We’ve had enough. We want demos that are fluid. We want demos that are fun. We want demos that work.
So my team tried something which we called ‘Demo Driven Development’ during our last sprint.
In every one of our stories, we included a task called ‘prepare the demo’. This task was only scheduled to take an hour. We just wanted to make sure the story could be demonstrated. The team also named a demo champion (me) for the iteration with some reserved time to prepare the demo. All these tasks were included in our sprint backlog.
The results were pretty good. The demo went smoothly for the most part. I did a small blunder that broke the flow a bit (sorry team) but feedback was positive during the retrospective. The team decided to keep doing the same thing for another sprint, just to see where we’d go.
To me though, the biggest change was not the demo itself but the awareness demo driven development brought. Every time I worked on a user story, I was thinking about how I could show it. The end result was that the feature was just a tad more configurable. One particular story didn’t have a UI so I made logging more readable and complete because I needed people to be able to understand what was happening.
The code was more or less the same. But the feature was better.
Some of you probably think that every story should be coded to be demo’ed anyway. You’re right, it should. But we wanted to improve in this area and it worked for us. Maybe Demo Driven Development is for you as well.
Wouldn’t it be better that every story can be deployed and actually used by an end user instead of just demoed? Seems like these will cover the demo part while not the other way around.
I normally think of Demo Driven Development as an ScrumBut. I think the risk of giving too much importance to the demo is that we might overlook other factors. Not saying this is the case, but it seems a bit risky.
Thanks for your comment Miguel.
I would like you to clarify your point about the user using the feature instead of a demo : do you mean a real customer or the Product Owner? Our demos were done with the Product Owner. Usually he had the mouse and keyboard and used the feature. However we still had to guide him, show him the strength and weakness the implementation. Our preparation was to make sure all the edge cases were covered, the database was seeded correctly and other details like that.
Which factors do you think might be forgotten by focusing on the demo?
This happened a while ago, but from what I remember the focus on the demo was for a sprint or two because we had trouble setting up the demo correctly. Our demos sucked (or so we felt). We had to get more focus on the demo. And it worked for us.