Demo Disasters: When Product Showcases Go Wrong

In this episode of Good Intentions and Bad Outcomes, hosts Gino and Wayne explore how product demos and sprint reviews, while well-intentioned, can sometimes lead to counterproductive outcomes in agile teams.

TIMESTAMPS:
0:00 - Introduction
0:43 - Wayne introduces the topic of product demos and sprint reviews
1:32 - The good intentions behind product demos
2:16 - When demos become counterproductive
3:43 - Teams turning demos into elaborate productions
5:17 - The "no code check-ins before demo" problem
7:16 - The "fake demo" with screenshots instead of working software
9:21 - Solution 1: Clarify the true purpose of demos
11:03 - Solution 2: Show what you've done without extra preparation
11:44 - Solution 3: Drop PowerPoint and use your existing tools
13:00 - A success story: How a technical demo led to project simplification
15:01 - Solution 4: Don't wait for perfect software to demo
16:17 - Conclusion and invitation for listener stories

Wayne and Gino discuss how sprint reviews and product demos, while intended to showcase progress and gather feedback, can sometimes become elaborate productions that waste development time or turn into competitive performances between teams. They share real examples of teams spending days preparing for demos, creating presentation decks instead of showing actual software, and prohibiting code check-ins before demos to avoid potential issues.

The hosts offer practical alternatives including:
- Reminding everyone that demos are primarily for feedback, not performances
- Showing actual working software rather than presentations or screenshots
- Eliminating extra preparation by simply demonstrating what's been completed
- Building confidence to demo work-in-progress features for earlier feedback
- Using existing tools (Jira, wikis) instead of creating separate presentations

If you've experienced situations where well-intended workplace processes have backfired, share your story for a chance to be featured in an upcoming episode!

Contact us at feedback@goodintentionsbadoutcomes.org

Chapters

• 0:00 Introduction
• 0:49 Wayne introduces the topic of product demos and sprint reviews
• 1:38 The good intentions behind product demos
• 2:22 When demos become counterproductive
• 3:49 Teams turning demos into elaborate productions
• 5:23 The "no code check-ins before demo" problem
• 7:22 The "fake demo" with screenshots instead of working software
• 9:27 Solution 1: Clarify the true purpose of demos
• 11:09 Solution 2: Show what you've done without extra preparation
• 11:50 Solution 3: Drop PowerPoint and use your existing tools
• 13:06 A success story: How a technical demo led to project simplification
• 15:07 Solution 4: Don't wait for perfect software to demo
• 16:23 Conclusion and invitation for listener stories

Transcript

[0:02] Hello.

[0:02] Welcome to Good Intentions and Bad Outcomes, a podcast about challenges and practices that you might encounter in the workplace, where good intentions have unintended and often unnoticed bad consequences.

[0:15] I'm Gino.

[0:16] And I'm Wayne.

[0:18] And I'm also thankful that spring is almost here. I was able to get rid of my toque and put on my good hat.

[0:24] That's amazing.

[0:26] Every time we share a situation that we or one of our listeners have seen in the workplace that is somehow challenging. We discuss the what and the why, and we try to come up with alternatives on the spot.

[0:39] Wayne, what do we have today? What are we discussing?

[0:43] Well, I thought we would discuss a little bit about product demos, because we talked last time about progress reports. It's a good idea to show progress, and in Agile we have this idea of ending off a sprint with a sprint review, maybe with a demo of the potentially shippable increments of software that we've built.

And so lots of teams love to show off the work that they've done, so they do a demo of the product. It's a great idea, really, and it's got good intentions because we want to show that we've actually done something real and that we've made some progress. So I like the idea of doing a product demo, but unfortunately, sometimes it can have some bad outcomes as well.

[1:32] Yeah, just to be clear, that's not the only reason why we have sprint reviews or demos, right? The other reasons are, of course, to get feedback and to make sure that the assumptions that you're making related to the software or the services that you're offering—that these assumptions are also validated by the audience. So hopefully, that is a user audience or at least people who know more about the users than you might as a delivery team.

But yes, progress is an important part of it, and it kind of holds the team accountable as well to making sure that there is something to show for, right? So all of these things are pretty good, and the intentions are definitely good. So what is the bad side, the bad side of the coin here?

[2:22] I mean, I've seen some... maybe I should start. I've seen situations where, for instance, a team—similar to the progress reports that we were talking about last time—where teams are spending a significant amount of their time to set up that demo. They essentially are spending hours as a whole team making sure that there's a certain amount of data in the database, if your product uses data (and many, many do, of course).

