The [Iteration] is Dead

Erik Huddleston recently wrote a provocative post on the Death of the Iteration.

He states that we mainly adopted iterations based on three (3) primary drivers:

  1. Cadence –Iterations represent a rhythm to the development process.  Rhythm through repeated routine is a critical driver of productivity and consistency of output in any repetitive task.
  2. Forcing Function – The iteration, with its short duration of typically a week to a month, serves as a forcing function to drive features to conclusion.  This forcing function also ensures that features are small and implementable in a reasonable amount of time.
  3. Synchronization – Most importantly, iterations form a natural synchronization point for stakeholders both upstream and downstream to the development process.  Small iterations reduce the risk of defects and environmental instability and shrink remediation times for defects by shortening the time that between when a change is introduced and when it can be put into a production or simulated production environment.

So why do iterations need to be laid to rest?

  1. Iterations are an unnatural concept – As the name implies, iterations are an arbitrary time slice…a line in the sand.  This leads to all sorts of technical and logistical gymnastics, that often have more drawbacks than benefits.
  2. Iterations encourage the introduction of Technical Debt – The “unnatural” and arbitrary sprint end deadline creates a few interesting behaviors in developers.  While the forcing function nature is great, it puts enormous pressure on developers to cut corners to meet the team commitment.
  3. Iterations hurt your developers self esteem – The sustainability goals of Agile are well known and critical to long term productivity of an development organization.  While the velocity metric provides a defense to burnout, the iteration introduces a couple of critical cancers to development health.

This leaves us with iteration-less development. Benefits?

Erik tells us the benefits include:

  1. Iterationless development gets rid of the tyranny of the iteration end.  This opens the door for developers (and the organization) to execute at the optimal sustainable cycle time.
  2. Cycle time has the opportunity to be reduced by removing the cycle time tax incurred by the timeboxed “boxcar” of requirements.
  3. Requirements and prioritization changes can take place at any time, without causing consternation with development.  WIP is much smaller, limiting the likelihood of a requirement change impacting an active development activity.
  4. It opens up opportunities for more diverse team organization functions like place shifted (remote) and time shifted (multiple time zones or work schedules) development.

So, what are your thoughts on this? Seeing as though there are literally TONS of books, articles, blogs, and research that support the value of iterative development, this certainly seems either anti-establishment, idealistic, foolish, or maybe revolutionary.

What do you think?

[HT: Erik]

