How Short Can Your Iterations Be?

One of the problems many people encounter when moving to agile is that they (literally) cannot imagine iterations shorter than 4 weeks.

I rarely recommend an iteration as long as 4 weeks now, and if people insist on 3 weeks, suggest they find the root cause for the reason their iteration needs to be so long. “Our builds take too long” or “our testing takes too long” are the most common problems I’ve heard. If you know what causes you to need more time, you can make a conscious decision about what to do. Do you want to address that technical debt now? or later? Every time your iteration needs to be long, it’s because you have technical debt of some sort. You can choose not to address that debt now–but be conscious of that debt.

There was a question about the length of iterations on the scrumdevelopment list. Ron Jeffries said that he and Chet regularly paired in 2-hour iterations. With our teleclass, Gil and I often pair for an hour or two. We decide in advance how long to pair for, so we timebox our time, and then we do the work.. We have daily standups where we replan what we’re doing for the day.

Does it make sense for you to have one-day or shorter iterations? It depends on who your customer is and when you can get feedback. But why not consider how short your iterations could be, and remove the obstacles to those shorter iterations? Your project will thank you.

About Johanna Rothman

I help managers and leaders do reasonable things that work.
This entry was posted in agile and tagged , , . Bookmark the permalink.

11 Responses to How Short Can Your Iterations Be?

  1. How do you deal with deployment dependencies? I’ve worked in large companies with incredibly complex architectures. And yes, that represents a technical debt, but comes with acquisitions. You can’t standardize everything overnight, nor would you want to.

    In any case, any deployment needs to be tested against other downstream applications, often three or more steps. SOX compliance is often cited as a reason for the current level of test rigidity, but in this case I agree with the intent: You can’t just push out a change without at least examining downstream impact.

    The best hope, I think, is to have fast iterations into a staging environment where changes are evaluated, then larger moves into an integration testing environment. Is this what you’re suggesting? Even this would be an improvement over the current practice, where there frequently is only one test environment.

    I just can’t picture what the process would look like that would allow daily pushes to the production environment, while still allowing time to evaluate downstream impact.

  2. Pingback: uberVU - social comments

  3. @Drew: As always, there’s isn’t only one good answer. I don’t think that there’s an iteration duration that is best for every projects. Certainly, in your case, doing 2h iterations (including your complete integration tests) isn’t going to work!

    But, if I understood correctly what Johanna said, the goal is to always try to get to the shortest iteration duration possible. Shorter iterations means you get feedback sooner and detect bugs and problems faster.

    Your idea of running two iterations in parallel, one short and one longer, looks like a good way to achieve this in your project.

    Don’t forget that agility is about being able to adapt. This also means adapting the methodologies to your needs, not forcing your project into a set specific methodologies.

  4. Pingback: Markus Tamm » Blog Archive » 25.02.2010

  5. Lovely.

    Shorter iterations give faster feedback and more chances to practice and test accurate estimating. I like to start with explicit goals and evaluate successes and failures often.

    My base goals are rapid learning, rapid progress, and rapid delivery of value to stakeholders. In each case, I put numbers on my estimates of both timing and values achieved. Shorter iterations make the retrospectives more frequent, more accurate, and more useful.

    I like to celebrate both successes and learnings from failures every day or at least every week. I like to record both in my logbook. That reminds me that if I am not having enough failures, then I’m not trying to do anything difficult.

    But that’s all my plausible fantasy that I wish I could make real. Wish me luck.

  6. Hakan Forss says:

    If you push often to production you shouldn’t have to do so much testing because you haven’t changed so much. If you don’t have automated regression tests and you are required to run the full regression suite then you should probably push to staging often and push to production less often.

    If you are bad at something, will you be better at it if you do it seldom or often?

  7. Iteration has transaction cost. If you have smaller iterations, you have larger transaction cost (meetings, deployment, etc). If you have 0 transaction cost, you can have daily iterations, but in most cases it is not true. So 1 week seems reasonable for experienced agile teams, while 4 weeks may be a very good starting point for new agile teams.

    Also batching has nice things, it reduces variability. With daily iterations you do not have this.

  8. Pingback: The case for Test-Driven Development « The Art of Software Development

  9. Pingback: pligg.com

  10. Pingback: http://www.topodkazy.cz/

  11. @michael: you might also want to decouple the delivery from the meetings.
    F ex Have a 1 week sprint, but do retrospectives every 2 weeks…

Leave a Reply

Your email address will not be published. Required fields are marked *

You may use these HTML tags and attributes: <a href="" title="" rel=""> <abbr title=""> <acronym title=""> <b> <blockquote cite=""> <cite> <code> <del datetime=""> <em> <i> <q cite=""> <strike> <strong>