How to Run an Effective Agile Demo: A Secret Way to Build Stakeholder Trust
As a developer on a scrum team, you have likely watched helplessly as the pressure from stakeholders mounts. Despite each sprint containing a multi-hour planning meeting, and producing a Gantt or Burn-down charts, your leaders never seem to be satisfied with the progress. Situations like the one described are often due to a lack of trust.
Trust is not built only with charts and graphs, but by making work visible to management. Leadership wants to see the application they’ve invested in come to life. Although stakeholders don’t always ask for it, they want a demo.
Over the past 10 years, demos have been my secret weapon when working with teams to install an agile mindset. Regular progress in short cycles can become a rallying cry that builds the team’s confidence and the stakeholder’s confidence in the team. This visibility raises trust levels, resulting in more autonomy at work and less stress for engineers.
If you’ve never seen a demo before, you are probably wondering what an effective one looks like?
What You Should Demo
You’ll want to start a demo with the most important aspect of your project: Working Software. Working Software refers to the new features that your team has recently built. Each new piece of functionality should be demoed from a production environment—or at least production-like one.
Demoing from production means showing stakeholders completed work that’s ready for users. Displaying Working Software shifts the discussion away from “when will it be done?” to “what should it do next?”
“What should it do next?” is a great question which allows you to discuss priorities with leadership in a collaborative way. It gives them the opportunity to steer the project. In the “what should it do next?” type of discussion, your team changes from a line on a chart to a team with a track record for accomplishing work and collaborating with stakeholders.
Demos have a lot of benefits, but they are not free. They require you to work in a way where user value is the outcome of each task. A common practice in the agile community is to deliver vertically sliced stories, which includes changes to all the layers of an application. However, if your team isn’t building vertically sliced features, then demoing will be difficult. Talk with your product manager, to experiment with vertically sliced stories for a short period of time.
If your team is building developer tools, you can still demo. Even though there isn’t a clear user interface, you can show the tool’s capabilities. For example, if a tool makes it easier to deploy an application, then present the deployment of an app. Make sure to talk the audience through how to interpret any output so that they can understand what is happening. In the scenarios where the tool takes too long to run to demo, try using the Cooking Show Technique. Show the process starting, and then reveal the end result—which you prepared earlier, or creating a recording.
How To Make An Impact On Your Stakeholders
As you start to demo, you need to be aware that your stakeholder’s first reaction will be to express the desire to see more. Despite the request to see more progress can feel unsatisfying, their lack of enthusiasm is an opportunity for you to learn what they care about. You will be in a position to better cater to their needs in your next demo. When you are anticipating leadership’s needs, it will impress them. So come to the conversation with something stakeholders are sure to care about during early stages of demoing: delivering more, sooner.
Bring a list of action items that will help the team deliver more software in the next demo. The list of ways management can help, generated as a team, includes the reasons why the request will help. Some examples are: asking for help escalating a service ticket with a vendor, or requesting new equipment.
Stakeholders want the project to be successful, so ask for their help to overcome your current problems. Sometimes a solution warrants a more in depth discussion, so give the topic the proper amount of attention in a follow-up meeting. Pausing a topic for a later time (known as Parkinglot-ing) will allow you to walk leaders through the problems you see and make a case for the solution you’ve suggested.
How Often Should You Demo
You’ll want to demo working software as often as you can. If it takes three weeks to build a feature, then you should schedule demos every three weeks. Over time, try to find ways to increase the frequency of demos. As the cadence of communication increases, the number of surprises will decrease, which allows for shorter and more efficient demos.
Another thing to be aware of when scheduling demos is how they affect other people’s time. Since you are inviting leadership and other departments to see your software, it is of the utmost importance that you don’t cancel a scheduled meeting at the last minute.
Last minute cancellations take away from the trust you are attempting to build. So, remember to only invite people as often as you can confidently show working software.
Who Should You Invite
The main stakeholder of your project is probably at the top of your invite list, but you should invite other key players to the demo. Your architect, tech lead, and other team leads that your project impacts, are all great people to include on your invitation. Also, consider sending the agenda ahead of time to make sure everyone knows the purpose of the meeting, and what they will get out of attending.
When you show working software, it can increase the organizational awareness of initiatives and possibly start demos in other parts of the company, helping all teams to see the bigger picture. When the big picture is visible, teams can more easily communicate the impact of decisions to the entire company and prevent crisis situations from cropping up.
Allow for Questions
It is not enough to just show people software; you will also need to allocate time to let them ask questions. It’s important to remember this content is new to your audience, so give attendees a few seconds pause to have a chance to formulate their questions.
For remote teams, you should make sure to leave at least a 10-second pause. It will feel awkward, but it gives additional time for audio delays as well as time to craft their question.
If a question’s topic generates a discussion longer than five minutes, you should recommend scheduling a follow-up discussion (Parkinglot-ing) to make sure others can ask about different topics now. For instance, a deeper discussion on user impact, security, or architecture, are all great topics that may need their own meeting. At the subsequent session, the interested parties will have an opportunity to raise all of their questions.
Iterate on Your Last Demo
Each demo should adapt to the feedback from your previous demos. Notice the aspects of the demo where your leadership focused their attention, and try to cater your demo to their needs next time.
If last time the design was nitpicked, consider taking note to make sure the designs are tighter in the next demo. If the architect asked about your system design, consider adding a few slides to preempt such a line of questioning. By anticipating the needs of your audience, you will build more trust with each demo.
Checklist For Your First Demo
Here’s the main things you should consider when scheduling your first demo:
- Invite individuals impacted by your team’s work
- Craft an invitation that lets them know why they should attend
- Decide what software to demo
- Choose a member of your team to demo it
- Invite questions after demoing
- If questions go longer than 5 minutes, schedule a follow-up meeting
- Ask leaders for help to overcome blockers
- After the demo, have a team discussion on how the demo should improve
- Schedule the next demo
Now that you know some secrets, you are ready to start building trust with demos. By showing Working Software, your efforts will leap off those Burn-down charts by increasing your stakeholder’s awareness of the value you deliver to customers.
Best of luck on your first demo!
Glossary
- Working Software - The primary way to measure the progress of a development team. Working Software is the software that has user value, and is delivered in some iteration of time.
- Cooking Show Technique - A demoing technique where you show the beginning of a long-running process, and then show a completed version, which you prepared before the demo.
- Parkinglot-ing - A brief pause to an important discussion that will be scheduled as follow-up meeting.
Photo by israel palacio on Unsplash