Why are so many people using Scrum, yet I see so few demos?
From all of the rituals in Agile Scrum principles the Sprint Demos are the most undervalued. In the organizations that I’ve worked in, and teams I’ve worked with, we’ve always held stand-ups, some form of planning sessions and retrospectives — all according to the Scrum principles. However, demo sessions always seem to be forgotten. Why are demo sessions so infrequent?
In this story I’ll argue why demo sessions might actually be the Scrum ritual you should dedicate most attention to.
Consider your Sprint Demo as a celebration of your work…and give it appropriate attention!
Why are demo session so rare?
First and foremost: you don’t have to do a demo session to do your work. Period. It is perfectly fine to deliver good working software without ever doing a demo session. This means that there is no incentive for a development team to actually give a demo. It simply does not block or delay their work if they don’t do it. That means that the value of a Sprint Demo has to come from external sources: a product owner that wants to track progress or external stakeholders that want to see deliverables. There is no inherent value for the development team to show their progress to others.
You don’t have to do a demo to do your work. There is no incentive to actually give a demo.
Another reason is that organizing a demo session takes a lot of effort: you have to invite people to join, setup and prepare your work, make sure it runs, book a room, etc. This means that you actually have to invest time into something that (at most) marginally benefits you.
Finally, lots of developers don’t enjoy presenting or giving a demo. Some people do not like to stand in front of a crowd and tell a story. Some people do not like to answer questions from the audience. This could even mean that it is an experience that people try to avoid, because it makes them feel uncomfortable.
The value of the demo session
Personally I’m convinced that regular demo sessions are useful, and you should stimulate teams as much as possible to have demo sessions. In the paragraphs below I describe the value that I see in demo sessions.
Demo sessions inform stakeholders
In the principles of Scrum the demo session is mainly intended to involve external stakeholders. In contrast to traditional waterfall software development models Scrum is intended to deliver working software as soon as possible. At every moment the software must be usable, so all stakeholders can assess whether it solves their needs. The goal is not to avoid errors in software development, but rather to find issues early on and correct accordingly. In order to do that you need to let all stakeholders use the software so they can actually determine for themselves whether it works and serves their needs. Demo sessions are an excellent way to demonstrate where you are in your development process and gather feedback from your clients and users.
I’ve also had demo sessions where we found out that features that were delivered actually should have been different. It is useful to know this as soon as possible, so you can correct and create the right features. How can you know if you are making the right features? Demonstrate often and regularly.
Demo sessions help to take a holistic perspective
In your day-to-day work you can easily lose track of why your are building certain features. In every demo session I organize I always ask the developers to think about why we are building this feature. Take the perspective of your user or customer. If they are able to articulate this to others then I know they have understood what they are asked to build.
It helps to place work in perspective: for example, we are building this part of automatically processing a form, because it currently takes a colleague about a full day of work to do the same thing. If developers understand the value of the feature they are able to make the right choices when building the feature. In my experience it works if you let people understand the complete value proposition and delivery. (That’s why I slice features in a specific way and never use the 'As a user…’-way of writing stories. More about that in another article)
Demo sessions balances out firefighting behavior
I define firefighting behavior as trying to solve issues at the last moment, or figuring out a solution for a problem that has already happened. Unfortunately this is common practice in the organisations I’ve worked in. Although I understand that in some cases there are unforeseen circumstances that may require immediate action to resolve an unforeseen problem, in most cases you could have solved most of the problems by proper planning. The issue that I have with firefighting behavior is that everyone loves a firefighter. You basically get recognition from the organisation and the behaviour is thus rewarded. Firefighters often get a podium to showcase what they have done and how they - in the last moment - fixed the situation. People that do proper planning and ensure everything is well taken care of do not get this same podium. By having regular demo sessions you create your own podium. This gives the team the opportunity to receive the same recognition within the organisation.
Demo sessions save time
But wait, didn’t you just say that demo sessions take a lot of time? Yes, that is definitely how it feels if you are organizing them. But if you think about it: you hold a demo session and in 20-30 minutes you can showcase to anyone in your organisation what is new. If you have to go round and explain it to each of them individually you’d have a day job doing just that. Or if everyone in the audience would have to ask you personally what’s new, you’d have to spent a lot more time answering those questions. Be pro-active and invite as many people as you want, so they at least have the opportunity to get themselves informed.
6 tips on organizing Demo sessions
Organizing demo sessions that are worth attending takes time and effort. However, you’ll notice that once you get the hang of it, it takes about 30 minutes to prepare in advance, and about 15-30 minutes to set up the demo session. Here are some tips to help you prepare your demo.
1. Prepare, prepare, prepare
Make sure that you are properly prepared for a demo session. You can’t kill a demo session faster than with unorganized, unstructured chaos. Think from the audience’s perspective: they want to see a smooth flow. For them it is a way to be informed in a few minutes.
This means:
- Practice the story. Explain why you are creating this feature and show how you implemented it.
- Run software from a production environment. Don’t deploy software in the demo, unless you are showing a new software deployment system/pipeline/etc.
- Test whether your feature works in the way you want to show it. It’s really awkward to stand in front of an audience and miss the clue to your story.
- Avoid showing features that are half-finished. People will focus on what is not there, instead of what is there.
2. Keep a list of invitees and invite them at least a week in advance
I use distribution lists in Outlook to quickly invite people for the demo’s. This way I only have to add that group to my invitation and I don’t have to think every, single time about who to invite. I also add more people as they show interest to join. If you are not using Outlook, or can’t create distribution groups, find another means to use a list to keep track of the people you want to join the session.
3. Make a list of demo features to show and create a good looking invitation
If you invite people do them a favor and tell them what they are invited to. Give the list of topics that you are presenting at least a day in advance so people can decide whether they want to join or not. Don’t assume that people join, just because you are such a pleasant colleague, they want to get something out of this session.
I typically create an invitation with a brief description of what we will show. Just two or three lines in which I explain why we have created the feature, and what we will show in the session. Essentially this is the summary of the demo’s already. Throw in a nice screenshot as well (Don’t be afraid that people won’t come — most people enjoy actually seeing the things in action).
4. Set up the session before everyone walks in
Ask which of the developers will present and if they can make sure everything will work smoothly. Give them the responsibility to demonstrate their own features. (If they don’t want to present, do it yourself).
Set up the demo and any files you need before the session starts. There is nothing more boring and uninspiring than seeing someone create a text file, or Excel file on the fly to create dummy data.
Keep in mind that you want to focus your demo only on what you want the audience to see and experience. Anything else you should prepare upfront, or leave out of the session.
5. Capture and share your demo
Nowadays it is easy enough to capture a screen recording. I use Microsoft Teams to host the session online (bonus: also allows remote colleagues to join in!) and record the session (via a ‘screen recording’). This gives people the opportunity to look back if they missed your session, or to check how the feature actually works in their own time. Demo’s tend to be rather fast, because the person demonstrating knows exactly what the flow should be. It can be useful for others to have a recording of how to get to the same result.
Of course, don’t forget to also share the recording afterwards to everyone that was invited. A great opportunity to also inform them about your next demo session!
6. Claim and defend a place in your visitors time
Make sure that your demo is worthwhile and that people want to keep coming back. Make sure they tell others in your organisation as well. That enhances the value of your demo sessions.
How can you achieve this? Choosing an appropriate time for the session is essential.
- Stick to the defined schedule and timing. I would also add: don’t ask for more than 30 minutes of someone else’s time. Never-ever let demo sessions run late. Allow for one or two questions after a demo. If there are more questions invite people to talk to you afterwards, or ask the developers directly.
- Plan the session strategically in time. 11.30–12.00 is my recommended time as people lost focus for their normal work and they can go to lunch directly after the session. Avoid start of day (anything before 10.00), lunch times (12.00–13.30, depending on cultural differences), and end of day (anything after 15.30)
- Make the session recur at the same day and time. This way people get into a cadence of expecting your demo’s to happen and in their minds they block that time slot for you.
To conclude
In your role as product manager (or product owner) you have most to gain from the Sprint Demo. The development team you are working with may not naturally be inclined to organize a demo session. They can deliver good work without a demo session and may find it a lot of work to organize one, or may not like to be in the center of attention during a demo session.
Yet there is a lot to gain from a demo session. A demo session is a fast way to update stakeholders in your organization. Presenting a demo forces you to look at the bigger picture and tell a compelling story. Demos also provide you a podium to show your contribution to the organization. And eventually demos will save you time in your daily work.
I hope this will bring you as much value as they bring me and my team.
Bonus tip
No slides! Seriously, don’t fall in to the trap that you prepare a slide deck for a demo. I have not come across a good reason yet why someone would need slides during a demo session. (If you have a valid reason, please let me know).
I oftentimes hear “there is nothing to see”, for example when we demonstrate additions to the API. Essentially anything without a UI, most developers consider as non-demonstrable. But this is not true. Consider what this addition means for the end user. What additional benefit does it bring them? Can you somehow show that? We once created a feature where users could link our service to their own webhook. A pure API addition. However, with a simple Microsoft Teams channel (webhook plugin) we showed that the end user could create his own notification service. And that is added value for a customer, and something worthy of a demo…
