The Agile Architect
Crafting the Perfect Agile Demo
Our Agile Architect leads you through all the things that go into making a perfect agile demo.
It’s time for your big agile demo. Last week’s demo, the first for your project, went poorly. As your team slogged through each story card, showing everything that was done in detail, you could feel your audience’s attention wandering. You covered everything completely. More than completely, really, because some cards overlapped, which meant you ran through the same functionality multiple times. When you finally finished demonstrating the last story card, the audience muttered collectively, “Thank you.”
And off they went. No feedback. No indication they liked what they saw--or didn't. The only emotion expressed was ennui and a desire to get the heck out of there.
But this time, it’s going to be different. This time, you’ve built a smooth presentation, weaving the story cards into a single narrative, walking the participants through all the affected workflows. And you’ve practiced until you have a crisp, concise delivery. As the crowd shuffles in, you think to yourself, “This is gonna be great!”
You begin the demonstration, and everything goes exactly as planned. You get through the demo in 15 minutes. Smooth as silk and still plenty of time for lots of questions. With a flair and great confidence, you end the demo with, “Thank you. We're ready for your questions now.”
And… silence. Again. Then, after a few beats, “Looks great!” someone says. “Nice job,” says someone walking out the door. And then you hear: “I have a question.” You smile. Finally!
“You scheduled this for an hour, but you only took 15 minutes. Can you please change this meeting going forward to only 30 minutes?”
You sigh as he gets up and heads for the door.
What is the purpose of the agile demo?
We give many different kinds of demonstrations during our careers. We show off our products to potential customers. We might make an online video for the masses. We show our investors our progress so we can continue to receive funding. We demo new features for our users. Maybe we show our families what we’re building. But perhaps the most important demos we conduct in an agile environment are our weekly demonstrations to our stakeholders.
Why? This is where we get feedback on what we're building. Recommendations and suggestions have the greatest leverage, given how early they're received in the development process.
The question, of course, is how to construct the demonstration to get the most value out of it. So first, let’s talk about the value we want from our demo.
Agile Demo Value Top 10
10. Show off our wares and excite our development team and participants
9. Get real-time feedback from our participants on how we're building the product
8. Give our participants a chance to tweak features before they're finished
7. Give our participants a chance to experience the product
6. Give our participants a chance to imagine new features
5. Give our participants a chance to kill a feature in development
4. Give the team a chance to set a goal of what to demo next time
3. Give the development team and participants an opportunity to have a structured discussion on what to work on next
2. Give the development team and participants an opportunity to come together in free-form discussion and ideate on the future based on the shared learning from the demo
1. Celebrate the success of our work
How not to give a demo
At the beginning of this article, I illustrated two examples representing opposite ends of the spectrum of how not to give a demo:
- Go through every story and bug in excruciating detail so you lose the attention of the participants
- Be so perfect that there is no room for the participants to engage and ask questions
But there are others:
- Gloss over everything so the participants don’t get a deep enough understanding of what’s been built to be able to ask any meaningful questions
- Be so technical that you lose the interest of your participants
- Talk the entire time so no one has an opportunity to ask a question
How to give the perfect demo
Now I know what you are thinking: You've told me a lot about what not to do, but what should I actually do?
There’s no simple answer to that question, and a lot depends on your participants. You know them; I don’t. But here are some things I’ve found useful:
- Don’t dilute the focus by showing under the hood. It doesn’t matter how the features are implemented from a technical perspective. You can go over that in a technical review. If you spend time on the technology, you lose valuable time needed to get feedback on the features you built.
- Encourage the participants to interrupt and ask questions. One of the worst things you can do is to ask them to hold questions until the end. If you do this, you are missing the point of the demo. The point of the demo is not for you to demonstrate the brilliant things you’ve done. It is to get feedback on how you can do better and/or different.
- Plan for breaks during the demo to give the participants time to think and ask questions. You want to welcome feedback, not be afraid of it. In some ways, a good demo is like a good test. It’s not an affirmation that what you did is correct. It’s an opportunity to find out how to do better.
- Use powerful questions to solicit feedback. Not “yes” or “no” questions but “how” or “what”, compelling the participants to think about a more complete response. “What could we do to make this feature more compelling for our users.” “How will we know we are getting value out of this feature?” “Where do you see our users having difficulty using this feature?” ‘Which kind of user will use this feature?” “How does this feature as implemented match your original vision?” “What can we implement better for the next demo?”
- Give the users control. Let them play with the product. Give them a task to do based on the stories completed. Let them drive the demo instead of the product owner or development team.
Final Thoughts
An agile demo should not feel polished. The more space you provide for the participants to interact, the more valuable the effort. You’ll notice in the column that I never refer to the audience. I refer to participants. There is no audience. Everyone in the room has a role to play and needs to be an active participant. The more you can encourage this, the more value you will derive.