In the agile world, there is a concept of “smells,” or symptoms that things aren’t going well. Introduced by Kent Beck and expanded on by practitioners, smells now describe problems involving adoption, coaching, design, code, and teams. When we see these symptoms, we can identify opportunities to improve.
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.