Do Your Demos Smell?

[article]
Ours Did…of Fresh Hot Popcorn!

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.

User Comments

2 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 Lead of the People Service Line 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. www.quicksolutions.com. 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; Scrum.org 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, TechWell.com is the place to go for what is happening in software development and delivery.  Join the conversation now!