Demo, Demo

The Team is ready with their sprint! Yesterday afternoon, a room was booked, a big screen was arranged for, and The Team frantically knotted the last loose ends to have a nice and shiny demo.
Not all features were demoable, of course. The sprint was not entirely finished. Some things couldn’t be demoed because the parts using it weren’t there yet. Some things couldn’t be demoed because nothing visible had changed. But for those, some really nice PowerPoint slides were prepared.
So now the demo starts. And who’s attending? Well, The Team is, of course. But despite the very compelling e-mail invitation sent out to just about everybody in the company (who matters, anyway)… nobody else showed up.

Luckily, not all demos are like that. Demos are your chance to show off, to let the stakeholders, the business, and management know that you really achieved something. And it usually makes them very happy to see something working.

But why is it so important to have demos? And how can you make sure you have well-received demos that don’t take forever to prepare?

Don’t Move Deadlines

“The story is almost finished. Can’t we demo on Friday?”
“I’d rather work on this story than waste time on a demo!”
“If we move the deadline to Monday we can have 20 story points done instead of 10.”
“Who knows we have a demo today?”

Scrum is made of fixed-length sprints. If you have three-week sprints, you have a deadline every three weeks. The sprint demo helps to keep the deadline fixed.

But having a demo can be difficult; it may feel like a waste of time, especially if nobody showed up last time. If not everything is finished, the demo can be embarrassing. But not having a demo is worse. Demos shape your sprint, and the shape of your sprints determine the success of your team.

Sometimes it can be very tempting to move the deadline a couple of days; it will allow you to finish a bit more and prepare a bit better. Although that might be true, it is a bad idea to move deadlines. Moving deadlines tend to move forever; if you start shifting it into the future, it will be very hard to fix it again. And then the whole idea of a clear, crisp break between this sprint and the next will be gone.

Deadlines Are Seldom Internal

Once you have revealed your schedule to anyone, people will start relying on it. After all, you committed to doing those stories in this sprint, so your stakeholders, business people and managers will expect you to finish on that day. It will be much easier for them to adapt if you tell them “We did this, this and that, but we didn’t start this and that,” than if you tell them “We’re still working on it, it should be ready any moment.”

Velocity Needs a Timebox

There’s another reason to stick to your deadlines: the team’s velocity is meaningless if your sprints have different lengths. Velocity is an important planning tool. Actually it is the only statistic about productivity a Scrum team produces, but if used correctly, it is the only thing you will ever need. Provided, of course, it is accurate.

A sprint demo makes a deadline much more strict, as it will be at least embarrassing not to have the demo at the set date. So book your demo meeting at the beginning of the sprint (or have it at the same time and place after every sprint.) It doesn’t hurt to create a bit of pressure for the team.

It’s Fun to Finish Things

Deadlines are good for the team as well. It is much more fun to clean the board, throw away the stories, wipe out the sprint burn-down chart and start over with a fresh new sprint planning meeting than to linger on the old stories. It gives a feeling of accomplishment to clean the old stuff, and excitement to start the new. The clearer your boundary between old and new is, the better the feeling.

Don’t Let Deadlines Woosh By

The team’s demo was scheduled for Friday, but on Wednesday Greg was still investigating the performance improvement that didn’t work. When Geoffrey asked his help for the synchronisation feature, they suddenly realised they couldn’t do both; but with the performance improvement implemented only halfway, actually nothing was working at the moment.
At the end of Thursday, Greg finally checked in his code. But now the reporting was broken. And fifty-odd tests failed. And the demo was tomorrow morning.

It’s not easy to meet your deadline. It requires discipline to really finish your work, and good planning to do that at the set time. The good thing about Scrum is that you will have deadlines often–you get a lot of opportunity to gain experience.

Minimize Work in Progress

To have a clear and simple demo, your work needs to be done. If a story or task is really done, it’s usually easy to demo it. If it is just nearly done, it can be very difficult to show: you don’t have a clean install, you have to work around unimplemented bits, or it fails in front of the audience. So the key to a good demo is to finish all your work. Now how do you make sure your work gets done?

It helps a lot to have clear focus. Work on as few tasks in parallel as possible. Finish a story before you take on the next one. Each finished story makes a good demo; each story in progress is blocking another one from being finished.

Don’t Commit to Too Much Work

It sounds obvious, but it can’t be repeated often enough: don’t take on more work than you can do. Be very strict in what you can take into your sprint. Don’t fool yourself, and don’t fool your stakeholders.

It may be tempting to take in more work, because it will please your stakeholders. But they will no longer be pleased if the work isn’t done in the end. Apart from that, if you know you cannot finish all the work from the beginning, you will lose focus on the work you can do. And then you will end up with a lot of stories started, but none finished.

On with the Show

“Well, guys, we have our sprint demo tomorrow. What are we going to show?”
“We have the new service implemented, but we cannot really show that, because the client isn’t ready yet. Then we did the performance measurements, but the tests took three days to run, so we cannot demo that. We implemented the performance improvement for the reporting, but the reports didn’t change… And we fixed the display bug! But that was already released to production, so we cannot show the difference with the old display, because we don’t have that anymore. I can mock up some screenshots…

