The Team has been hard at work for a month, and time has come to show off what have been accomplished.
So How Did We Ever Get This Far?
Revisiting our stripped down definition of Scrum, we can see that we have arrived at #4 (of 5). This means that we’ve created #1) a Product Backlog, we have done #2) Sprint Planning (both phase 1 and phase 2) and we’ve been hard at work during #3) The Sprint (there are two different posts on the subject).
Only what is truly done, is eligible for demonstration. Done is still defined as “potentially ready for production”. The Product Owner and the stakeholders are invited, and The Team spends at most 1 hour to prepare (clear out the meeting room (stash away the the Xbox), adjust the projector, bring up the software on the demo-computer, bake/buy some brownies, etc.). We’re not in the business of creating fancy pantsy power points telling a glorified story; we’re going to see the actual implemented functionality, live. We’re going to fiddle and play with it to see how it actually works.
To break it down into hard facts, this is how The Demo will proceed.
- First off, some formalities. The Team presents the Sprint Goal, the Product Backlog they committed to, and what was completed. Different team members will talk about what went well, and not so well, in The Sprint.
- Show and tell. The majority of the time is spent in dialogue with the stakeholders, while showing the software functionality. The Stakeholders are asking questions, getting clarifications, providing their criticism and so forth. The Team makes notes and engages actively in these discussions.
- Feedback. After the show and tell,The Stakeholders are polled one by one for their impressions. They are allowed to suggest changes. Additions, or requests to redo parts of the delivery, are put into the Product Backlog for prioritization.
- Next demo. The Scrum Master announces the next place and date for The Demo, and we’re done.
So What’s so Great About The Demo?
For one, it’s people, communicating. Again! Good communication is a cornerstone in complex undertakings, such as software development. The ancient form of communication (talking) is so alive and of such a high-bandwidth that enourmous amounts of information will flow freely during these sessions. We’re touching and feeling the actual product, talking about it, discussing it, pointing at it (maybe even yelling), proposing improvements, changes, and evaluating its value now that it’s alive and breathing right in front of us, on the screen.
Without feedback, there can be no improvement. During the demo feedback is polled from The Stakeholders. Feedback (whether criticism or praise) is yet another cornerstone for making not only great software, but the right software.
Getting to Done, with focus
The Demo keeps The Team focused on not over-committing to Product Backlog items during Sprint Planning. Whatever is committed to must be truly done, or we won’t even justify talking about it during The Demo. This focus on done will keep complexity under control (not creating more and more almost done functionality that weighs you down), and it facilitates a fresh start for the next sprint. The fresh start is important for morale, and it is important not to drag half-finished functionality along. They will get increasingly expensive to implement the longer they drag out in time — it’s far better getting to done when everything is fresh in mind.
It’s serious business, this Demo. (Knight Rider theme fades out; The Hoff is dishing out high-fives)