(This is the second post in a series about software demos - some of these even went well.)
There are all styles of demos ranging from very informal walkthroughs with other peer engineers on your team to more scripted scenarios that are recorded for later replay using software like Camtasia and made available on the interwebs. With Agile, we now demo the stories that we developed at the end of every 3 or 4 week sprint in front of all the project stakeholders (all internals but representing various disciplines on the team such as Development, Test, Product Management, Services, etc).
Sometimes you need to demo new functions to external paying customers. Now with external customers, you need to be on your best behavior for obvious reasons. So even if they ask stupid questions or offer feedback and criticisms that are off-base, you have to keep it respectful and professional:
- That is an interesting way of looking at that problem, but…
- You could do it like that and it is possible that may work, but…
- Let me make sure I understand what you are saying….
Most external customers are just like us. They are under all kinds of the same schedule and cost constraints and pressures. They are mostly also all competent and easy to work with. Just like with internal demos though, there are also several classes of problematic demo attendees that you might come across:
- The Grudge Holder is pissed off at your team (and company) because of problems they have encountered with your product in the past or with other products they have purchased from your company in general. These people will find a way to take shots at you and there is not much you can do except separate the information from the emotion and be sympathetic.
- The Know It All thinks you aren’t even worthy of their time and so challenge you on every little aspect of the software you are demoing. They like to push buttons to see if you are competent, but usually will back off once you can show them that you actually know what you are talking about.
- Loves To Hear Himself Talk just basically has to say something. Frequently. In every meeting. Whether what he has to say is worth hearing or not. You have to be pro-active with Loves To Hear Himself Talk or they can wreck your demo.
Last fall I was asked to demo some new Configuration Baseline functions in our 721 release to one of our external customers. I encountered during that demo an individual combining the Know It All and Loves To Hear Himself Talk.
This guy was basically asking a question after almost every scenario and user interaction, just killing the pace of the demo and hindering the conceptual model of Baselines that I was trying to roll out. Once decoded, the questions weren’t that difficult to respond to, but they all would have been covered in due time over the course of the demo. So I kept finding myself having to respond with “A little later on we will show how that is accomplished” or “I’ll get to that in a couple of minutes”. Usually, that would stem the flow, but not with this guy. I could also pick up that he had a pretty high opinion of his own technical chops. You know the type.
We weren’t even 5 minutes into a 30 minute demo when he launched into this multiple minute monologue of questions that I struggled to follow. One of those deals where about a half-dozen unrelated concepts and questions emerge and you are left shaking your head, wondering how the hell to respond to that mess or where to start. Dude was all over the place, but I sort of picked up that he was confused about a couple of fundamental concepts:
- Whether all Configuration Items in the Baseline need to be connected to one another via relationships.
- Whether cyclical paths can exist between the Configuration Items in the Baseline,
So once the dude actually stopped talking, I paused for several seconds for dramatic effect and returned his serve with this volley:
A good way of looking at a Baseline is to view it as a directed graph of Configuration Items captured at a point in time. While a Baseline would typically be used to represent a connected digraph of related components (like a database server and its supporting software and hardware), you should realize that disconnected CIs may also be included in a Baseline. Oh, and cycles are permitted among the connected sub-graphs in the Baseline. Did that address all of your questions?
Damn! What can I say? I was bored. Little joys for little boys? I don’t know how I pulled that out of my ass unrehearsed, but it flowed out with such precision, confidence, and technical correctness that, had I not been alone in my office, would have jumped up and looked for a fist-bump from a peer engineer. I rendered Chatty Cathy speechless. Boo-yah!! BTW, its not like that was rocket science stuff – elementary terms that one learns in the Introductory to Data Structures that used to be taught in Computer Science curriculums.
In over 25 years of engineering in industry, I can’t recall having to make much use of the Graph Theory that I learned in my Computer Science courses at Pitt. But, damn, it was nice to be able to summon that from the nether regions of my brain when I really needed it. Major props to Alfs Berztiss
