Maybe you love showing off your work, or maybe you dread the times when you have to present a new feature or release. In this article, I want to point out why it's a good thing if you have the chance to showcase your work, and why it's important to do it well. |
As someone involved in software development, sometimes you'll be asked to present a feature you or your team have been working on. Though the audience and goal can vary, in this article, we're not going to focus on technical presentations, onboarding sessions, or other kinds of knowledge transfer. Instead, we're going to dive deeper into so-called iteration demos.
// What is a demo?
Like many other activities on a recurring schedule, an iteration demo is a concept that was introduced as part of agile and XP methodologies. Iteration demos are recurring events, usually near the very end of a development sprint, where developers showcase implemented functionality to any interested stakeholders. Attendance may differ from project to project, but ideally, there are representatives of every team that might have a role in accepting a feature and signing off on a release.
// Why are demos useful?
The most important aspect of a demo, and in my opinion the greatest benefit, is the possibility to establish a regular, short feedback cycle. Ever since the industry has moved away from the waterfall model, the development process became an iterative activity, heavily tied to a similar design and validation cycle, so it's not rare to have requirements change along the way. The best way to avoid working too much on something that's going to need changes afterward is to get frequent feedback from the people who might solicit the changes.
Also, the demo aims to keep the team honest and help the project management assess possible resourcing needs and timeline changes. Notice how I didn't say assign blame or point fingers. Demos can help both development teams and management identify possible issues or delays, caused by themselves or others, but the whole point of having them often is to notice these issues before they grow out of proportion and cause any notable damage.
Last but not least, the demo helps the team review all the progress their hard work brought, gives closure after a sprint and allows everyone involved in creating the feature to take pride in their accomplishment.
// Why do demos often feel like a challenge?
I've found two very common reasons why developers dislike demos or at least see them as difficult challenges. I encourage you to pay attention to the underlying reasons and possible solutions if you notice yourself or a colleague being nervous about demos.
Most often it's a fear of addressing an audience. A fear of public speaking is a very common form of anxiety, and it can be difficult to overcome, but like most of these kinds of issues, it can usually be solved by taking it on head first. You can help by lending a hand to anyone who you might see uncomfortable when the topic comes up. Offer to help them prepare, or assist them by reviewing their presentation beforehand, and ask for the same if you yourself don't feel up for the task. Highlight the fact that they can take pride in the work they're showing off, how the feedback they receive is valuable, and that nobody intends to shame or humiliate them.
On the other hand, if there are toxic participants in the demos, it's a real priority to address them and make sure they understand that they're harming both the process and the team, therefore also harming the product with their behavior.
This ties into the second common reason I've noticed, fear of being criticized or feeling like you're being constantly evaluated. If you're not as far along as you'd hoped by the end of a sprint, make sure to understand and also mention the reason. Estimates can always turn out to be wrong, tasks can turn out to be much more difficult than anticipated, and everyone is aware of this. Demos give you a chance to let others know in due time if they need to find more people to help out, update timelines, and setting customer expectations accordingly.
In case early warnings about legitimate problems are met with negative attitudes, it's a pretty good sign you're in bad company. Conversely, if the team is behind schedule because of somebody slacking off, odds are the demos can either motivate the person to try harder or eventually help prune him out of the team.
// What to expect?
In case you've never participated in a demo before, here are a few things to expect that might come in handy.
You'll likely not be the only speaker. Remember to pay attention to others, you might learn things, and your insights might prove useful for them. You'll already be prepared for your presentation by the time the demo starts, so don't worry about it now, listen to the others before and after your turn.
You'll likely get questions/feedback. Don't expect a silent audience that only gives kudos at the end. The whole point is to debate any concern about the feature, so don't take feedback personally, and don't be afraid of questions. They're not meant to attack you, but to improve the product, so embrace the opportunity to find the best solutions.
You might not know everyone present. Demos are often wide audience affairs, with a lot of people checking in from within your company, from customers, marketing teams, third parties, you name it. Don't worry about it, and if you see more unknown faces than usual, feel free to introduce yourself at the beginning. Don't be afraid to politely ask people if you're not sure who they are when they address you. Knowing who you are speaking to helps you give the best response for that person.
Technical problems are a given at any gig. Screens freeze, computers lock up, internet speeds fluctuate, microphones go crazy. Never get hung up on such things, do your best to have a backup plan, but it's a common experience, so everyone will understand in case your presentation doesn't go as smoothly as you hoped.
// Tips for demoing a given feature
Now, let's take a look at what you can do to make your feature demo the best experience for you and for your audience. I've been regularly going to demos for the last ten years, both as a developer and a product manager, and I'm confident that these pointers will give you good results.
Let's start with a couple of things you should take care of ahead of time. These steps will help you be prepared by the time the demo starts.
Have a script, ideally written out in front of you. This is the best way to make sure you set your goals for the talk, cover everything you want to mention, find your bearings if you're interrupted by questions, and it also helps with time management.
Create good-looking and lifelike data in the app ahead of time. It's always a much more refined and polished experience to see someone using an application that displays credible data, instead of empty fields, random strings, and missing images. A feature demo is part storytelling, so invest in a good story to present, and you'll have the audience's attention. Consistent data also helps you find any logical issues in a flow easier.
Prepare questions for stakeholders you don't otherwise talk to often. Spontaneous feedback is very valuable, but don't forget, you're not doing a monologue. If there's anyone whose input or feedback you need, a demo is a good time to at least reach out, even if the larger discussion happens later, in private.
Pre-record a session in case a live demo is impractical. It's usually easier to do a live demo since you can accommodate any questions or retrace some of your steps on demand. That said, if there are practical reasons why a live demo isn't an option, pre-record the presentation, and practice talking over the video before the demo.
Once it's your turn, pay attention to the following:
Start by stating what you are showcasing and why. This helps set expectations, and it's also a good cue to get back the attention of listeners who got distracted from the demo before your turn came around.
Always establish the context before jumping into a feature. Step out of your expert shoes, and imagine what your talk sounds like to an outsider. Depending on the audience, you need to go into different levels of detail, but it's always a good idea to iterate through the minimum required information: what problem does the feature solve, for who, and why.
Specify whether the feature is finished or a work in progress. In case it's WIP, make sure to point out what's done and what isn't to avoid confusion, and point out any known issues. If you can present estimates for the work still left to be done, even better. Remember, setting expectations is one of the goals of a demo.
Try to walk through features in ways the end-users would naturally use them, don't worry about jamming everything in a single flow. If you need to highlight multiple aspects, it's often better to do a few different flows focusing on one thing in particular for each, rather than doing a single very complex flow with much back and forth between steps and options.
Whenever you point out something, also mention the reason why it was done the way it was. If you don't have a good reason for something it's a good sign that you should review why it's been done that way, and make sure it's not a random decision. In case it is, it still might turn out to be a good one, but you should at least make sure there isn't a better way of doing it before settling on keeping it.
// A note about being efficient
Past the pointers above, which are related specifically to presenting a feature, here are a few general aspects worth mentioning to help your delivery be as efficient as possible. Remember, demos can be long and have many people involved, so the better everyone communicates, the less time you waste.
Be aware of time. Find out how much time you'll have for your part, and make sure the script you prepare fits in the slot. If people keep interrupting or moving the discussion off track, politely note that you want to proceed to make sure you have time to cover everything important, and you can cover questions or discussions at the end, or separately after the demo.
Adjust your language to your audience. Remember, the goal is for everyone to be able to follow your presentation. Don't try to impress by using complicated language, excessive jargon, or having a quick pace, aim instead to get your message across as simply as you can.
Make it your own. I've had a very extroverted colleague who always went out of his way to make his demos entertaining, to the point where it was jokingly referred to as "The Show" by everyone. I'm not suggesting you bust out the props and start collecting jokes, but a talk is always better received when it's natural and reflects the presenter's personality, than if it's monotonous and overly formal. Just remember, it's about the feature, not about you.
Try to record the demo if nobody objects (you do need to ask for consent). This can help get the most out of the feedback you receive. It's difficult to take notes and remember discussions while focusing on presenting. As the next best thing, ask someone to take notes during your talk if a recording is not possible/practical.
>>> Summary
Even though demos can sometimes feel like a bit of pressure, try and remember all the benefits they bring. You have a chance to show off your work, get important feedback early in the process, you get to ask any important questions, and raise emerging concerns. Getting through a successful demo usually brings all the participants closer together, it boosts morale and yields valuable action items for most people involved.
All in all, even if it takes a bit of courage to battle self-doubt and fear of public speaking, I can guarantee that the effort is well worth it, and learning to give better demos over time will make you more confident and well rounded professional.
// Tamas Wagner // JULY 15 2021
Comments