Enterprise Agility–The Big Picture (2): Iterations

Note: In the post Enterprise Agility-The Big Picture, we introduced an overview graphic intended to capture the essence of enterprise agility and the Agile Release Train in a single slide. In this post, we’ll describe the iterations [callout (#2)] that are the fundamental building block of enterprise agility. For elaboration on earlier numbered callouts, select the “Big Picture” blog post category.

In this post, we’ll discuss the Iteration, the heartbeat of agility. While it isn’t appropriate here to elaborate in detail on how teams achieve the iteration, Chapter 11 of Scaling Software Agility, Mastering the Iteration
is posted right here on the blog for easy access to that discussion. But for now, we’ll just focus on the Big Picture, repeated with updated callouts below.

big-picture-2-iterations1

Big Picture 2-Iterations

Iterations and the Agile Release Train

The graphic illustrates an example of the Agile Release Train concept that I described in Chapter 18 of SSA. To summarize, the Agile Teams teams are organized around a standard iteration length, and share start and stop boundaries so that the code maturity is comparable at each iteration boundary system integration point. Of course, agilists always recommend continuous daily integration (Chapter 14 of SSA) and this graphic doesn’t mean to imply that isn’t happening. However, it does gives credence to the fact that it may be quite difficult to achieve continuous integration, (including full automated regression testing) across all teams (at least early on in the agile adoption lifecycle) and at least it is forced at the iteration boundaries in this model.

Iteration Length

Iterations have a standard pattern of plan-implement stories-review (demo and retrospective). In the Big Picture,  , the iteration lengths for all teams are the same as that is the simplest organizational and management model (Chapter 18 of SSA). As for length, most have converged on two weeks as a standard length. The logic is as follows: Realistically, there are only four natural, calendar-based choices – 1 week, 2 weeks, 4 weeks, and a calendar month. Due primarily to iteration overhead (planning, demo, retrospective, etc.) and the occasional holiday, one week is too short for many teams (though I am aware of large scale systems being built in one week iterations and that length is also quite typical for XP teams). Four weeks or one month is simply too long, as there are not enough times to fail before some major release commitment. In other words, the lessons learned are too far apart to make the necessary mid-course corrections necessary to land the release on time. That leaves just one choice: two weeks.

However, you’ll also note that the graphic doesn’t call out an iteration length. I am aware of different teams using this basic Agile Release Train model that apply iterations of one, two and four weeks, respectively, so if you don’t like the two week choice, after you and I are done arguing, you can still apply the model.

Number of Iterations per Release

You may also note that we’ve illustrated four development iterations (indicated by a full iteration backlog) and one hardening iteration (indicated by an empty backlog). This is somewhat arbitrary as well and there is no fixed rule for how many times a team iterates prior to an internal or external release boundary. On the other hand, if you assume standard two week iterations and the multi-iteration pattern shown here, you’ll arrive at an internal release boundary of about ten weeks. In practice, many teams apply this model with five development iterations and one hardening per release, creating an internal release cadence of a fully shippable increment about every 90 days, which is perhaps a bit more natural and corresponds to the likely maximum external release frequency for some enterprises.

In any case, the length and number of iterations per release are up to each enterprise and in point of fact, the differences are not all that critical, so the Big Picture model is largely immune to the team’s actual selection.

We’ll discuss the Role of the Product Owner and the iteration backlog in the next posts.

3 thoughts on “Enterprise Agility–The Big Picture (2): Iterations

  1. When you first implement a 2 week iteration, you will be pushed repeatedly to change the iteration to a more longer length. This is a result of the dramatic change, the lack of appropriate build infrastructure and the fact that everything is so much more blatantly visible. While it may make sense to change your iteration length long term, don’t do it until you know for sure the basic root problems are solved.

    We are sticking with 2 week iterations. Our goal is to get to a point where we only need 1 day for demos and planning vs. the 2 we require today. We struggle from time to time but we haven’t given in.

    In addition, expect some initial slip ups. You may start with a 3×2 cadence and find out that it actually took a 3×3 to get to the level of quality needed. That was a slip of one hardening iteration which shouldn’t be a big deal. Once you can get to a 3×2 consistently, strive for a 3×1!

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s