On my last project team, we turned routine demos of working software into special occasions by doing fun things, such as hanging a few movie-premier-themed decorations, having access to a carnival popcorn machine, or using seasonal holidays for themes.

In the agile world, there is concept of “smells” or symptoms that things aren’t going well. Introduced by Kent Beck and expanded on by practitioners, smells now describe problems with adoption, coaching, design, code, and teams. When we see these symptoms, we can identify opportunities to improve. Here are some demo smells I’ve gotten a whiff of over the years:

They’re Called “Show and Tells” Rather than Demos
Why give people flashbacks of grade school? If your customers are in primary education, this might be ok; otherwise, you could be on a slippery slope away from “working software” to showing your stakeholders “almost” completed pieces and telling them how you think it’s going to work. “Show-and-tell” could imply one-way communication: we’re doing the showing and the telling. The point is to show working software, so do it!

The Same Team Member Conducts the Demo Every Time
The purpose of demoing working software is to get buy-in for it or discuss needed tweaks. Rotating the demonstrator or “driver” builds collective ownership (another agile principle). Even more powerful is having the product owner or a business stakeholder conduct the demo, showing how an idea went from backlog request to completion.

Developers Don’t Attend the Demo
The creators miss out on hearing the “Oohs” and “Ahhs” when the audience likes what they see. Perhaps more importantly, they miss hearing the questions that could lead to a better user experience, such as layout or navigation, or concerns about other interdependencies that need to be explored. Saying “They don’t have time” is no excuse; ensure your capacity planning accounts for demo time. This is one of the core events in agile practices—make time for it.

While it is great to have developers in the demo, it is important for them to resist the urge to answer questions, provide lengthy explanations, or start to solve a problem right there in the meeting. Answering a question that has a quick answer is fine; if additional explanation or background is needed on the item but is not necessary for the rest of the demo, just convene a breakout session immediately after.

Product Owners, Stakeholders, or Sponsors Don’t Attend the Demo
When engaging your product owners and stakeholders early in the project, make them aware of the time commitment for demos and get them scheduled as quickly as possible so that the time is blocked on their calendars. Start and end on time, but schedule enough time to go through the entire demo with time for discussion and feedback. The demo is one of the highest-value practices in agile; give it the time and attention it needs.

It is important to have representatives from all of the groups, departments, and teams being affected; ideally, more than one so they can discuss it with each other. Think of these folks as your “advance guard” sharing the excitement about the new app and preparing for the changes it will bring about.

If there are missed expectations, then note them accordingly and follow up immediately after the demo. Do not get into a contentious discussion or blame game. Thank the attendees for their feedback so they feel heard and  welcomed to offer it going forward. Any feedback other than saying “This is exactly what I wanted!” highlights the lack of common understanding about the functionality.

It’s an Endurance Race Rather Than a Show
Configuration depends on your facility layout, but whenever possible, the driver should stand at the front of the room and present the demo rather than sitting among the audience. Otherwise, the driver can’t see attendees’ body language and questions aren’t solicited; the driver just continues on to the next item. When the driver looks at his own screen, tracking the movements of a mouse with his eyes is second nature. It can be frustrating for the audience who has to search a large projected screen to find a little mouse pointer they are not accustomed to be looking for as the driver says “All you have to do is click here.”

When there is a whiff of a sentiment akin to the phrase “Let’s get this over with,” the driver tends to talk faster than the audience can listen and assimilate the new material they just saw and formulate questions about it. Also, the person controlling the screen needs to talk more slowly than normal so everyone can follow along, especially those viewing from remote locations or if the presenter has a different accent or speech cadence from the audience.

That’s Too Many People to Invite
How many people are “too many” to invite to a demo? If you are constrained by room size or conference bridge capacity, this might be understandable. But including only a few key people does not foster collaboration, excitement, and ownership; instead, those who were not included but will be impacted will feel excluded and undervalued. Why not reserve the auditorium or biggest room available?  Or project onto the biggest blank wall in the facility.

One of the key demo practices is to “invite everyone,” increasing transparency into what the team is doing across the organization. Narrow rather than broad attendance means missed opportunities to identify and capture the comments of folks who say “Oh this will save a lot of time” or “This will be a big adjustment;” comments like these have huge organizational change and training implications. If feedback is difficult to collect due to the number of attendees, explore mechanisms to collect the feedback and respond appropriately. For example, if attendees are attending remotely, you could ask for a point person at each location.

We Don’t Identify with the Audience; We Need to Help Them “Get It” by Pre-Answering Their Questions
If you struggled to understand a complex environment or domain, anticipate that your audience will struggle to understand how your new system will fit into the world they know. Before the demo, as a team, take some time to reflect back on the questions that you had to face and share your learnings with your audience. Build your audience’s confidence in themselves and in you by supplying what they need to make the most of the demo; diagrams, tables, or quick reference information. Don’t succumb to the curse of knowledge and become tappers (for more information on that, Google “tappers and listeners”).

Use two projectors—one driver can drive the app while the other can be prepared to show supplemental content, such as context or workflow diagrams.

Demo Data Is Not Representative or Is Distracting
Using comic-book characters or silly names for demo and test customer names might be amusing for us, but could be off-putting for some audience members. If you will be showing user names, use “business-possible” names rather than Mickey Mouse or the names of competitors of the client. If your users could potentially see an error message, use that opportunity to tell them how to resolve the problem rather than having them view a “stupid user error.” 

Better yet, think about how to prevent the users from making the error! Keeping the demo data representative of their real world enables your audience to focus on the application and builds credibility by showing you “get it.”  If you need sample narrative content, use a lorem-ipsum text generator. Maybe you’re bored with lorem ipsum and want to embed your own cleverness? That’s understandable, but if you won’t have time to do demo-data cleanup, consider not putting it there in the first place.  

Who’s Driving the Bus?
Leave the “stage” or front of the room empty only if you are going for a dramatic effect. If you are the ringmaster or Master of Ceremonies for the demo, it’s your show—own it. Facilitate, moderate, monitor, and keep things moving. If you are sitting among the audience, it’s difficult to read faces or body language to detect confusion, questions or impatience. And the audience experiences a weird sort of Wizard of Oz effect when they hear a voice but don’t see who’s behind the curtain.

Speaking of Error Messages…
When an unexpected error shows up on the screen in front of fifty people it can be embarrassing. This can be minimized by baking quality in the code, but it can still happen to anyone at anytime. Anticipate this situation—you might even rehearse it so that the driver doesn’t panic or get derailed from the course of the presentation and is able to recover gracefully.

If the demo doesn’t feel like a celebration, then that is a smell. This should be a proud moment for the team – they have delivered working software. Customers should be delighted—or at least happy. Ensure that everyone applauds at the end of the demo—have the team start it and others will join in. Celebrate the wins. Try a “Shout-out Shoebox” by creating a container that anyone on the team can drop a note, which thanks someone or calls out something they did that helped and made a difference; read them at the end of the demo.

This is your party—be a great host! Think about what would make your guests comfortable and encourage them to come back.

Me, I’m off to find more napkins for that buttery popcorn!