Frequency of Iterations is Related to Speed of Release

 

I’m working with a group of people who are new to iterative development. They’re doing more of a staged delivery lifecycle than an agile lifecycle, but they are releasing about once a month. They don’t like it, because they say they’re releasing too frequently.

The problem is that their planning and releasing take too long for the length of their iterations (about one month). If you release every 20 or so working days, the planning can’t take more than about a half-day. The releasing can’t take more than a couple of days. But their planning was taking a couple of days and their releasing was taking up to two weeks. Way too long.

That’s when I realized that the time it takes you to plan an iteration (or a project) has to be reasonable compared to the length of the iteration (or project). And the time it takes you to complete an iteration (or a project) has to be reasonable compared to the frequency of an iteration (or a project.)

I’ve talked about the “sweet spot” organizations have for projects. Every group of people have some default start-up and shut-down time. The combination of that plus the work inside is the project’s sweet spot. I suspect one of the problems moving to Agile lifecycles is the need to change start-up and shut-down times–which can be quite difficult.

So, be aware of how long it takes you to start something (an iteration or a project) and end it. That will tell you whether you need to change things to make your iterations successful.

4 Replies to “Frequency of Iterations is Related to Speed of Release”

  1. I’ve definitely found that to be the case. People get VERY tied to their planning processes, though, so it’s a hard pattern to break. A lot of project management tools make it hard to frame the problem interatively as well (hence the agile PM’s tendency to stick with white board and post-it notes).

  2. Do you think that the long duration (for the iteration cycle) of their planning sessions might be *because* they were doing staged delivery rather than agile delivery? I’ve found that agile keeps the loose ends tied up better, and out of my constant consciousness, than does staged. In doing so, there’s less planning that needs doing at any given point. Like using data encapsulation with an object, I can think at a higher level.

  3. Re Jeremy’s comment about PM tools – products that are designed to support predictive methods, like MinuteMan or MS Project, don’t work for Agile projects. You need tools like XPlanner or eXPlainPMT for that; or else just cards and a whiteboard.
    Re George’s comments – I think you’re right about the effect of staged vs agile delivery on planning sessions and iteration length. At our company we’ve noticed that as we try to apply Agile methods to larger initiatives, iteration length and IPM length tend to grow. One of our projects is using a 3 week iteration length, which IMO is too long for Agile development. There’s a risk that we’ll get into iteration lengths of 4+ weeks, and that would efffectively force us into RUP instead of XP. At that point you’re doing staged delivery again, and losing a lot of the value of Agile practices, even if you’re making a show of doing Agile.

Leave a Reply