| This series is about practices we do, without understanding why we do them, and therefore may not get the value we want from them. If you too don’t benefit from them, you might be doing it wrong. | |||
|---|---|---|---|
| Iteration planning, Pt. 1 | Iteration planning, Pt. 2 | Definition of done | Demo |
| Done-Done | Daily stand-ups | Retrospectives |
Another iteration has passed, and so they gather, developers, testers, product owners and scrum masters to behold the showing of the increment.
But lo, can they screw this up as well? You betcha.
But before we do that, let’s recall why we have a demo in the first place. Remember the deal between the development team and the business? “You let us work for two weeks without interruption, and we’ll give you something that works.” The trust we try to build requires guarantees from both sides.
How does the business know that they get something that works? After years of hearing promises of “just a few tweaks and it’s done”, we now have a demo. The product people can now examine the results and decide – is it enough? Are we going to continue developing this? Do we throw it away?
Agile, being a risk-reduction methodology, uses the demo as another feedback point to do course-correction. It limits the time of developers building the wrong thing, until the next inspection. And since it’s that important, the demo becomes an essential ceremony. Any agile framework saves a time slice, just so we won’t forget to do it. You know, like retrospectives.
Masters and Students
Smart teams, who already got the idea that feedback is good for them, don’t wait for the demos. They understand that the product people are not out to get them, and can actually save them time if they do early reviews. They proactively do preliminary demos to get that feedback.
But with early reviews, how much point is there to the official demo meeting?
Sometimes, the point of the demo is outside the team’s scope. Invite other teams to see what we’ve done, or management. Or get some pizza and be proud of what you’ve accomplished.
Teams that are starting to adopt agile practices, still need the demo meeting as a feedback check point. However, that demo can lose its value very quickly because we concentrate on procedural stuff, rather than on its value.
Hand me that process fixer, will you?
You’ll hear many things in “bad” demos. Here’s a couple:
- It’s not done, but let’s show it anyway
- It’s “development done”, but not tested, but let’s show it anyway
- Preparing the demo takes too much time
- The team is showing APIs, not GUI, so it’s not useful for the user
And many others.
Sure, we can solve all these with proper guidance. For example, show only Done-Done items, because we’re after working software. If there are only APIs to show, that’s not done. Bugs open? not done. Demos need preparation? not done.
All these are based on our work process. They stem directly from the agile manifesto, the principles and agile practices.
But all those miss the point.
If demos are for getting feedback (and they are, we already saw how agile masters do it) then why should we exclude anything from the demo? Obviously, if we solved the trust problem, there’s no issue showing half-done things.
It doesn’t matter if we just have APIs, or half working UI. Feedback is still helpful. “But showing tests to product people is stupid”. Nope, most of them don’t seem to think so. Ask them.
Demos are about allowing the team to make decisions, and change course through feedback. The more check points we have, we’ll be making less mistakes and waste less time.
The answer to the question “should it be in the demo” is, therefore, yes.
| Reference: | You’re doing it wrong: Demos from our JCG partner Gil Zilberfeld at the Geek Out of Water blog. |
