Agile project teams that skip demos put their outcomes at risk – for each sprint as well as the overall release. The reason that is often given for not having done a demo at the end of a sprint in agile projects is that whatever the team is delivering as “done” that sprint is not interesting enough to demo. After a couple of sprints in which this thinking goes unchallenged, the team will not only accumulate technical debt, but their velocity will slow and progress on the overall backlog will slow.
Teams that demo every sprint have a tendency to perform better. While teams that skip demos tend to underperform. The reasons behind this deserve further examination to help build the case for doing demos at the end of every sprint.
The most obvious issue is that without the need to present a demo of what the team completed, it is easy to say, “we can finish that in the next sprint.” Small things like documentation, bigger things like tasks, and processes like full regression testing can easily slip without the healthy pressure to be accountable for being “done” and able to demo at the end of a sprint.
With this mindset, it is a slippery slope to accumulating technical debt and other partially-finished backlog work that could require the team to add sprints to finish needed features or to deliver less valuable scope in a schedule-driven project.
Here are just six of many solid reasons why agile teams should demo every sprint, even when they think their demo might not be very interesting to the product owner or other stakeholders:
- Commitment and accountability: Agile project teams operate on shared commitment and accountability to themselves and to the organization to deliver on these commitments every sprint, and every release. Committing to complete a sprint backlog and then being accountable to demo what is done forces a team to be accountable to that commitment.
- Transparency: One of the great things about agile is that showing what is fully done every sprint is a true and transparent way of measuring the overall project progress and leaves no doubt as to what is really complete.
- Healthy pressure: Some pressure is healthy for teams. Knowing that the team must demo their work at the end of each sprint adds enough pressure to help them push to get it “done.”
- Pride in work: Doing a demo every sprint encourages the team to be proud of their work every sprint, no matter what they are delivering – even if they think the deliverable is uninteresting.
- Motivation: Points three and four above help with overall motivation. Project team motivation is an aspect of projects that is not always easy. Leveraging a degree of healthy pressure to deliver the demo, as well as the team’s pride in their work, can go a long way.
- Agile discipline: We demo because we are using an agile framework, and demos every sprint are part of the discipline of most agile methodologies. Rigor and discipline in execution is crucial to project success as well as improvement in the use of agile methodologies.
Think the sprint deliverables are not interesting enough to demo? Make them interesting! Find the value in each one and focus some element of the demo or presentation around it.
I recall a team member from a past project who worked for an entire release cycle on a set of application programming interfaces (APIs). These valuable, incremental software product enhancements did not lend themselves to demos, but that did not stop the team member. For each sprint, he would pick a theme for his slides (Game of Thrones, Star Wars, Family Guy, etc.), and create a humorous and effective presentation on that sprint’s API advancements with the theme. It communicated well to the demo audience and added humor to an otherwise dry topic.
Another example is from my first true Scrum team. Part of the team’s first demo consisted of a blank web page with two fields and a control button. A numeric value was placed in one field, the button clicked, and the same value came back in the other field. Not too exciting – until the technical accomplishment of building first-of-its-kind middleware to communicate with a particular Enterprise Resource Planning system was explained. The product owner and sponsors immediately understood the value, making it a worthwhile demo.
In summary, demos are an integral part of agile projects. They are necessary to show the value completed of each sprint and ensure the project maintains momentum.
Remember, teams that do not demo slip – teams that do demos ship!
Similar Content:
-
How strong product owners can make agile projects successful
-
Why it is important to protect your sprint backlog?
-
5 Reasons to consider using an agile approach
