I wrote an article a few months ago about sprint reviewing the “hard stuff”. It was inspired by an engineer who asked me (challenged me) about demonstrating more back-end, embedded, non-UI, infrastructural work at the end of Scrum sprints.

 

 

His general take was that it was:

• Hard to figure out how to demo the “stuff” they were delivering, and
• The components didn’t lend themselves to demonstration (in simplistic terms, they didn’t have a UI)

I pushed back a bit in the article, trying to encourage him to demo “something” and not “go silent” for too long.

Last week I received the following comment on that article. And really appreciate Christi taking the time to read it and for asking her questions. In this article, I’d like to respond…

Comment

New comment from Christi on Sprint Reviews—do you need to demo the “hard stuff”?:

I like the questions to ask the team.

But, I don’t think that dismissing the question as teams trying to skip this step is accurate. I have a team that does low level coding that does not show. They want to do demos – they want the feedback from the stakeholders – they want the involvement of users. We have tried the high level approach of “this is the business value you will get from this code”, tried low level “technical” reviews, and even tried fun game show type approach.

The problem is not the team or the work. It is a strict adherence to a ritual that does not necessarily add business value at every stage of development. There needs to be a better solution than to just keep doing it because it is the process – that is just anti-Agile to me.

The Agile community spends so much effort on how to make the Retrospectives meaningful and/or fun and so much internet space on ways to deal with tough team members, it is about time to focus some on the demos. Just like Retros, demos are not one size fits all. And some support from the community on ideas during these “tough times” in the cycle would be fantastic.

For our next demo our team will be presenting the stats of progress of a software upgrade and hardware upgrade as there truly is nothing to see other than a box with a green light in a server room. (There will be a picture of said server and field trip for those interested.) But this seems a waste of resource time – we know the next steps, we communicate daily with the Product Owner and impacted teams. We understand the impact of the overall effort and the options in front of us. We cover that in our Grooming and Planning sessions.

So, when does the demo become ritual rather than driving business value?

 

The ESSENCE of the Sprint Demo/Review Is…

Christi forced me to think about the essence of the sprint review or demo. Should it focus on ceremony? I’d say no. Should it focus on showing the easy stuff or what’s convenient? Again, I’d say no. Should it be a simulation or an allusion to what the team just delivered? Again, no.

So what IS it about?

My mind goes back to the second principle of the Agile Manifesto –

Working software over comprehensive documentation

Then the first thing the review or demo is about is – showing working software. It doesn’t say – just UI-centric software or functional software or even programming language centric. It’s very open-ended, emphasizing working software. So I get it – working software is a central focus.

The next question I asked myself is the WHY behind demonstration. Why are we doing a Sprint Demo or Review. What’s the ultimate purpose? What is it trying to achieve?

Again, I think it’s simple. It’s about FEEDBACK…

• From / to your customer(s)
• From / to stakeholders (management)
• From / to other teams
• Preparation – From / to each other 😉

Logistics

Scrum talks about having a Sprint Review at the end of each sprint. Some folks call it a demo. It’s where the “potentially shippable deliverable” is demonstrated to customers, clients, and stakeholders. It’s a powerful bit of closure to the sprint and a place to synch-up the team and their customers on the teams’ progress.

• Is it a milestone? Yes.
• Is it a status checkpoint? Yes.
• Is it a “Show and Tell”? Yes.
• Is it group-based? Yes.
• Does it serve as closure for the sprint? Yes.

The review is built in as a ceremony in core Scrum. If you’re trying to adopt Scrum, and it’s an incredibly simple framework, then the Sprint Review is a requisite part of it.

Responsibility

I also want to make the point that the team has a responsibility to make their work transparent. Not just in a demo, but all of the time. This transparency allows stakeholders to see progress and problems. It also allows them to ask questions and established dialogue between themselves and the team.

Transparency is a core agile tenant or principle and it has lots of positive side effects. I mention the responsibility here to Christi to make an important point:

THAT the team does a demo and makes things transparent is a firm responsibility.

HOW and HOW OFTEN are sort of up to the team.

And teams who embrace this responsibility usually become incredibly creative in demonstrating their software and gaining valuable feedback, which consistently amazes me.

Sample Agenda

Here’s an example of the sort of agenda or flow that I normally like to see from a team Sprint Review:

Hello, This is me/us (the team), who we are, what we generally do

Here’s what we tried to do and why (Business Why – Priority – Delivered Value)

Here’s how we approached it (Strategy)

Here’s a quick synopsis of the results  – How did it go? Did we meet our goal? If yes, great! If not, why? Impediments? What did we learn?

Let me/us show you what we did; what do you think? (Feedback Loop)

Here’s where we’re going next – working on, goal(s), what to expect in next demo.

What do you think? Fist of Five on the review…

Thank you for the feedback!

Wrap-up

Getting back to Christi, I think she may be getting wrapped up in the wrong things – that is the tactical parts of the Sprint Demo. While tactics are important, it’s not really the point.

The real point is for her and her team to:

1. Demonstrate working software
2. Gain/Give customer & stakeholder feedback

And do those two things as frequently as possible. That’s it. No ceremony or ritual allowed. Just good old fashioned demonstrable software and then…listen.

Stay agile my friends,

Bob.