Time for a Demo?

When I first learned Scrum, the idea was to have 30-day (4 week) iterations with a demo at the end of each iteration. Today I see teams that have iterations from 1 to 4 weeks, or in the case of Kanban, no iterations at all. So the question is, how often should there be a demo?

I’m a believer of getting sign off on a user story once it's done. This usually comes from the person who wrote it, who may be a proxy to the product owner. So when we get to the end of the iteration, all the stories that are completed have already been reviewed by someone on the business side but not necessarily the product owner. 

So the questions is, If it’s a short iteration, does it make sense to have a more formal demo of the stories? I think in some cases the answer is “no.” 

On one of my projects where we were using Kanban, we planned the demos every 4 weeks. This allowed us to finish a set of stories that were part of a feature, so the demo was more complete. I think this approach works with short iterations as well, only conducting the demo after every second or third iteration, depending on how long your iterations are and how complex your features are. 

There's also another consideration. I work with clients building applications that will get rolled out to the organization. On these projects, we need to consider organizational change management. The demos serve as a way to help introduce the new application to the end users. So from this perspective, there may be a large number of attendees at the demos. This is another argument for less frequent demos.

So while a demo can be held at the end of every iteration, even for short iterations, there are some reasons to hold them less frequently. 

Tools

When I was young, I had a riding lawn mower. We had a big yard out in the suburbs and the riding mower made the job quicker. Today I live closer to downtown in a house with a smaller yard. I’m currently using an old fashion reel mower…no motor, just foot power to make it work. For the yard I have, it’s all I need.

With all the technology around us, it’s easy to get caught up in the latest thing. Tools can make us more effective, but sometimes they can be distractions. 

Take project management tools. There are a plethora of them around and I have used them effectively on projects. But I have also run projects with just a white board and stack of post-it notes, not letting the technology get in the way of interacting with my team.

The Manifesto for Agile Software Development says it should be “Individuals and Interactions over Process and Tools” so ask yourself if the tool you are considering is going to help you or could it just be another distraction? Put another way, A fool with a tool is still a fool."

Minimal Viable Product

I have a customer with a challenge. We've been working on an application and finished our first release. The business folks looked at it and came up with a list of "must-have's" they want before going live. The IT folks are pushing back, trying to keep additional work to a minimum before going to production. They even threw out the phrase "minimal viable product" or MVP as a way say what's the least that can be done.

However, MVP isn't about doing the least amount of work and calling it done. When taken in context of Lean Startup, it's part of a process. First you build the MVP and hypothesize what you think will happen when you go live, you measure against your hypothesis, and ideally learn something that takes you to the next step.

When I work with customers used to a more traditional approach to projects, I often see resistance to the MVP approach. They think they have one chance to get what they want, so they ask for everything. If they truly thought in terms of MVP, they would be able to think about it as what do they want first, knowing they get a chance to ask for more.

In some cases, the next step may not be in the same direction. In Lean Startup, there's the idea of the pivot, making a more fundamental change in direction. Groupon started as an online activism platform and PayPal started out building security software for handheld devices (think Palm Pilots, not smart phones). There are plenty of other examples out there of companies that didn't get the results they expected and made a pivot. Lean Startup is about getting to that point as fast as you can.

For my customer, we're going to time box another round of development, make them prioritize the must-haves, and then hopefully go to production, so they can see it they are moving in the right direction. Are you ready for your next step?