Agile tales: Where did that demo go today?

news · 6 years ago
by Miklós Vargyas

Yesterday I had a chat with a developer about daily demos. He and his team were planning to demo their product increment in the next couple of days for all other teams, developers who were interested. That was intended to be a short, 5-10 minutes demo to enable stakeholders (other developers in the company in this case) to give feedback on what's been built.

During our conversation, however, this dev raised a concern: "The demo effect can ruin everything, the system that's still under development may not work when other devs stare at it with their hungry eyes. Shouldn't we wait until more is built and the system is more complete, stable and 'almost' done?"

No, I said. If something goes wrong due to the demo effect that's just fine! That's why we demo everyday. The sooner it crashes the better for us. It may reveal design or integration problems, unfeasibility of the particularly approach taken, or just simply a bug, whatever. If it remains hidden for a longer time and turns out sometimes later then it might cost us lot more to fix.

This is one key idea in agile product development: shorten the feedback loops (when the system or the next potential increment of it get's tested, reviewed, reflected) and make the feedback opportunities frequent.

Sounds good, doesn't it?! Well, no. It's fine as long as it is not me who has to do the demo. But as soon as I have to sit there click, show and tell, this great idea gets rather scary. If everything goes well then I feel happy, satisfied, proud… but if if things go wrong, and they surely will, thank to the demo effect, then I feel embarrassed, I feel shame. This potential risk will make me hesitate, feel insecure and reluctant to do the demo. When I demo I don't expose the product as it is in the current shape, but I expose myself and the whole team who worked on the story. It requires extreme courage do go there and do it, and to take the risk that the demo effect will strike down.

But, if every stakeholder who's there knows that it's not failure if something goes wrong, that it is just normal and great since problems turn out in early development not in production, then I can feel more secure, more comfortable with this situation.

We should not stigmatise failures, mistakes but we have to praise them and ensure that they happen early in development. The demo effect, just as all sorts of "failures" in agile development, are our friends. Try to demo everyday and don't be scared of showing something incomplete.