Some features are easy to demo, and some are not. If you created a new button that does something, pressing the button in front of the audience is a convincing demo; they can see what it looks like, how it works, and, not unimportant, that it works.

But how do you demo something difficult? The key is to realize who your audience is: your stakeholders. They understand the feature because they need it, so there is not a lot to explain. The most important thing to show in a demo is that it works.

Make a Demo Plan

Although finished stories are usually easy to demo, that doesn’t mean your demo comes for free. It is a good idea to start thinking about what you can finish after three-quarters of your sprint, and about what you can demo one or two days in advance. After all you will be presenting it for a room full of people.

Have a quick meeting with the team to come up with a demo plan: for each story, decide how to demo it, and what needs to be prepared. Let the team decide who will prepare and demo what; if everybody picks a story to demo, the preparation can be quick and in parallel. Testers can do good demos sometimes by just running the tests, if the tests can be followed and understood by the audience. If you can get your users to demo a new feature it is even better!

Some demos are best done in pairs. One person does the clicking and typing, while the other one talks. This makes both the clicking and typing and the talking more fluent. It is difficult to do both at the same time. It also forces you to think a bit about your demo in advance, instead of improvising completely.

Make sure you have a nice introduction, you know what to show, and what to tell. Check out the room where you have the demo for availability of a projector, a screen, network cables, wall outlets, or anything else you might need.

Avoid PowerPoint

Presentations are nice, but demos are much nicer. Don’t show a picture of what a screen looks like if you can show the screen itself. The most boring demos are endless presentations about what has been done without showing the actual result. Think again: what are you showing on those slides? Can you show it in real life?

There is a time and place for everything, even for PowerPoint. You can use it for a short introduction about your sprint, showing the stories done and maybe some statistics, and you can use it if you have tables and graphs of test results, for instance. But always value demo over presentation.

Wiki Pages

Do you have a wiki for your team? Consider creating one. A lot of good, free wiki software is available on the internet. All your statistics and information about Scrum can go onto your wiki, but you can also use it for test data and test results. It is actually quite possible to run a demo using your wiki.

Wikis have several advantages:

  • Wikis won’t go away, and are easy to find, compared to documents and e-mails.
  • It is easy to fill the wiki as the sprint progresses, instead of creating a presentation just before the demo.
  • You can use a wiki for much more: design sketches, documentation and manuals, the product backlog, team members’ details, …
  • Wikis usually have versioning built-in, so your documentation will be as safe as your source code.

Wikis and Scrum fit together very well.

Shorter Is Better

Demos don’t have to fill the entire meeting that you allocated for it. If you can show some working software in five minutes, you did a fantastic demo.

Do you write client and server software? Then it is very well possible you can demo two (or more) stories with one press of a button. If you can show what the user will experience, there is no need to explain what is happening behind the scenes.

Save the time to answer questions from the audience. Or even better, save the time to have the audience themselves play with the new feature. There is one thing even better than demoing working software to people: giving working software to people.

Sprint Flow

A good planning, a fixed size sprint, a nice demo: those ingredients will lead to a happy sprint flow. The team will get used to a rhythm in each sprint. First, you get acquainted to the work to be done, think, design and find solutions. In the middle period, most of the work is done. And last, you tie up all loose ends and deliver the working software. The sprint flow is actually quite soothing. In each period, you know what is expected. And except for the last few days, there is little time pressure.

You can make a graph of the pressure, or the work load, in a sprint over time. Each phase has its characteristics; together it forms the waveform of sprints. The predictability of the phases makes the team very productive. There is time pressure, but not too much of it; there is no uncertainty about what needs to be done. There is a period of just working, that is short enough not to become boring or unfocussed. And after that, you celebrate with a demo, you make the stakeholders happy and well-informed by showing them working software, and then you look back and improve.

Demos play a key role in this. The pressure in the team builds up because they know they need to do a demo. And the feeling of accomplishment afterwards is much stronger when you show your work to your stakeholders. This sets the team up for a good retrospective and another successful sprint.

Sprint Demos: Getting It Right

“Where’s your demo? Weren’t you supposed to do a demo?”
“We had that five minutes ago. But here’s the URL of our application. Try it out yourself!”

A good demo is nice to do; showing new and shiny features to stakeholders makes everyone happy. The key to a demo like that is that you are prepared for it.

To get into the habit of doing good demos, do it the same way every sprint:

  • Schedule your demo meeting immediately at the beginning of the sprint.
  • Minimize work in progress during the sprint.
  • Make a demo plan: what to demo, how to demo it and who will be demoing what.
  • Show working software.
  • And remember: short is good.

Don’t put a lot of time in preparing the demo meeting itself, though. Prepare by carefully finishing your stories. That is what the demo meeting should be made of: demonstrating finished work.

And that is why it is always useful to have a demo. It gives you an incentive to really finish things. Only then it will be fun to demo it.

A very powerful side effect of demos is that they shape your sprint. They form the mark that the team is heading for all the way. And if done well, they are the exclamation marks that end the sentence on a high!

Leave a Reply

Your email address will not be published. Required fields are marked *