Making sure that they will go through all of these scenarios already and making sure that everything looks clean, prepping it and even preparing the things that they would say, having a PowerPoint associated with it to make sure that they walk through all of these things. And it defeats the purpose, right? It's not really what it's intended to do. Again, what it does is it takes a tremendous amount of productive time away from the team and impedes them from making even further progress, which is not quite what was intended. So that's one that I see. What else do you see?

[3:43] Well, as you're talking about that, it recalls to mind a place where I worked at one point, and there were many teams there, and they took their demos seriously, but they fell into the same problem that you're discussing. One particular team stood out in my mind because they really turned it into a production.

They would take their sprint review and they would come up with a complete demo with music and a theme. And they would practice it ahead of time, almost like a bit of a Hollywood production. They would have speakers that would stand up and address certain parts of the demo, and it was practiced ahead of time, at least twice. So there was almost a day to prepare the demo and then a day for the demo. And there's two days out of your sprint gone right there.

And I tell you, looking at it, it was pretty fancy, but it almost turned into a bit of a competition. Who could run the best demo? Each team was trying to outdo the other teams in their demos. One had cookies and milk. The other had the music with the dance party. It was really overboard.

And you know, it made me a little angry. And you wouldn't like to see me when I'm angry. Anyway, I have to bring out my Hulk hands and just smash that down, which I don't like to do.

[5:12] Yeah, I can imagine that was far from productive, right? I've seen situations as well where there was an explicit instruction on Friday morning to not check in any code anymore because there was a demo on Friday afternoon, because they wanted to be sure that the demo would work and there were no issues.

And I—I didn't have those Hulk hands that you clearly have—but I also wasn't happy with that particular evolution and essentially encouraged them to not prepare for a demo at all. Not at all. To basically just go to a demo—and it would be a handful of people, four or five who would show up—and to become that confident that they could, before they left their desk to walk to the meeting room where the demo would happen, basically commit their last code to the repository that automatically would build, and by the time they would be at the demo, they could show off that new feature, even including the last commit that they had done.

[6:36] And there were a couple of situations where it was even possible to just give the keyboard to the user. And so like, "OK, you guys know what we're building, so why don't you just try it out and see what happens." And that was the demo. Those things are quite valuable.

So, but again, if you're blocking people from making progress because you have something planned to actually show progress, that doesn't make a tremendous amount of sense, right? So again, there are a few things that we can do to mitigate this.

[7:16] Just before you get into what you can do about it, I saw one other problem, unintended outcome, to the same good intention of having a demonstration, a product demonstration. It was almost the opposite effect where the team knew that what they had built would not run and it wouldn't be demoable.

So instead, they ran a demo anyway because they thought they had to, and they ran a demo that was basically just screenshots put into a Word document, and they said, "This is what our software does," and they just went through a Word document, and that was their demo. It wasn't really a demo of anything. It was more vaporware than it was actual working software.

So again, a bad outcome from something that was supposed to be a good intention where we want to do what's right, but we felt obligated to do this thing that really maybe didn't even make sense at that point.

[8:17] Yeah, it reminds me of a printing conference I once went to when I was still a developer many, many years ago, where the printing press that I was developing software for wasn't ready. But it printed pre-printed sheets, and the people demoing at the conference—this particular printing press—had to know very well what the scenarios were and the things that they were printing and the actions that they would do on the images in order for the demo to work.

So I was like, "What are we doing here? That doesn't make a lot of sense." Anyway, it's still a different situation because that was obviously a commercial opportunity to show off the capabilities of that particular printing press, which clearly it didn't. But in this case, there is a different intent, and the intent is to get feedback about the stuff that you have built and to essentially be able to show some progress, right?

[9:21] So the things that can be done about this—and I would start with just making sure that in front of every single demo when you're giving it, whether it is as a coach, as a scrum master, as a team lead, as a project manager, whatever your role is, as a team member (you don't have to be in a leadership position to show leadership)—is to remind everyone what this demo is for.

That the demo is not for showing off and having a full-on production, for winning the next Oscar or Grammy Award. It really is to get feedback and to steer the product into an even better direction. That's essentially what that is for. And to make sure that you get that feedback on whether or not you're going in the right direction—whether what you're building is what the customers expect, is what they need, is what they appreciate.

