Build Trust and Confidence with Frequent Demos
Part of our approach to software development at Carbon Five is to ensure everyone is playing with the same dictionary. The start-of-project questions we all ask are common: What are the success metrics for our stakeholders? Will our customers dislike our product? But words like “success” and “dislike,” “good” and “bad” are all personal words. What they mean will change project-to-project, and even person-to-person.
It’s a common assumption that users and stakeholders know their needs, and can easily voice them. But if a stakeholder has gone through the daunting process of signing with a new team, they may well be looking to that team to define those needs for them. How do we do that?
While it’s not a match for every project, consider adding a demo to the end of your iterations — a scary proposition, but that’s the point. When done right, the benefits of regular demos are massive.
The Benefits of Demos
Demos are a time for us to show off our hard work; they reorient us towards the people who matter; and they help our stakeholders discover their opinions. Without demos, interpersonal and spatial learners will struggle to fully understand what we’re building, how it will help their day, and (critically) what our plan is missing. Especially if we’re building a rote tool, interactive demos with customers allow us to tap into their muscle memory, a very valuable resource.
Perhaps the largest benefit is the demo itself. Practice will mean the team is well-rehearsed to handle a surprise visit from important but rarely-available stakeholders. Demo deployment also adds impact to the end of our iteration. If our hot new feature missed the demo, can we say that it’s actually delivered? Continuous integration is what will keep us honest, prepared and truly agile.
Demos also help us prioritize, for example: “Iteration one of Feature A lacked impact — new analytics came back saying it’s rarely used. Let’s punt iteration two.” They may even surface forgotten problems: “An adjacent team didn’t know we’re consuming Upstream Service 1.0, and 2.0 is rolling out soon. They’re sending our tech lead new docs ASAP.” In this way, demos can be seen as a miniature beta, getting user feedback sooner in the development process, potentially saving us time working on features we don’t need.
Send the Invites
First, who attends a demo? Stakeholders and product owners are probably the most important attendants. This can be a much more engaging way to check in on how the project is going. What about developers and designers? If they were spearheading an epic that’s just been through review and has been accepted, they’re a great candidate to explain why it’s awesome. If not, maybe they can skip this round. In this way, demos can be similar to sprint grooming: not everyone needs to be there.
Open invite demos can be great — especially if a big feature was just delivered. If we’re fortunate enough to have an onsite customer or dedicated customer advisory council, inviting them to a weekly demo is certainly worth considering. However, everyone needs to be aware of what’s within the scope of our project and, more importantly, what isn’t. If attendants weren’t present at kickoff, they need context. Even if they were, remind them.
Running Successful Demos
Inherent with any line of communication, demos increase the risk of too much feedback. We may engage with a piece of criticism before asking whether it’s worth our immediate attention. This is how scope creep happens, but it’s not a problem unique to demos.
Standups and retrospectives, when mishandled, turn into calendar edema (a condition where swelled meetings have left us no time for actual work). That’s why these meetings are heavily regulated, and demos are no different.
And how do we elicit feedback while making over-corrections less likely? Remind everyone of how we’ve defined success and avoid general questions. The demo is about what we just delivered, so focus there. A tangential observation might be critical, it’s true, but that can be followed up in another meeting. Keep attention on whether the feature feels complete. Did we get snagged using it, and how? How likely are we to accidentally break it? How does this feature make us anxious? But also — how does it make us confident?
Frequent Demos Build Trust
Remember we’re not the only ones sweating. Demos can be frightening to the audience because a feature — something our project can’t succeed without — may not be built yet. What must be avoided is an overthrow of the project manager. Attendees should have a voice, but the PM has the gavel. Not only is there a plan, there’s a plan for altering the plan. No violent rebellions!
This may be the best illuminator for why demoing regularly is less scary than, say, demoing quarterly: our stakeholders are given a chance to see that, yes, Feature B was missing from Demo A, but now that we’re at Demo B — there it is. And it didn’t break Feature A. Now stakeholders know when we say Demo C will show Feature C, they can trust us.
Regular demos will be yet another meeting to juggle, so not all calendars will be able to fit them in. If this situation sounds familiar, we should at least consider demos to be another tool in our toolbelt. If we’re feeling project drift; need a morale booster; want to sanity-check against production; or even need to prep for a more important upcoming demo, let’s grab an audience and show off what we’ve built.
Interested in more software development best practices? Visit the development section on our blog for additional insights and tips!
