Since the words "Technical Demo" can be off-putting, both to the demo-giver and to any non-technical stakeholders in the audience, my teams often call them "Show-and-Tells" - they are opportunities to show progress and changes, evolutions in the system or interface, and more.
Why We Do Show-and-Tells
At the end of a Sprint, we want to pause and look back on what we accomplished, celebrate our efforts, and even to show off a little, to key people and stakeholders outside the Development group.
The Show-and-Tell time lets us do all those things. Since we do not always know what each other is doing, it is a chance to show the team. It is also a chance to show our work to the Product team, the Testers, any Support and Implementation groups, and Sales and Marketing people. It’s a great way to:
* show a finished feature
* show progress on a multi-sprint feature
* show before/after behavior of a fix
* raise questions needing input beyond tech team
The Show-and-Tell leads naturally into a discussion about the new features or fixes, with input from their perspectives about the work done so far and the next steps.
Challenges of Show-and-Tells
In a Show-and-Tell setting, we just have a few minutes of the time and attention of these other Stakeholders, so we need to be clear and to the point.
They are not technical people, but bring important other perspectives about how our work will affect our end-users. So we need to talk to them in ways that make it easier for them to put our work into their own context.
Remote presentations bring their own challenges, such as all the logistics of screen-sharing, and less feedback about audience-attention. We need to be ready for these wrinkles.
Tips for Rocking the Show-and-Tell Demo
Giving a Show-and-Tell Demo takes a set of Skills. Some people have these skills naturally, to a degree. We can all grow in our abilities and skills for demo-giving.
Tell a Story
It is tempting to dive into technical details, but the best Demo will talk about the changes from the end-user’s perspective.
* Show us how a client will use this new or changed feature
* Show the “Happy-path” first, the most common uses
* If there are important edge cases, show them next
* Do Configuration details and options need to be shown? If so, put them last
Have a Plan
You should know ahead of time what you are trying to show. Is it a finished feature? Are you showing progress and asking for guidance? Do you need to do a before-and-after of a bug fix?
* Prepare your data in advance
* Before starting, have everything you need already logged in / set up / running
* Focus the audience on what is important
* Avoid jumping out of the App - jumping away from the App they know, into a Database window or, worse, an IDE with code, is a good way to confuse your audience
Public Speaking
A Show-and-Tell to stakeholders may be to a small group of a half-dozen, or to a larger group, 20 people and up. If you get nervous speaking to a large group of people, you might find this unpleasant.
The usual tips for better public speaking apply:
* Prepare your talk in advance
* Practice
* Take deep breaths
* Go slow
* Repeat key points
* Enunciate your words clearly
* Posture and eye contact are a little different in remote calls, but it pays to make sure you are comfortable, and to occasionally look into the camera
* Repeat key points
Expect Feedback
Ideally we are showing fully completed work that has already been code reviewed and merged to a mainline branch. That way, QA and others can see it for themselves right away.
Even if that is the case, expect feedback. Remember:
* Feedback could be both positive and negative
* Their perspective can raise major issues from the client perspective, before they affect any clients
* They may offer small tweaks
* They may raise larger questions about the ticket’s specs or direction of the feature or app
* In-meeting feedback is not automatically a decision! The topic may need further thought and analysis by Product or Development teams