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. 

Barriers to Innovation

I came across this video that addresses some of the barriers to innovation at NASA.



Do any of these conditions exist at your workplace? People not stepping out of their comfort zone? Silos? A process that inhibits innovation?

I was presenting an overview of Scrum last night at the Kansas City PMI Chapter meeting. One of the things I stressed is the Scrum (and any agile approach) is supposed to be flexible; using Scrum doesn't lock you into specific steps. As the Agile Manifesto states "Individuals and Interactions over Process and Tools" Does your project management process allow you flexibility to be innovative?

Running and Scrum Planning

I was trying to come up with something to blog about and was drawing a blank. It was the end of the day and I had been doing a lot of writing for a project I'm working on, so I decided to head out for a run and hope for inspiration, and it worked.

As I was out there, it occurred to me how my planning for running is similar to the 5 levels of planning for Scrum.

Starting at the lowest level, at the start of the day I look at my schedule, family activities, the weather, and my goals for the week to decide what to do for a workout that day. This is like the daily standup meeting; what happened yesterday (did I have a hard workout I need to recover from), what's planned for today (long run, biking etc), and what obstacles are there (busy schedule, bad weather).

Moving up to the next level, my weekly planning is like the iteration or scrum planning. I set some goals for the week such as the types of workouts I want to do that week, rest days, and total amount of time I want to work out (I go by time rather than number of miles). The iteration planning is looking at the features for that iteration and planning some detail to them, while still leaving some flexibility to their execution.

At the third level is the release planning; how many iterations are going to be included in the release, dates, themes, and feature sets. I break up my year into phases, starting with prep phase, going through a base phase, build phase, and then the race phase. Each phase has a theme and dates to go with it. For example, the theme of the base phase is endurance.

The next level up is the product roadmap; what is the overall theme, the big picture for the year. This year for example, my overall focus is on running a fast (at least by my definition) marathon. All the more detailed planning works around that.


Finally we get to the vision. My vision is to continue to be a competitive athlete; in running, triathlons etc. The product vision is how the product will look in the future.

So there it is. If this planning model can be applied to my running, it can probably be applied to a lot of projects, even if they aren't following Scrum.