Scrum

WHAT MAKES THE DEMO ACTUALLY USEFUL?

In scrum, there are a lot of ceremony that we perform. A routine that we follow, meetings we always have. All of them has a purpose, or we wouldn’t do them. That goes for the Demo too. But I have found that the demo in most of the cases degrade to being just a show-and-tell performed in front of patient parents that wants their children to be happy.

First, let’s define the Demo. It is performed just after the sprint ends. Yes, it’s not a part of the sprint. The sprint is when you play the game, when you create the things you are going to deliver. Then you deliver it, as you do after every sprint. It would be hard to demo something that isn’t finished, no? So, we wait until we have lifted our hands from the keyboard and moved away one step from the desk. Not until then is there anything to demo, it is just a work in progress.

Second, everybody is invited to the Demo. Not everybody has to come, but they are welcome. The ones that are required are the persons who are receiving the things we developed. The stakeholders to the user stories and to the product. We can’t do a demo without them. They are vital to the process. And I will explain why in a second.

Third, the meeting is to get feedback, to have a two-way discussion with the stakeholders. The things we talk about is if they are happy with the solution we present or if they want anything changed. So much can go wrong during the process. We don’t have all the domain knowledge they have, and when they tried to explain things to us before we started writing the code, we likely misunderstood some things.

Then there’s the human factor. When the stakeholders see what we have done, they start to think. It is exactly what they wanted, but we didn’t think of this or that. Or we really should have that implemented too. So, we need to change a few things. And now we know.

Or it is almost exactly what they wanted, it’s just that the order of the things is not perfect, like we should move a menu entry up one level to reduce the number of clicks, which will be significant because they use the function a lot. Or moving things around on the screen to make it clearer because they know that some things belong to each other, and we didn’t know that. It could be anything.

This is the real benefit of the demo!

The discussion, the communication, the feedback.

We want to know as soon as possible if we are on the right course. We want to correct things as early as possible. The alternative, wait until everything is finished (a.k.a. waterfall), makes it so much harder and so much more expensive to correct. Things stack up. Compare with a building. If we don’t get the foundation right, it is much easier to fix it when it is out in the open, and not when there is tons of building materials on top of it that we have to work around, or in worst case, tear down.

Now, what happens most of the time is that the stakeholders probably don’t know what scrum and agile is about. They are still living in the old world. Departments, deliver when finished, accept both the good and bad and move on…

On the other hand, we developers have had a lot of time to accept the scrum way. We live and breathe it every day. So, to us it is natural. In fact, it is so natural that we don’t think of it as ‘something else’. It is the norm. And that means we unconsciously think that everybody else thinks the same way.

And that is a big reason why demos rarely work. We have different views of the world. The sad thing is that we just let it happen. We developers just sit down after each demo, sigh, and wonder why the stakeholders don’t show any interest at all in what we do.

What we have to do as a scrum team to fix this, is to realise that we have to educate. We have to tell them what we need. We have to show them that they actually need it too. They will never guess it, and they are not mind readers. We have to invite them into the discussion. We have to make clear at the beginning of the meeting what we expect from them.

Start with the invitation. State the reason for the meeting. Not demo. Feedback! Tell them why we have the meeting. Then the stakeholders will be a little primed for it.

Begin the meeting with repeating this. We want feedback. We need feedback. It is the reason why we are here, to get feedback. Not to just show you what we have done. Your opinions matter.

Then, after each story is presented, don’t just sit there. Ask the stakeholders what they think. Is it as they expected? Should we tweak anything to make it even better? Do you see any new ways on how to improve it? To add to it? And don’t forget to talk about the next step. How does this fit in to the bigger picture? As long as you get the discussion going in the right direction, you are doing it right.

I think the name is poorly chosen… Demo. It implies that we just want to show you something. I would use the Sprint Feedback or Stakeholder Feedback as the name of the meeting instead. That would communicate the intention of the meeting immediately.

— Cheers!

Like it? Share it!

Leave a Reply

Your email address will not be published. Required fields are marked *