Show, don't tell!

It's Not What You Do, It's the Way That You Demo It

The demo is probably the most misunderstood part of an agile/scrum development process. What should we show? To whom? How do we know if we did it well? Will there be snacks?

We will try to go over our past experience in all kinds of teams and companies and share some things we learned along the way. In order not to bury the lede, here's the conclusion from the start: keep it relevant, fun, and brutally honest.

We're Already Doing Demos

We have demos at home! Demos at home:

Yes, you are, and hopefully well. If you are happy with them, we will have other blog posts for you soon. But wait, is everyone happy with them? How do you know?

Perfect is the enemy of good. However, some patterns of pain recur in many different teams and industries. It's definitely informative, sometimes entertaining, and hopefully useful to catalog them. Let's look at some.

Show Me the Code, Show Them the Code, Show Everyone the Code

Some of us might have been guilty of this one on more than one occasion. When setting up a new greenfield project for a back-end or data project, this might be all you have. It was hard to write, and it is awesome. Why shouldn't you show it off?

You should! But to whom? This is probably the most important lesson and it applies to all other issues as well. You don't have a fixed audience! Have a pool of people you can call. Tell them ahead of time what you will show. If they are important decision-makers, reach out personally to ensure they understand why this demo will be highly technical. Many times there's a good reason.

However, if you find yourself doing a code demo three sprints in a row, the problem is not in your stars. Are you solving the wrong problem? Do you have the right audience for the demo? Could you do some end-to-end work, even if it's not the most efficient thing to do?

A sometimes useful strategy, if all you have is code, but it's really cool code, is to have a demo with only technical stakeholders. Even if they're not part of your usual audience, call them in to show off! You're not wasting their time; you're showing the great work that is being done across the organization and showing them what you're capable of. Maybe they have cool ideas that could use some technical craftsmanship.

Still, more often than not, when this situation repeats, it's a good moment to reflect and focus on what your day-to-day stakeholders need from you.

It Will Be Done When It's Done. What are we building again?

Another common situation is that you've worked for a while on something and it's laying the foundation for something important, but it's not really done. Should you demo it? What if it's the main thing you did this sprint, and a demo without it will be very light? What if this happens two sprints in a row?

Let's be honest. If this happens, you probably estimated wrongly or split the work into slices that were too big. Maybe both. Sometimes honesty is the best policy; when it comes to software, brutal honesty is always best. In fact, the degree to which your organization accepts and promotes this is probably the best indicator of future success.

So now is the time for sweet medicine. Maybe not so sweet. Does your audience want to see something unfinished (don't use weasel words; it's not unpolished/in-progress/almost done, it's unfinished)? Maybe, maybe not. Ask them! Don't decide for them. Make it clear that if the answer is yes, then in the next sprint or so they will see some nice polishing being demo-ed!

And maybe this should go without saying, but your next retro should be about how you ended up here and how to avoid it. Reach for some of that medicine again.

There's No Power in Those Points, and No Point in That Presentation

The only time you should have a slide deck is when the audience wants one. How do you know if they want one? Ask them. Not your scrum master, agile coach, project manager, business analyst, etc. Ask the audience: "We would like to just show you the awesome thing; do you want a slide deck?". If they say yes, then of course, slide away. But do ask, and ask every time.

The cheeky title (borrowed from Masood Boomgaard) aside, there is a time and place for slide decks. The place is presenting to a large number of people who need structure, and the time is the early 2000s. Trust me, if the audience wants one, they will not be shy about telling you so. But they do take time to put together, and more importantly they distract from the actual product. Remember the product?

If you need to have one, try to be clear and concise. Add simple diagrams if you have them. And always try to show the product as well. If there isn’t time, ask if they want a specialized demo at a later date.

This Sounds a Bit Negative

Fair enough, let's move away from the pathologies, although there are many more. Let's look at a simple structure and some guidelines:

• Record it if allowed! Don’t press the issue, but this can help with on-boarding new team members, allowing people to skip the demo, etc.

• Always have a demo if possible. As you plan and deliver work, always wonder how you will show this to people. We believe the demo is the most important part of agile or scrum, more important than stories, backlogs, sprints, etc. A regular demo, run correctly, will ensure a good cadence and goodwill.

• Have a regular audience for the demo, but feel free to change it with a few days' notice. Both the people who get the time back and the ones who get to see your team once in a while will appreciate it.

• Keep an online doc for questions to be added during the demo. Answer as many as you have time for, and ensure you come back to the rest, either in follow-up demos or in that document.

• Gather feedback from everyone at the demo in the following week. Honestly, do this by personal message if possible, although automation is nice. Don’t just send a form that centralizes the answers somewhere; that is too impersonal. And if you do it in person/by video, write down the answer wherever you share this with the team and send it back to the person as well. It’s easy to hear what we want to hear!

• Have fun! Not everyone is a joker, but most people can keep it light if they know it's fine to do so.