Most Agile Teams Have Two-Week Iterations

June 23, 2015

Scott Ambler

 

 

In the 2015 Q1 Agile State of the Art Survey we asked how long the sprint/iteration length was for agile teams.  The figure below summarizes the results.  For the team who were following an agile lifecycle the survey found that two thirds of teams had a two-week iteration length, and that over 90% have iteration lengths of three weeks or less.

 

 

The general consensus within the agile community is that shorter iterations are generally better than longer ones, as we saw in this survey. There are several reasons why you want to have short iterations:

  • Reduced time to market.  The shorter the iteration, the more often you will have a potentially consumable solution (or in Scrum terms “potentially shippable software”) that you might choose to release into production.
  • Reduced feedback cycle. The shorter the iteration the more often you will have an iteration demo, increasing the opportunities for feedback from your stakeholders.
  • Reduced risk. The shorter the iteration the shorter the amount of time that your team can get off track until it would be noticed by your stakeholders.
  • Reduced bureaucracy. The iteration length puts a cap on the amount of time that you can invest in a given activity.  For example, if you have a two-week iteration then your team is unable to tolerate a three-week review process and instead is forced to find ways to fit that activity into a two week time frame (or better yet find ways to get rid of the activity entirely).

 

Over the years we’ve heard several rather questionable excuses for why teams believe need to have longer iteration lengths:

  • Regulatory compliance.  Regulatory compliance generally requires teams to hold more reviews and create more artifacts.  So do these things in a lightweight agile manner.  Furthermore, read the regulations because it’s incredibly doubtful that they require you to work in an onerous, heavyweight manner.
  • The team is large. The increased risk of a large team implies that you should find ways to decrease that risk wherever you can, and one way to do that (as you saw above) is to keep your iterations short.
  • Outsourcing.  Outsourcing can be an incredibly risky endeavor, and the best way to decrease that risk is to increase the collaboration opportunities between the customer and the service provider.  Part of that strategy is to have very short iterations, preferably one week in length, so that the customer organization sees on a regular basis what is being produced by the service provider.
  • We’re special.  It’s human nature to think that you’ve got it harder than others, that you’re in a more complex situation, that for some reason you’re special.  You’re not.  There are other teams out there in much more difficult situations than you face and they’ve managed to figure out how to have shorter, less risky iterations.  You can too.

 

The fact is that the only valid reason that we’ve seen for having longer iterations is that your team is new to agile.  In these situations you’re still learning the fundamentals so naturally you’re going to be going a bit slower at first.  Our advice is to get some solid training in disciplined agile approaches and support from a qualified disciplined agile coach.

© 2015 Scott Ambler + Associates