- Project Demonstration, Sprint Demo, Sprint Review, and Iteration Increment Show – we are familiar with the various titles of these meetings but the core idea of each of these meetings is the same. The objective is to show everything that team has done at the end of the iteration to stakeholders and budget owners of the project. We know how important this meeting is and how simple in theory it is. Just gather them together and show what you have done. In this article we will look at real Luxoft project. We will examine a problematic demo meeting and then look at important aspects of effective demo preparation to succeed in this simple process.
At the beginning let’s look at project itself and project environment. It is an internal key company-wide product. It has more than 10 stakeholders in Moscow and about 10 stakeholders in other locations. More than a half of stakeholders are senior management and are very busy people. Product Owner, team managers and analysts are located in Moscow. Scrum Master and development teams (about 15 people) are located in Dnepropetrovsk, Ukraine.
How it was
Now let’s look at a sample demo process and its problems. They have started a demo meeting in a very simple way by just asking everyone to come and to see what the team has done. However the following occurred:
Demo Meetings Delays with a 15-20 minute delay because:
- Team was waiting for everyone
- Team began to start WebEx, conference call and other technical preparations at the start of the meeting
- Microphones didn’t work or worked badly
- It was not clear to everyone when the demo has started and ended
- There was no agenda or clear demo plan
- There was no known demo meeting leader
- Several people started long conversations outside of the demo scope
- No one really understood the reason for the meeting
- Only participants from Moscow were in the game – people from other locations didn’t hear conversations, were not able to communicate with other attendees and understood little if anything.
- People didn’t understand what was shown on the demo
- People didn’t understand whole project status
- People got a lot of complex and unclear status slides
- Some stories were not able to be shown correctly
- Stories had only test data like “12345”, “qwerty”, “test surname_1” and people didn’t understand how it worked in real life
- The actual scope of the stories were not clear and it was hard to understand if these stories were accomplished or not
- The reasons for specific choices were not clear
- Technical stories were shown to absolutely non-technical stakeholders with technical details that were not comprehensible to non-technical stakeholders.
- Forgotten Action Items – there were a lot of action items that were lost after the demo meeting or were misinterpreted.
- So we see that the “organizational recipe” for this demo meeting did not work. Now let’s look at a list of solutions and techniques that helped to improve the situation:
- Recurrent Demo Meeting Requests – we have created recurrent meeting requests in Outlook so everyone knows when will be the next demo meeting and in order to book their timeslot beforehand.
- Recurrent Demo Preparation Meeting Requests – we have created recurrent meeting requests in Outlook so everyone who is responsible for Demo has time to prepare it (start video/audio conferences, check connection, meeting room readiness, etc.) and to book a meeting room beforehand. This is all done in order that when stakeholders come to a demo meeting everything is assured to be ready and working.
- Definition of demo start time – we have decided that demo starts just when key stakeholders (2-3 persons) come in. So now all other stakeholders know that we will start just when key stakeholders come in and there are no other delays.
- Strict Agenda – we have created a clear agenda that is described in a meeting request letter and is reminded at the start of every demo. Demo strictly follows agenda. So now everyone knows when this or that will be discussed and there are no undirected chaotic discussions.
- Working Agreements – we have introduced Working Agreements as an instrument of keeping demo meetings productive and focused on achieving goals. We have Demo Agreements written on the white board at every Demo Meeting and we remind stakeholders about them. Demo leaders can use the Demo Agreement as an instrument for guiding any discussion.
Demo Meeting Agreements
- Demo strictly follows agenda
- Only one person speaks at the same time
- Discussions which are out of agenda or take too much time should be stopped
Handouts – we have printed colorful handouts so everyone can see slides of presentation and be able to take notes for themselves. Also it is useful when the projector shows not only the presentation but the working application.
Agile Charts – we have changed all sprints and release statistic slides from classical project management approach to agile which makes understanding of progress simple and clear.
How it was:
How it is:
Demo Leader – we have introduced to everyone the person dedicated as a Demo Leader. This is the only one demo facilitator in the meeting room, who rules demo, gives voice to others, watches the time, follows agenda and uses demo agreements as an instrument of controlling the demo. Now everyone knows who is leading the demo and who has the rights to rule the meeting.
Assistant in other location – we have given a team member as an assistant to Demo Leader in Dnepropetrovsk to facilitate other team members and demonstrate executed stories. The Assistant controls everything that is shown on the screens and can connect team members to discussions. Also the assistant manually adds action items to the parking lot so that everyone in real-time sees that everything is written and is written correctly.
Video Bridge – we have removed boring and ineffective audio conference and have introduced video bridge using 2 big monitors in 2 main locations and 2 cameras. Presentation and application are showed using projectors. Now stakeholders and team members not only see the application and hear the presentation but have rich and efficient conversations looking at each other.
Removing Tech Stories – we have removed tech stories from the demo because they are not interesting for stakeholders and can be confusing for them. But for everyone who wants to look at them (for example if several stakeholders are technical guys) there is a timeslot just after demo wh ere tech stories are shown.
“?” Marks – we have made these marks to give a quick and working mechanism of stopping the demo to ask some question. It works better than trying to interrupt people from other locations talking.
Moving Story Acceptance to another meeting – we have made another meeting before all-hands demo session for formal acceptance using acceptance criteria with the Product Owner. It is not interesting for all the stakeholders to look at every story in such detail to check accordance of working story to acceptance criteria. So at the Demo we show only stories accepted by the Product Owner and ask for feedback and double-check that stories solve business problems.
Quick Demo Feedback – we ask stakeholders after demo for quick feedback on Demo organization (what was good and what was not so good) this helps us to improve demo quality continuously.
Demo Team Retro – we have a short retrospective review after each demo meeting in order to improve weak parts.
And that’s all. No magic and no complex solutions – just a number of simple yet powerful techniques which has helped this team to become more effective in carrying out demos and make their customers happier. I hope this will help you too.