To those who want to hack it together just to make the demo work - please slap yourself

I'd like to talk a bit about the sprint demo today. Jimmy Bogard has an interesting post about letting the customer drive the demo. I think this a great idea, particularly later in the project cycle. I'd like to respond to this post a bit as well as bring up a few ideas of my own about the demo. First, a brief overview of the demo and its place in Agile.

On all other projects we demo only a few times, but on this project we demo every sprint

So part of Agile is that working software is the best metric for progress. We also favor customer interaction and communication. I view the demo as the ultimate way to realize these things. First, it allows you to show your working software so that people can see what has been done. This is much better than progress reports, lines of code, cyclomatic complexity, and TPS reports (make sure you use the new cover sheet). You're also showing your software to the customer, so you're interacting with them and communicating what you've done. In turn, the customer can tell you how well you're doing in meeting their needs. This way, you can ensure that the project is always on the right track and change what you're doing if the customer changes their mind or (more common) realizes that what they asked for wasn't what they actually needed.

The demo isn't that important though

So the demo is a great way to show your progress and get rapid feedback on it. However, the demo is not an excuse for cutting corners just to be able to show off features. Let's say that you're working on a story and it's about half finished. Let's say the half that's finished is the data access portion of the story and that the UI is not yet complete. You don't care about that though, you want to demo this new feature, so you spend like 20 minutes and create an awful hack that implements a crappy use interface. That way, you have something to show.

That sucks

You've now accrued technical debt (more on this in another post), because instead of having something good that you can build off of, you're going to have to wipe out everything that you've done and start over. Or you're going to base your development off of a hack. Or you just never fix the hack because you don't have time. This makes your application less maintainable and harder to test (if you're hacking together application code, you're probably not going to write tests for it right?) and this will be a future problem. If you just do this in one little place in the application, that's not so bad. But it's a long, slippery slope and it's a dangerous habit to get into. My point is that the demo is not important enough to sacrifice good development practices in order to have a better demo. If you can only get part of a feature working, just show that part. If you need an extra day, push the demo back. Just think of a problem like this with the demo as another change that you need to respond to.

Letting the customer drive the demo is like letting a 16-year old drive a Ferrari

So Jimmy Bogard's idea is to let the customer drive the demo instead of development. He says that in practice he's getting better feedback, the customer is less bored in the demos, and the customer feels that something is really getting delivered. Read his post because I think he has some excellent points.

I'd like to point out, however, that the customer can find ways to crash the app that you never dreamed of. Especially early on in development. They also tend to ask "why" a lot, like "why doesn't that link work" and "why can't I add a customer to a group yet" and so on. In fact, I've found that early on, customers only see the incomplete parts of the features. You know, the ones that you have stories for that you haven't picked up yet. They don't care that you can save a customer and that it works on a distributed system running Oracle and Sql simultaneously accross a 56k WAN, they just see that there's no option for selecting a group for that customer. They're going to complain. They're going to crash things. They're going to make the demo long and painful.

This is just like letting a 16 year old kid drive a ridiculously powerful car; they're going to break it and it's going to be catastrophic because they don't know how to drive it yet. However, if you start them on a Pinto or something, then they'll gradually improve and be able handle a more powerful car (like a Volkswagen) and so on until they're driving a Ferrari without killing themselves.

So don't let the customer drive the demo. Yet.

While there are some great benefits to letting the customer drive the demo, it's a very dangerous thing early on in a project. They're going to break things. They're going to see the faults instead of the features. The feedback you get will probably just make you wonder if you're supposed to salute Captain Obvious indoors. Later in the project, your customer will definitely have things to say and they'll be more familiar with the application. Once that happens, they'll be able to drive effectively, they'll look past the few little things that still aren't working quite right, and they'll learn how to give good feedback during the demo so you'll get some benefits from letting them drive. Just don't rush out there and try this on your next project's first sprint demo because I believe that you're asking for trouble