Becoming Iterationless


Image by Yogendra174 via Flickr

For our 4.0 release, we experimented with shortening our iteration length and got some mixed interim results.  At the retrospective to discuss our what we wanted to do with these observations for the next release, we talked about the positives, negatives, and related ideas about our ideal iteration length. The results were actually somewhat surprising.

There wasn’t a preference between 2-week and 3-week iterations so we leaned towards maintaining the momentum of the 2-week iteration.  However, our Big Information Radiator has been evolving more kanban-like characteristics (including limited queues, loose work-in-progress limits, and swarming to eliminate blockages), so when it came down to a vote between keeping iterations and moving entirely to a continuous flow system, the latter won out.  We are now iterationless.

Arguments to retain iterations:

  • timeboxes create a natural heartbeat
  • we have a high-level of predictability from week-to-week and month-to-month
  • short time horizons provide concrete milestones to help people complete work
  • it has worked well for us so far so there is risk in changing it; e.g. ‘leave well enough alone’

Arguments to adopt a flow system:

  • it eliminates the stop and start of iteration endpoints
  • flow provides another opportunity to learn and experiment
  • on-demand story estimation sessions fit better into the product owner schedule
  • it allows the product owner to reprioritize sooner if there are customer implications or commitments
  • it introduces a change to a stable system that may perturb us to a different stable point with better characteristics such as faster story completion
  • we have a seasoned team that may not need milestones to drive progress

I think this change will not be without its challenges:

  • Our minimal toolset (a spreadsheet and the wiki) has evolved to support our iteration structure.  We will need to tweak them over the next few weeks as we discover what we need.
  • Our minimal tracking artifacts are currently hand-drawn burndown charts and velocity numbers.  We will likely keep the latter but start to focus more on burn-up charts and story cycle time.
  • Our velocity calculations give us a reasonably tight envelop for probable release dates and provide a good means for planning where new features into subsequent releases.  We will need similar visibility in a flow system.
  • Iteration timeboxes provide a cadence for our day-to-day work and provide regular intervals for planning, demos, and retrospectives.  Without iterations, we will need a mechanism for maintaining these (possibly separate) rhythms.

This ought to be a fun experiment.