49 Replies to “The [Iteration] is Dead”

  1. Interesting post.
    I really like the idea, but it would take a lot more than just dropping the iterations.
    For instance, how would you measure team velocity in this case? If you simply pick a date and say “we had a velocity of X points during the last week/month/whatever”, then it’s just the same as iterations.
    If you do that once you have completed a pre-defined development cycle, then what you have is a variable time iteration model.
    I would like to know your thoughts about that.

    1. You bring up an interesting point. One could look at how Kanban measures progress in stead of using velocity points. You could look at churn time, open item time, and the like.

    2. Well there is too much obsession around time: measuring velocity should not be an end and as former statistical process control specialist like Deming I do warn against harmfull measurement and Interpretation.

      As for Iteration per-se, my viewpoint is that instead of getting rid off iteration per-se, one should restore the original meaning of iteration by going back to the hidden origin of Agile. As I said, Agile did inspire from Lean which tried to restore lost Deming’s principles in Quality. For Deming, iteration is a fundamental tool of continuous improvement principle, which he reifies in his Deming Wheel or PDCA cycle. This cycle or circle is less about time or cadence but about the 4 sequences of Plan-Do-Check-Act (Correct) which should be repeated over and over again which constitutes the operational definition (also a key Deming concept) behind continuous improvement. This PDCA comes itself from the scientific process composed of Induction and Deduction phases. The reason Deming and Shewhart did invent that Wheel is Visual Thinking to make the mass understand abstract concepts in factories.

      So if people get rid off Iteration even if they were meaning cadence, the risk is that there would be no name left for the real concept of Iteration. So instead of announcing the death of Iteration, just rather kill time-boxed cycle alone but please restore the term iteration to her original meaning.

  2. Iteration focuses both developers and stakeholders on actually producing a product for the customers. I’ve seen environments that do not iterate and they often fail to ever deliver as the stakeholders change the developer’s directions on a whim. Does the iteration time line have to be the same for every sprint? No. That is the artificial part of iteration. Be more flexible in setting the sprint’s timeline and goals.

  3. Maybe I just need another cup of coffee. But, I don’t buy a few of the arguments. I’m going to limit my response to just one.

    “Iterations are an unnatural concept”.

    Though I’m a proponent of Kanban, I think iterations are very much a natural concept. I think we, as people, take to iterations quite naturally. See, time in linear. It’s seen sequentially as a series of events that are leading toward something. Even Issac Newton said time is something absolute in reality, regardless of human perception.

    Every day of your life is an iteration! So, unless it’s 2012 (shout out to all of the doom sayers), I think the iteration is very much alive.

    1. We as humans, naturally enjoy some sort of framework around our lives, doesn’t creating a framework for our work make sense too? I completely agree. Iterations aren’t dead, per se… but we need to continually inspect and adapt to find other ways that may just work as well…

  4. I think iterations are still alive, unfortunately!

    After a team becomes adept at delivering early and often in iterations, I see a reluctance to “break out” of them to go even faster.

    What is our reasoning behind keeping iterations at this point? Is it the argument that we can only do great things when faced with time boxed constraints?

    I’m probably a bit more progressive here, but I would love to coach a team to consistently commit to small stories and then break out of iterations entirely.

    We need to evolve beyond measuring velocity anyway…


    1. David, I would agree, it would be nice to be able to do away with the iteration. But I think we’re assuming we’d have teams who don’t NEED iterations. Some team members work better with short iterations, some longer, and some don’t need them at all.

      I think we’ve all had that one guy or gal on the team who, regardless of the timebox size, needs just a little more time.

      But that is another blog post…


      1. Yep iteration also provide tons of metrics like velocity that help developers to sell agile to the management. Iteration ensure we have a fixed environment that brings less interference in the gathering of metrics.

        And without metrics how can you know when you expect to finish a release?
        – You plan everything??? Well that isn’t agile.
        – You just go blind doing the best you can (I like that one :P) but you need to have serious trust with your clients and managers with guts.
        – How can you set priorities if you don’t have a relevant metric to tell you approximately how much time it takes to do things and when to expect the completion of a feature?

        1. Here’s my take on it:

          1. Velocity can be gamed, and roughly takes 2-3 iterations before it starts to be gamed by the team. Therefore it is difficult to equate it to productivity.

          2. The backlog needs to meticulously groomed and prioritized by value before you can ever imply that velocity = measure of value. Often that is not the case from my experiences.

          3. It doesn’t matter if you have 100pt velocity in an iteration if the delivered features are never used.

          It would be nice if we could evolve the conversations around iterations, velocity and done to the point where we actually measure real value delivered by the organization.

          That requires us to approach this from a different perspective… and to break out of these “rules” that were put in place to make waterfall teams see the light.

          News flash, waterfall teams already see the light now with agile, and now we have to take it further.

          No one (that I know anyway) wants to run in 2 week iterations for the rest of their career.

          1. Ah… the “gaming” aspect. Well, hopefully self-organized teams will keep each other truly accountable for their work… but I guess, rogue units can game the system… of sorts.

  5. I don’t quite understand all his points and have some doubts, I would need to think more about it, but here are some concerns/comments:

    – Technical debt is depending on how mature a agile team is. What is the definition of done, so for mature team, iterations help reduce the technical debt.
    – Hurt self-esteem, depends with how you work… Agile is more than rules, it’s a culture, principles and values and you must keep true with them. Overtime isn’t encouraged, it’s better to not deliver everything and them ask ourselves why it occurs and learn from our mistakes and learn to do better.
    – Unnatural process, I don’t agree it becomes natural when you get used to it, why no iteration would be more natural.

    – Tyranny of the iteration end??? It’s nice that things have a end so we can look at it, take time to cold down and ensure things get done and there is some engagement in deliver on time what we said we would do.
    – Requirements and priorities adjustment should occurs all the time anyway it’s just we don’t disturb the team all the time an uneducated client want something new. Change need to be consider before being apply, is it really a good idea? If these other stories got push to later is this ok? … Forcing a little time to think about change and ensure they are required is a safety net I care about. If it always occurs, maybe you should educate you clients and help him organize.

    I see iteration as a great way for agile starters to help themselves continuously improve. You need to master Agile before having the culture of it and iteration is a big part of it.

    Agile is a framework, so if no iteration suit best for you why not try it and see, although, iteration is a core value of Agile so it will obviously have TONS of unexpected impacts.

    All books, discussion on the net and training materials are done for iteration, so I would not recommend agile starter to do iteration less development if you want to be Agile. First get mature (which may takes more than 2 years) and then ask yourself why you want to get rid of iterations, since there may be other solutions.

    Also iteration brings place for continuous improvement; cold down times, learning time boxes and it is currently what our industry should work on: Refine our technical skills and best practices so mentors can train new developers and pass the knowledge of the community to a higher level. But for that, it requires time to get better, practice, try new technology, and ask ourselves if we can improve.


    1. Well said: “…iteration is a great way for Agile starts to help themselves continuously improve.” It’s nice to know what to measure against!

  6. My team started doing 2 week iterations in 2003. After a couple of years we decided it was 1) stupid to try to “commit” to 2 weeks of work at one planning meeting and 2) silly to beat ourselves up if we didn’t meet our “commitment”, because we always work as hard as we can, and the “commitment” does not make us able to perform miracles. Meanwhile, we had gotten full suites of regression tests at all levels running in CI many times per day, so every day we have a stable build.

    We decided to stop trying to plan the whole 2 weeks at once or do any kind of “commitment”. We still have iteration planning, we plan enough stories to keep us busy for awhile, we might plan a couple to have “on deck”. We pull in more work as we need it. We still have a sprint review at the end of the 2 weeks, and we still release to prod every 2 weeks. We are capable of releasing at any time, and if the business has something they want in production sooner we can release it. However the business doesn’t really have a need to release more often, in general.

    We also don’t worry about our velocity. Someone knows what it is, but nobody on the team thinks about it. Apparently once we started doing this more “lean” approach, our velocity actually went up.

      1. Yes, I did take another job for 6 months in 2009 but realized the error of my ways and came back. :-> It’s great to be able to work in one AWESOME team for so long and see the evolution of problems and solutions over the years!

  7. Okay, if it walks like a duck…etc. It’s Kanban. Why avoid using the name?

    I like Kanban. It removes the artificial dead zones caused when you try to get everyone to be ‘done’ at the same time — the end of an iteration.

    That said, I disagree that iterations are ‘unnatural’. Each day, week, month, etc. is a new iteration in life. Perfectly normal.

    1. Where I work, we keep the idea of potentially deployable versus what we really want to put in front of our customers alive. Thus we have projects that cannot get done in one sprint. But we meet specific goals at each iteration. Generally we get something before the customers every sprint, but the big stuff runs through our sprint of sprints. Thus we avoid the dead zones, by allowing for time mismatches, while still getting the benefit of success every sprint and making the bosses happy as we are at least deploying something, bug fixes or major new products, every two weeks.

  8. “iteration encourage introduction of technical debt” is wrong. Firstly, it reflects that the team cannot even decide the amount of work they feel comfortable to compete. Self-organising is the basis of any agile methodologies I heard of (or pls correct me if you think good software can be made by non-self-organising teams).

    Secondly, by having timebox, the teams need to think about ways of improving their way. A typical question is why we always test until the end of the timebox.

    Having short iterations is not the excuse of introducing technical debt. It’s about professionalism.

  9. Only one part of this bothers me (and of course kanban interests me), the troubling bit being:

    Iterations encourage the introduction of Technical Debt – The “unnatural” and arbitrary sprint end deadline creates a few interesting behaviors in developers. While the forcing function nature is great, it puts enormous pressure on developers to cut corners to meet the team commitment.

    I know it’s the standard agile pundit’s line of questioning, but are you sure this is the fault of iterations, and not the fault of people cargo-cult-ing the iteration while really pushing stretch goals instead of cutting stories down? Agile, as the art of “maximizing the work not done” and “maintaining a sustainable pace” while “getting software done through people” is not compatible with teams having commitments that they did not choose and that they cannot meet. As doc said recently, “velocity is not the problem. Do not try to fix the velocity.”

    I am happy to see other systems (perhaps better systems in some ways) but “people are cargo-culting iterations” is not a reason to stop using iterations, but a reason to stop cheating at them.

    Otherwise, nice stuff and I enjoyed it. Good work.

    1. Thanks for reading! There are a lot of “options” under Agile, right? We need not get caught up on things that people think are “make or break.”

        1. Huh… re-reading it, I may have replied to another person under your reply accidentally. Can’t figure it out!… Anyway! I agree, iterations don’t necessarily introduce technical debt, if anything I would think it works the opposite! It can show you something to measure against and improve, inspect and adapt~

  10. Shu – Ha – Ri : Follow the rules, breaks the rules (and learn), forget the rules.

    1) When starting, do iterations.
    2) After having experienced how they work, experiment with the concept and try adaptions.
    3) If you are at this point, things flow naturally and you don’t need any more advice.

    When you reach 2) or 3) – and it all works so fine for you – you may be tempted to advice others to start at this advanced level.
    But you don’t do them a good service this way.

  11. One argument for iterations/sprints: the time between two sprints (a weekend in our case) is a great opportunity to calm down and relax. Then we start full of energy into the next sprint. This helps to keep a sustainable pace.

    Oh just thought of a second argument: sprint goals are a great motivation tool. Achieving goals helps team motivation. I consider achieving a single user story not that big a goal.

    And a third: the end of iteration reminds us to focus on the most important things and simplest solution to reach the goal – no gold plating. It needs a lot of disciplin to keep that in mind without time boxes.

    1. @Urs:

      You can achieve all these without sprints – there is no coupling to sprints as such.

      Sustainable pace: Limit your WIP, apply 80/20 rule to your cycle times (to create slack) and mind your cadences. We’ve demonstrated this already by developing a product (no sprinting) over 4 years with the same team – without sustainable pace we would have burned the people.

      There are also teams that fail in creating sustainable pace when sprinting (I’ve seen this twice):

      About goals: you should set goals even without sprints (Goal for a release, goal for a feature, goal for a theme..). By studying the cadencies you can find where is the sweetspot: big enough accomplishment taking place rather frequently. From business perspective the goal usually should not even be “end of sprint” but “when value realized”.

      About goldplating: indeed, discipline is the key and transparency helps a lot. There are lots of tools to help this issue (demo available all the time, definition of ready and done, raise a flag when average cycle time has been reached, continuous deployment etc.).

      1. Marko:
        “big enough accomplishment taking place rather frequently” that sound like iteration to me 🙂 But yeah maybe it work once you get mature in agile and we may try it one day, but I wouldn’t recommend it to not mature teams in agile.

        I agree, a calm down time is required, in our case, we have 2 weeks iteration (10 working days) and inside it:
        – ½ to 1 day planning and set ourself up to be able to work
        – 1 Green Refactoring Day and last minute correction, pay technical debt, etc.
        – Day used for the review practice, review and retrospective
        – We also held a techno Friday to have continuous improvement of our skills
        – I personally don’t develop on these 3 days and every spare times is used to do readings, put in place some process or technical ameliorations or prepare team building activities.

        What do you think of that splitting? I know it may seems a lot only 7 developing days on 10, but I consider Planning, Review and Retrospectives as a must in the agile mentality.
        Which means we have between 5% to 10% dedicated to personal improvement, team training, cold down and team building. We also have a full day (10%) dedicated to pay technical debt, stabilization, technical or process improvements.

        1. @Micael:

          About iteration regarding the “big enough accomplishment taking place rather frequently” – to me it is about cadence not FIXED lenght iteration. Sometimes achieving the goal takes 2w + X days .. sometimes less.

          I also find it unnecessary to make one imaginary boundary (sprint) as in real life we have multiple boundaries (cadencies) and they have different cycle times (not 1).

          Figuring our the cadence via statistics will get you the rythm (of reaching goals), but it does not require FIXED length iteration (= sprint).

          About your approach:

          I think the “refactoring/tech debt” day is a bad idea – it concentrates all the “clean code improvements” into single time slot (big batch size) but what you also want to achieve in the code is small incremental refactorings taking place “all the time” as part of your TDD cycle. I see lots of teams calling “redesigning” refactoring as their process forces them to create unnecessary big batches of refactorings.

          1. I agree that refactoring should always occurs as soon as possible (TDD is awesome). But in my mind sometimes, we require feedback (ex: deployment, newly learned stuff) to know what is the best solution or we may think about it over later and found a better way, although older stuff is already commited and done. This stabilization period is used more to refactor some specific sections in the code.

            I don’t think having some small improvement refactoring every iteration to raise the global clarity is unnecessary. We just have to consider the ROI and do only what worth it of course.

            Also in real life, bugs occurs and we need sometimes to correct them before the end of the iteration, so we have a deliverable quality piece of software.

            For the Fixed time box, I still think it gives a value for the metrics and know what your velocity is. Also it’s a claer finish line that remind us that we need to do only what brings value the way it need to be done, no gold plating.

          2. @Mikael

            To me it sounds that your refactoring is something else than what the definition says:

            “Refactoring is the process of changing a software system in such a way that it does not alter the external behavior of the code yet improves its internal structure.”

            Maybe you could share a thing that you’ve learned from deployment and then implemented as “a refactoring” to the existing solution?

            I still fail to see why your case would need “refactoring” DAY for such things instead refactoring the code all the time as you go and learn new things.

            About bugs – what happens if the bug must be fixed but cannot (or there is hindering bug that is exposed once the first one is fixed) within the fixed spring length? Do you extend the sprint or do you move the deliverables to next sprint or maybe something else?

            I have shared some approaches about handling bugs in agile:

            About the metrics: one can have troughput metric (such as velocity) without a timebox. Simply put: number of X over a time period.

            And yet, timebox does not deny one from gold plating – it is about definition of done and transparency. Does your process force people to release what ever they have done in the end of the iteration – no matter if they feel it is not yet done or not (to avoid gold plating)?

  12. @Marko

    Reducing cycle time by reducing WIP was where my head went when I read this.

    How about having one story in process at a time and then have a “Sprint” review and Retrospective after a certain number of stories or story points have been delivered by the team?

    1. @James

      WIP limit of one is rather aggressive and may result too steep J-curve for the adoption – depends totally on your context.

      We do plannings, reviews and retros on demand. Plan when there is free “slots” on the boards, review when there is something to review, retro (or do a root cause analysis) when there is anything suspicios going on. In addition we have “fixed” 2 week retro cadence to make sure that we concentrate on improving the process (just to ensure the discipline and make ppl bring tough topics on the wall).

Leave a Reply