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.
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.
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.