Agile. Successful demo in a distributed team
Project Demonstration, Sprint Demo, Sprint Review, Iteration Increment Show - we are all familiar with the different names of the same process event of the Scrum framework. The purpose of these meetings is to show interested persons and project budget owners everything that the team did at the end of the iteration. We all know how important this meeting is and how, in theory, it is simple - just gather everyone and show what you have done.
Below is the experience of a real project. We will look at the main issues and then focus on aspects of effective preparation and successful demonstration of the sprint results.
The team develops a key product used throughout the entire company. He has more than 10 key stakeholders in Moscow and about 10 more around the world. More than half of them are top managers (very busy people). Product owner, team leaders and analysts are in Moscow. Scrum Master and the development team (about 15 people) are in Dnepropetrovsk.
So the easiest way is to just ask everyone to come and see. And this is the way the team went.
However, the following happened:
The meeting began with a delay of 15 -20 minutes
• The team waited for all guests.
• The team began preparations at the beginning of the meeting: WebEx, audio conference, connecting to the system, etc.
• Microphones did not work or worked poorly.
')
Chaos on the demo
• Not everyone understood what time the demo session starts and ends.
• Lack of a clear demonstration plan
• Lack of leader demo session
• Began a lengthy discussion outside the goal of the demo
• No one fully understood the meaning of this meeting.
Only participants from Moscow took an active part.
• People from other locations did not hear the discussions and did not have the opportunity to communicate with other participants of the meeting
Lack of clarity and transparency
• Participants did not understand what was shown
• Participants did not understand the status of the project entirely
• Participants received a large number of complex and obscure slides.
Invalid user stories
• Part could not be demonstrated
• Use of test data: “12345”, “qwerty”, “test surname_1”. Participants did not understand how this would work in real life.
• The actual amount of user stories was not clear. It was difficult to understand whether this story was fulfilled or not.
• The reasons for choosing the implementation were not clear.
Technical stories were shown to absolutely non-technical people . A large number of technical details was not acceptable for such an audience.
Forgotten Action Items . There were so many points that were either lost after the meeting or misinterpreted.
So, everyone understands that this meeting was not effective. What methods have helped improve the situation:
Create recurring appointments . We created recurring meetings in Outlook - all participants always knew where and when the next demo will be. This allowed all participants to plan their schedule in advance.
Making training schedule. Now everyone who was responsible for conducting the Demo had time to prepare (start audio / video conferences, test connectivity, readiness of the conference room, etc.). All this was done so that when the parties concerned came to the meeting, everything was ready and we could begin.
Determination of conditions for the start . We decided that the demo starts exactly when the key participants (2-3 people) are present. Now, all interested parties know that we start exactly when the key participants come and there will be no more delays.
Strict meeting agenda . The demo follows according to the message. The Agenda is registered in the schedule and reminded before each meeting. Now everyone knows when this or that item will be discussed and chaotic discussions do not arise.
Working arrangements This is a tool to maintain the effectiveness of the meeting and maintain focus on meeting the goal of the meeting. Work agreements are written on the whiteboard on each Demo. Demo leaders can use them as a discussion management tool.
“Parking Lot” . When a discussion goes beyond the limits of the Agenda or takes too much time, the demo leader places it in a “parking space”, like an Action Item. Any Action Items encountered during the meeting are also placed there.
Handouts . We printed colorful handouts so that everyone could see the presentation slides and be able to take notes for themselves. It is also useful for the projector to display not only the presentation, but also the running application.
Agile Charts . We changed all the slides with the status of release or sprint. Previously, the “classic approach” was used, we made it more “agile”. This increased the understanding of progress.
It was:
It became:
Demo Leader . We have introduced the role of leader demo. This is only one presenter in the conference room who manages the demo, gives others the right to vote, keeps track of the time, agenda and uses working agreements as a management tool for the demo. Now everyone knows who is the leader and who has the right to manage the meeting.
Assistant in another location . We made one of the team members in Dnepropetrovsk an assistant of the Demo Leader. The assistant controls everything that is displayed on the screens and can connect team members to discussions. Also, the assistant manually adds Action Items to the Parking Lot so that everyone can see in real time that everything is written and written correctly.
Video Bridge . We abandoned the boring and inefficient audio conferencing and introduced a video link. The presentation and application was shown using projectors. Now, stakeholders and team members not only see the application and hear the presentation, but can effectively communicate when they see each other.
Delete technical stories . We have removed the technical stories from the demo, because they are not interesting for interested parties and can be misleading. But for everyone who wants to see them (for example, if there are technical guys among the stakeholders), a time interval is allocated immediately after the demo for their display.
Question marks . The question mark is a very quick and effective demo stop mechanism. This works better than trying to interrupt a talking person from another location.
Receiving user stories at another meeting . We made another appointment before the demo for accepting stories (using acceptance criteria defined by the product owner). The process of detailed acceptance is not interesting for interested parties - they are not interested in the demonstration of each story in detail. So on the demo we show only user stories accepted by the product owner, we collect feedback.
Fast feedback . We ask interested parties after the demo to give a quick feedback on the organization of the demo (which was good and what was not). This helps us improve the quality of the demo continuously.
Retrospective demo . We do a short retrospective after each demo. It helps to improve weaknesses.
That's all. No magic, rocket science, complex solutions - these are just a series of simple but powerful methods that helped the team become more effective in conducting the demo and made their customers happy.
This is not a complete list of what can be improved in conducting a demo. Why in Agile demo, how to conduct it effectively and much more, we reveal in detail at our trainings .
And how do you spend your demo?
Below is the experience of a real project. We will look at the main issues and then focus on aspects of effective preparation and successful demonstration of the sprint results.
Project Overview
The team develops a key product used throughout the entire company. He has more than 10 key stakeholders in Moscow and about 10 more around the world. More than half of them are top managers (very busy people). Product owner, team leaders and analysts are in Moscow. Scrum Master and the development team (about 15 people) are in Dnepropetrovsk.
How it was
So the easiest way is to just ask everyone to come and see. And this is the way the team went.
However, the following happened:
The meeting began with a delay of 15 -20 minutes
• The team waited for all guests.
• The team began preparations at the beginning of the meeting: WebEx, audio conference, connecting to the system, etc.
• Microphones did not work or worked poorly.
')
Chaos on the demo
• Not everyone understood what time the demo session starts and ends.
• Lack of a clear demonstration plan
• Lack of leader demo session
• Began a lengthy discussion outside the goal of the demo
• No one fully understood the meaning of this meeting.
Only participants from Moscow took an active part.
• People from other locations did not hear the discussions and did not have the opportunity to communicate with other participants of the meeting
Lack of clarity and transparency
• Participants did not understand what was shown
• Participants did not understand the status of the project entirely
• Participants received a large number of complex and obscure slides.
Invalid user stories
• Part could not be demonstrated
• Use of test data: “12345”, “qwerty”, “test surname_1”. Participants did not understand how this would work in real life.
• The actual amount of user stories was not clear. It was difficult to understand whether this story was fulfilled or not.
• The reasons for choosing the implementation were not clear.
Technical stories were shown to absolutely non-technical people . A large number of technical details was not acceptable for such an audience.
Forgotten Action Items . There were so many points that were either lost after the meeting or misinterpreted.
Solutions and methods that helped
So, everyone understands that this meeting was not effective. What methods have helped improve the situation:
Create recurring appointments . We created recurring meetings in Outlook - all participants always knew where and when the next demo will be. This allowed all participants to plan their schedule in advance.
Making training schedule. Now everyone who was responsible for conducting the Demo had time to prepare (start audio / video conferences, test connectivity, readiness of the conference room, etc.). All this was done so that when the parties concerned came to the meeting, everything was ready and we could begin.
Determination of conditions for the start . We decided that the demo starts exactly when the key participants (2-3 people) are present. Now, all interested parties know that we start exactly when the key participants come and there will be no more delays.
Strict meeting agenda . The demo follows according to the message. The Agenda is registered in the schedule and reminded before each meeting. Now everyone knows when this or that item will be discussed and chaotic discussions do not arise.
Working arrangements This is a tool to maintain the effectiveness of the meeting and maintain focus on meeting the goal of the meeting. Work agreements are written on the whiteboard on each Demo. Demo leaders can use them as a discussion management tool.
“Parking Lot” . When a discussion goes beyond the limits of the Agenda or takes too much time, the demo leader places it in a “parking space”, like an Action Item. Any Action Items encountered during the meeting are also placed there.
Handouts . We printed colorful handouts so that everyone could see the presentation slides and be able to take notes for themselves. It is also useful for the projector to display not only the presentation, but also the running application.
Agile Charts . We changed all the slides with the status of release or sprint. Previously, the “classic approach” was used, we made it more “agile”. This increased the understanding of progress.
It was:
It became:
Demo Leader . We have introduced the role of leader demo. This is only one presenter in the conference room who manages the demo, gives others the right to vote, keeps track of the time, agenda and uses working agreements as a management tool for the demo. Now everyone knows who is the leader and who has the right to manage the meeting.
Assistant in another location . We made one of the team members in Dnepropetrovsk an assistant of the Demo Leader. The assistant controls everything that is displayed on the screens and can connect team members to discussions. Also, the assistant manually adds Action Items to the Parking Lot so that everyone can see in real time that everything is written and written correctly.
Video Bridge . We abandoned the boring and inefficient audio conferencing and introduced a video link. The presentation and application was shown using projectors. Now, stakeholders and team members not only see the application and hear the presentation, but can effectively communicate when they see each other.
Delete technical stories . We have removed the technical stories from the demo, because they are not interesting for interested parties and can be misleading. But for everyone who wants to see them (for example, if there are technical guys among the stakeholders), a time interval is allocated immediately after the demo for their display.
Question marks . The question mark is a very quick and effective demo stop mechanism. This works better than trying to interrupt a talking person from another location.
Receiving user stories at another meeting . We made another appointment before the demo for accepting stories (using acceptance criteria defined by the product owner). The process of detailed acceptance is not interesting for interested parties - they are not interested in the demonstration of each story in detail. So on the demo we show only user stories accepted by the product owner, we collect feedback.
Fast feedback . We ask interested parties after the demo to give a quick feedback on the organization of the demo (which was good and what was not). This helps us improve the quality of the demo continuously.
Retrospective demo . We do a short retrospective after each demo. It helps to improve weaknesses.
That's all. No magic, rocket science, complex solutions - these are just a series of simple but powerful methods that helped the team become more effective in conducting the demo and made their customers happy.
This is not a complete list of what can be improved in conducting a demo. Why in Agile demo, how to conduct it effectively and much more, we reveal in detail at our trainings .
And how do you spend your demo?
Source: https://habr.com/ru/post/227707/
All Articles