A common practice in agile development is to demo your progress to your stakeholders at the end of each iteration—usually every two weeks. But I’ve worked with many, many people who are reluctant to do so. “It’s only half finished, they won’t understand,” or “It’s only back-end work,” or “We don’t have much to show,” or something else. I believe they are always wrong.

Building a trust relationship with stakeholders is hugely important—they want us to succeed, and the more we show them our work progress, including its imperfections, the more they will understand and so be able to help and steer us. And the more they can keep us honest.

I once worked with a team whose trust from our non-technical stakeholders was faltering, and much of that was because the team wasn’t demo’ing much. As a result the stakeholders didn’t feel the team was making much progress and they didn’t feel they were getting much insight into what was happening. So the product manager and I decided we would require every piece of work to be demo’d, regardless of the state it was in, and regardless of how happy the developers were to show it. Even if one of the tasks was to add some logging information, we reasoned, we could show the log lines on the screen and point to the new information. It wouldn’t be much, but would be something.

One of the pairs in the team was migrating the code from a legacy source code control system to the more modern git. Not surprisingly, they didn’t want to demo this. “They won’t understand, it’s very obscure, it’s just back-end stuff, there’s plenty that others are already demo’ing,” they said, and to be honest I was inclined to agreed with them—it almost wasn’t worth it. But we really need to restore trust, I wanted to maximise what we were demo’ing, and I wanted everyone to set an example for everyone else. I said their demo didn’t need to be more than 60 seconds, they didn’t need to prepare much, and they just needed to explain a bit about what they were doing and present a couple of screens that showed there was some actual work going on. Reluctantly, they agreed.

When it came to the demo, that’s what they did. And at the end the five stakeholders in the room didn’t really react much—I don’t really think they understood what they had just been shown. So one of them asked a question. One of the developers answered it, and that seemed to help a bit and, emboldened, the stakeholder asked another. In the end, it turned into a 20 minute discussion in which our (previously) non-technical stakeholders learned much more about what was involved in writing software, the basics of source control, and the value of branching, which was an idea that was (of course) entirely revelatory to them. They came away from that demo with a much greater appreciation of the work of the team.

If there’s no real evidence of what our teams do for any length of time then it’s very easy for our stakeholders to get concerned. After all, they’re not experts in our field and can’t make good guesses. Demo’ing our work helps keep us together.

Photo by Randall McRoberts