Iteration Management – Post #2 – What’s an iteration anyway?

This post is a part of a series of posts about iteration management. If you want to start from the beginning, go here.

OK, if we’re going to talk about something called “iteration management”, we first should discuss what an “iteration” is. Turns out there are lots of different ways to deal with iterations, so I’ll go over some of the common ones.

Time boxed iterations (the Scrum way)

When most people think of an iteration, they think of a set period of time in which you perform a series of activities and then you do it all again in the next iteration. This is what you usually find in Scrum-based agile environments (doesn’t mean that you have to do textbook Scrum). In a Scrum-based environment, an iteration usually goes something like this (more or less):

1a. Capacity planning – determine how much work we can get done in the iteration
1b. Sprint planning – meet with the business and the team to figure out what to work on, maybe estimate tickets
2. Do the work
3. Demo/UAT
4. Maybe release to production, or at least say that a set of features are complete
5. Retrospective – team meets and talks about what went well, what didn’t, what to change, etc.

The length of an iteration is up to you. I’ve seen people do anything from one week to a month. The shorter the iteration, the less time you’ll have between production releases (if you’re releasing to production each iteration). With longer iterations, you often fall into the trap of doing a bunch of work and then trying to test it all at the end, which ends up being a testing nightmare (now you’re Agile team is just doing mini-waterfalls).

My favorite is a two week iteration. Sure, it would be nice to release to production every week, but I’ve found that the business likes the two week cadence of the process, and they get used to being involved at certain points in the process every two weeks. It also gives you more time to get the work done instead of having more meetings dictated by the process (since you only have those meetings every two weeks).

In the iteration-based model, your metrics are usually measured by the iteration. (For example, how much work can we get done in each iteration?) This model works well when you have a project that you need to complete by a certain time. You need to know if you’re on track, if you need to devote more (or less) people to project to get it done on time, you need to estimate work to know how long it’s going to take, etc.

Continuous flow (the Kanban way)

In this model, you don’t have time-boxed iterations. You just have a backlog where work comes to the development team at any time and they just work on whatever is most important. You might release to production on a regular schedule, or you might release whenever you feel that you have something significant to release. Some teams might even release to production multiple times a day.

The goal in the iteration-less model is not to see how much work you can get done in a certain amount of time. The goal is to see how quickly you can move a ticket through the process (we call this “cycle time”). The idea is that we want to minimize the time between when a business person has an idea and it becomes a reality.

This model works really well for teams that are doing maintenance work or production support (i.e. you aren’t working on a project where people need to know when the project will be done). Things like capacity planning and estimation start to feel like cruft in a situation like this, and it’s much simpler to just bring work to the team and do whatever is most important. You can still have regularly scheduled activities (e.g. demos every 2 weeks), but the process is much more fluid and free-flowing.

Which is best for you?

Only you can answer that! There are no rules on how to do this. I encourage you to think outside the box and come up with whatever works best for you. Regardless of the method, here are some things that I think are important that you should consider:

• How can I most quickly diagnose problems?
• What works best for the stakeholders, management, and the business?
• What allows us to best handle (and even encourage) changes in priorities?

Most of the rest of this series is going to focus more on the time-boxed iteration method of developing software. Many of the ideas will still apply to the flow-based approach, but the time-boxed method is more involved and has a lot of interesting nuances that are worth talking about.

Read the next post in this series, Card walls.