As a developer on a scrum team, you have likely watched helplessly as the pressure from stakeholders mounts. Despite each sprint producing multi-hour planning meetings, and Gannt or Burndown charts, your leaders never seem to be satisfied with the current progress. This common situation is due to a lack of trust.

Trust is not built only with charts and graphs, but by showing management what you are building. Leadership wants to see the application they’ve invested in come to life. Though no stakeholder asks for it, they want a demo.

A demo is my secret weapon when working with teams that are attempting to install agile. By showing them changes at a regular cadence, it becomes a rallying cry that builds their confidence in the team. This boost in trust levels results in more autonomy at work and decreases the stress of 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 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 that allows you to discuss priorities with leadership in a collaborative way. It gives them the opportunity to steer the project. In this type of discussion, you are no longer a line on a chart, but a team with a track record for accomplishing work.

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 build vertically sliced stories, which include all the layers of an application. However, if your team isn’t building vertically sliced features, then demoing will be difficult. In this case, you should try talking with your product manager, who may be open to experimenting 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. 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.

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. Although this can feel unsatisfying, their lack of enthusiasm is an opportunity for you to learn what they care about, and how 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 they are sure to care about during early stages of demoing: going faster.

Bring a list of action items that will help the team deliver more software in the next demo. This list should be generated as a group, and crafted to include only the items that leadership needs to help the team with, along with the reasons why it 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 executing the solutions to your problems. Sometimes a solution warrants a more in depth discussion, so give the topic the proper amount of attention in a follow-up meeting. This technique will allow you to walk leaders through the problems you see and make a case for the solution you’ve suggested.

How Often To Run A 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 list. 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 you all 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 think about their question.

If a question’s topic generates a discussion longer than five minutes, you should recommend scheduling a follow-up discussion 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 his questions. 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:

1. Invite individuals impacted by your team’s work
   • Craft an invite that lets them know why they should attend
2. Decide what software to demo
   • Choose a member of your team to demo it
3. Invite questions after demoing
   • If questions go longer than 5 minutes, schedule a follow-up meeting
4. Ask leaders for help overcoming blockers
5. After the demo, have a team discussion on how the demo should improve
6. Schedule the next demo

Now that you know some of the secrets, you are ready to start building trust with demos. By showing working software, your efforts will leap off those Burndown charts by increasing your stakeholder’s awareness of the value you deliver to customers.

Best of luck on your first demo!

If you enjoyed this post, please follow me @soonernotfaster for updates on when new content is posted. Thank you for reading and happy coding!

Photo by israel palacio on Unsplash