Do Your Demos Smell?

Ours Did…of Fresh Hot Popcorn!
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.

User Comments

Leyton Collins's picture

Thanks Terry. I've witnessed all these smells too. The most frustrating and saddening one for me still to this day is the fourth one. It's also the one in my experience for teams new to Agile to fall into. Demos are used as opportunities to stroke each others' egos, and stakeholders if they attend are largely either ignored or placated to. What a huge waste of opportunity. A team and product release I managed a few months ago was like that. Both gladly and thankfully they realized the missed opportunities and everyone was all the happier for it.

November 16, 2013 - 9:00am
Nora Stern's picture

You highlighted many excellent points!  I particularly related to "who's driving the bus" and "representative demo data".  And I totally agree with "invite everyone".  I've seen several new applications launched on such a selective basis that it really slowed down adoption.

February 6, 2014 - 10:10am

About the author

Terry Wiegmann's picture Terry Wiegmann

Currently Quality Assurance Service Offering Lead with Quick Solutions, Inc., one of the largest privately-held IT Consulting firms in Columbus, Ohio, offering leading edge consulting services around Strategy, People, Process and Technology. Curious and passionate about exploring continuous improvement, the intersection of analysis and quality engineering, and building community by presenting, teaching and creating opportunities for others. IIBA CBAP; ASQ CSQE; PSPO; Toastmasters International ACG; Lewis & Clark Trail Heritage Foundation Ambassador. Experience crosses methodologies (concurrent engineering, plan-driven, Lean, Scrum); local and global geographies; commercial and back office software; public and private sector; custom, COTS, SaaS, products and services.

AgileConnection is one of the growing communities of the TechWell network.

Featuring fresh, insightful stories, is the place to go for what is happening in software development and delivery.  Join the conversation now!