And it's also the most important thing that you're building for them and not just something that, well, in the end will start making sense, but right now doesn't even make sense because there's a gazillion other things that we need to be able to do. So all of that feedback you can get from a meaningful demo that does not take a tremendous amount of time to prepare. But make sure that that is clear so everyone has it in their head—both the participants and the spectators, if you will, if you want to call them that way. I call them participants on both sides: the people presenting and the people being there to provide the feedback.

[10:59] That would be my first advice. What else, Wayne?

[11:03] Well, I like what you're talking about there—how the demo should be an opportunity for feedback and not take too long. So it's not like we have to prepare for the demo. Really, all the work that we're doing throughout the sprint or for the time ahead of the demo, that's the preparation, that's the work we're doing, and we're finally just showing what we've done. We don't need to prepare a special thing in addition to what we've done. What we've done is the demo, right?

So whatever we've got—you know, say your sprint ends on Friday—whatever we've done for the past two weeks, we get to Friday, we'll show what we've done. We don't need extra on top of that.

[11:44] Yeah, I agree. And for that, I would advise anyone to drop PowerPoint, just as a start. Drop any presentation that you might potentially have for your demo. If you want to have, let's say, a wiki page where you with your team keep track of things, or you have—like we talked about Jira already—you have a Jira board that shows what things are in the right column, which would mean that these are complete, and you go over those. This is enough.

Like, show this and show the people who are attending your demo that these are the things that you have worked on, and these are the things that you will demonstrate. And that is your schedule, that is your timeline. You can walk through this. You don't need to create a separate PowerPoint, and you have not wasted anyone's time, and it encourages you at the same time to use the tools in the way that they're intended and to make sure that the description in your Jira is meaningful for everyone who attends. So there's only benefits to that.

[12:50] Yeah, I can think of one project that had a really good outcome from an unintended effort around a demo. It's kind of the opposite of what we're talking about.

[13:06] So they held a demo regularly because they wanted to make progress, so they had a good intention. And one of the great things that came out of this was—because some people hesitate to show a demo because they haven't quite got it working yet or there's nothing really to look at, is what the complaint is. "We haven't produced anything that's visible, so people are going to have a hard time understanding it. It's going to be mostly technical."

But this team didn't let that stop them. They showed sort of the technical architecture that they had worked on early on in the project. The customer was actually there, had a look at this, and they were actually building out an API that would have a front end that would call it. The customers saw this and they saw the development on the API, and they said to themselves, "You know, we have systems that can call that API directly. We don't even need the front end that you're going to build. Just give us the API."

So they were actually able to fulfill the customer's needs with only building half the project. It took them half the time and half the money. They could eliminate a whole unnecessary piece, but it was because they discovered this from feedback from the customer during the demo. So it was a really good outcome from that good intention.

[14:16] Yeah, and there you see—I mean, this is one thing that I believe is important to recognize as well—any outcome can be demonstrable, right? But you need outcomes to be things that can be exercised from the outside. And if you're using something like Postman to exercise a certain API and you demo your application that way instead of building an expensive front end that users need to use—if the purpose is really the functionality that's behind this API, then that's a very valid way to do this, and clearly that's demonstrated in your story.

[14:55] OK, fantastic. Anything else before we close it off?

[15:01] Just one other thing I want to mention that I've seen—sometimes teams are a little bit hesitant to show software that's maybe not complete yet. And so there's this idea that we have to produce this really fully functional, very fancy-looking product, and we may be hesitant to demo it.

That's OK. We don't have to have a perfect piece of software in order to do the demo. All we're looking for is that feedback that you are talking about there. So actually, the earlier you get that, the better your product's gonna become in the end anyway. So don't be afraid of demoing a piece of software that's in progress.

[15:42] Yeah, and just make it clear in the beginning, right, that you don't get the feedback specifically on this—like, "I want this to be in our company's colors." Like, "OK, well, we're not there yet." So better to get this out of the way by just saying it upfront.

[15:56] OK, fantastic. That's it for today. I hope you enjoyed the conversation. I definitely enjoyed seeing Wayne's fists there. I've never seen those before.

If you have a situation at work in the past or right now that you feel has unintended bad outcomes, please let us know and we might discuss it in one of our future sessions.

[16:17] Thanks again, Wayne.

[16:19] Thanks, Gino.

[16:20] Bye-bye.

[16:21] Bye-bye.