Why Increasing Your Iteration Length Might Be a Bad Idea

One common struggle when adopting agile (particularly in large organizations) is that it can be very difficult to get things done within a short iteration (typically two weeks). Often times, people on the team will push for lengthening the iteration to make it easier to fit things in. There are a few reasons why you might want to avoid this.

I last blogged about iteration length back in December (see this entry). There, I discussed some reasons for a short iteration and some of the fallacies behind increasing iteration length. In this entry, I'd like to focus on a major reason why increasing iteration length is likely a bad idea: the fact that you're not able to complete things in the iteration is probably a sign that you have issues that need to be addressed. By increasing the iteration length, you're hiding the problem.

There are many reasons teams struggle to deliver working software within the iteration. These reasons typically fall into three main categories: story size, organizational issues and productivity issues.

Are you taking things on in chunks which are too large? Obviously, the larger things are, the more time each one takes. Not so obviously, the rate of time increase is often non-linear. I.e., doing things in larger chunks can take longer overall. The more you take on at a time, the more that can go wrong and the more debugging you have to do to figure out what it was that did so.

In addition to this issue, smaller stories give more opportunity for feedback / adaptation based on what you've learned. Do a little, learn from it, use that knowledge to decide what to do next. It might be that areas you thought were important going in aren't and that other areas that you never thought of are.

A second reason teams fail to get things done in an iteration is that people from outside of the organization have to get involved to make it happen. Often these folks have different priorities and might or might not buy in to agile development. Ideally, you would organize so that you can accomplish goals within the team. See this previous blog entry on organizing for agility and this one on coordinating teams.

Finally, teams fail to get things done in an iteration because of inefficiencies within their processes / environment. If you've optimized for waterfall / large batches, then you'll likely need to make some changes to get things working in an iterative approach. What is slowing you down? What are you waiting on? These are the areas to focus on.

It might be an issue with delays. So and so has to buy in to this and they're unresponsive. Or this must be reviewed by a committee. Think about ways to change this. Can you eliminate this part of the process? How can you get a better response time?

It might be an issue with technology. How long does your build take? How long does it take to figure out if you've broken anything? How often / easily can you deliver the build to others? Focusing on these issues can have profound effects on your productivity. For example, if building takes 20 minutes, you'll tend to batch things up. The bigger the batch, the more you'll have to wade through if it doesn't work. Now compare this to a 5 second build where you get feedback on whether you have broken anything. Now doing a little and getting feedback becomes much more feasible.

To sum up, completing things in an iteration can be hard. Particularly if you have a history of doing things in big batches. Working through these issues can significantly improve your productivity. You might be much better off doing so than avoiding the issue and lengthening your iterations.