Stop wasting your time on Demos

On their journey to create valuable products, agile teams may wonder how to best organize product demonstrations, out of any agile dogmatism and overly precise frameworks.

The demo is a pivot ceremony and needs to be mastered by the team as soon as possible. So stop wasting your time on unuseful demos: it is a serious evidence you’re driving to a cliff. Stop asking feedback on elements you don’t care, or even worst, on design you consider as good enough. Stop justifying the work you did on the last weeks. Stop waiting for recognition. Stop discovering what your colleagues have done the last weeks during this ceremony. Stop checking your email by lack of interest or because you wait your turn. None of those behaviours will help make you customer, team or organization awesome.

Go back to agile basics and (re)start thinking on your agile journey up to great questions.

A new definition of the Demo

While the demonstration is only a part of the SCRUM review, it remains an key momentum to gather feedback and check hypothesis. I would propose a new definition. I design it as complementary of SCRUM and inspired by Lean StartUp, to help you finding the essentials of agile.

The participants* will regularly* validate* (or not) hypothesis* the team have made on the product: “this technical thing should work like this”, “this design is good enough for our customer”, “this functionality is what they really need”, “this performance level is sufficient”, “the new product increment will work”.

*Further details on the words I’ve used:

• Participants: those who will provide answers to your questions as well as ask new relevant questions.
• Regularly: as soon as it is relevant. Don’t wait the end of the sprint if it is possible to check the hypothesis before with relevant stakeholders.
• Validate: you may need more than a screen to do so. Test, review and adapt what is relevant for validation on your context. The closest to the real product in the customer context, the more qualitative it is.
• Hypothesis: Learning over feature. We do not presume the value. We make hypothesis that we want to test, confirm or invalidate. Be data driven.

Last, if you are not yet familiar with Lean StartUp, Eric Ries defines two type of hypothesis:

• Growth hypothesis: how to put the product on the market?
• Value hypothesis: would our customers buy this value?

It would have been able to use the word “feedback” instead of “hypothesis” as agile coach and Scrum Master usually do. My observations are that when teams ask for feedback, there are not in a posture of learning: learning from others, learning from mistakes and wrong hypothesis they have made. Maybe due to their high school education (the do thing perfectly mindset). Feedback is a mean and not a goal. The goal is to check hypothesis to move forward. There are different ways to check a hypothesis. One of them is to observe the behaviors of a customer using your product.

A structure to help team members preparing the demo

Sorry guys, the purpose of a demo is not to celebrate your works. Celebrations and cheers might be a spontaneous consequence of a demonstration, but it shouldn’t be your objective as seen before. If recognition of your work is a thing, share it to the team and invent a different ceremony.

Based on Richard Lawrence’s article “How to give a great sprint demo”, below is an adaptation with what looks essential for me as today:

1. Tell a story. It is not a new story the developer consolidates 30min before the demo. It is the story you should have prepared before taken the work in the sprint. The better it is prepared before the sprint to start, the better is it during the demo for the presenter.
2. Focus on hypothesis over the long acceptance criteria list. You need to keep the essentials to make a story great, and the demo focused on the essential. Consider each iteration as the validation of different hypothesis.
3. Invest in accordance to the importance of hypothesis to be checked. Rather than “Run through the demo at least once” or “three time” as you can read on different articles on internet, ask to yourself the question: “What is the minimal amount of time I need to invest to unsure we can validate or invalidate the main hypothesis we have made on the product during this sprint?”
4. Ban the question “Do you have a feedback? from your demo. It doesn’t generate ideas, neither goes in the direction you would hope. If there is a specific area on which you want to learn and collect fruitful feedback, tell it and be specific. If not, don’t demo your work and continue you plan.

Questions to adapt your demo framework

It might be difficult to challenge the status quo of standard framework as the crowd always refer to them. It is even more difficult when you finally succeed to apply them after tremendous efforts.

I propose few questions to challenge the status quo of your demo:

• What are you trying to learn from the demo you’ve organized?
• Is it customer/business focus to invite a lot of stakeholders waiting their turn during a demo?
• Is it customer/business focus to run the demo by the team, not letting stakeholders playing with your product?
• Is it customer focus to ask to key-users speaking in the name of users?
• Is it customer focus to restrict the demo to the demand expressed by customers not benefiting from their presence to learn what they need?
• Indeed, are you learning from participants you have invited?

Conclusion

The hypothesis of this article is that you truly want to be agile in your industry, you want to design great products and have great teams enjoying what they do. Are you therefore starting to moving from standard framework? Are you trying to build your own one? I would love to read your story!