Letting the customer drive the demo

At the end of an iteration, we have a demo to the customer (and any interested stakeholders) of functionality delivered in that iteration.  Something I hadn’t tried until recently was letting a user or customer drive the demo.  There were some minor issues with this approach, but overall I really liked the outcome.

Original approach

Normally, iteration demos went something like this:

  • Show completed story cards/feature lists
  • Drive through some canned scenarios
  • Try to hit every story completed
  • Collect feedback as we go

While this accomplished our goal of showing the completed product and soliciting feedback, this approach had a few problems:

  • People got bored watching developers use the product
  • Developers don’t use the product like actual users do
  • Scenarios were geared towards showing features, instead of real user paths
  • Paths were driven away from buggy parts of the system, and centered around “happy paths”

Customers felt like they were being shown a list of features checked off, instead a system that was incrementally better than the one shown at the last demo.

Customer-driven demo

Instead of a developer driving a demo, we tried letting the customer or a user drive the demo.  Of course, the guinea pig needed to have some familiarity with what we delivering, but the user chosen was always one that was involved with our iteration.

I was more than a little skeptical of this approach, but once I saw it in action, I think it will be my default style for iteration demos.  The benefits we saw were:

  • Demos doubled as user acceptance testing
  • We collected far more meaningful feedback seeing actual use
  • Customer felt in control of the demo, so boredom was greatly reduced
  • Removed some “us vs. them” mentality
  • Removed notions of “you’re not using it right”

But perhaps the biggest benefit was that the customer felt something real was delivered.  Demos are a time for us as developers to demonstrate that we were accountable for what we committed to deliver.  If developers give the demo, there’s a hint of bias in what is shown, where we could hide areas that weren’t quite done.

While our system only has one type of user currently, I could see demos in the future where each persona in our system is a different person driving sections of the demo.

Since the feedback gathered, verbal and observational, was of much higher quality in this style of demo, I’ll use this style as much as possible.

Related Articles:

Post Footer automatically generated by Add Post Footer Plugin for wordpress.

About Jimmy Bogard

I'm a technical architect with Headspring in Austin, TX. I focus on DDD, distributed systems, and any other acronym-centric design/architecture/methodology. I created AutoMapper and am a co-author of the ASP.NET MVC in Action books.
This entry was posted in Agile. Bookmark the permalink. Follow any comments here with the RSS feed for this post.
  • http://blog.perfectapi.com Steve Campbell

    Great idea – I think I’ll give that a try ASAP.

  • http://agilology.blogspot.com/ Jeff Tucker

    Great idea and great post, but I think this is something that you have to be careful with. I’d wait until at least a few sprints into the project before letting the customer drive. I have a few opinions on the demo myself and rather than post a blog in your comments like I did in the past, I blogged about it here: http://agilology.blogspot.com/2008/03/to-those-who-want-to-hack-it-together.html