The Agile Release Train, Strategic Alignment and Product Development Flow

In this blog, in Scaling Software Agility, and in my forthcoming book on Agile Requirements, I’ve been writing fairly extensively on the implementation of the Agile Release Train (also see whitepaper derived from the book)  as a means of achieving both strategic alignment and product development flow in the larger software enterprise. It is hard to overstate the importance of the Agile Release Train in how it helps the enterprise achieve product development flow. I spend a lot of my time helping enterprises achieve the benefits of this model.

Recently, I’ve been reading (and rereading) Don Reinersten’s new book The Principles of Product Development Flow: Second Generation Lean Product Development. This book may be the best book on product development I have read in a decade. I strongly recommend it to anyone who finds my blog or the topic of scaling software agility of interest.

In addition to the depth of content, and its simultaneously light, yet rigorous, (is that really possible?) economic and mathematical treatment of flow, I like the way the book is organized around eight major themes of product development flow. They are:

1. Take an economic view

2. Actively manage queues

3. Understand and exploit variability

4. Reduce batch sizes

5. Apply WIP constraints

6. Control flow under uncertainty – cadence and synchronization

7. Get feedback as fast as possible

8. Decentralize control

For a meaningful discussion of these themes, I refer you directly to Reinertsen’s book.

Mapping The Agile Release Train to Reinertsen’s Themes

Perhaps not surprisingly, the Agile Release Train maps pretty directly to Reinertsen’s eight primary themes. Understanding this mapping is the key to understanding the criticality and motivation for the ART itself. So to make it easy for you, I’ll map them in this post:

Product Development Flow Theme 1 – Take an economic view.
The ART’s incremental releases substantially improve the ROI of software development by accelerating the release of value to the customer. This helps capture early market share and drives gross margins by delivering features to the market at the time when the market values them most highly.

Product Development Flow Theme 2. Actively manage queues.
The short, frequent planning cycles of the Agile Release Train actively manage queue lengths:

Team backlogs (queues of waiting stories), (see the mildly controversial post on this topic ) are generally limited to about the amount of work that can be accomplished in a single release increment (Or Potentially Shippable Increment). Planning much beyond that is generally not very productive for the teams, because teams know strategic priorities could change at any release boundary.

Release backlogs (queues of waiting features) are typically limited to those features that can realistically be implemented in the next release or two. Beyond that, product managers understand that they may be over-investing in feature elaboration for features that will never see the light of day.

Portfolio backlogs (queues of waiting epics and future projects) are typically limited to those epics that could likely find their way to release planning in the next six months or so. Too early, or too in-depth investment in business cases for those projects that will not be implemented is a form of waste.

Product Development Flow Theme 3. Understand and exploit variability.
Since a high degree of variability is inherent in software development, frequent re-planning provides the opportunity to adjust and adapt to circumstances as fact patterns change. New, unanticipated opportunities can be exploited by quickly adapting plans; critical paths and bottlenecks become clear and resources can be adjusted to optimize throughout through the bottlenecks and better avoid unanticipated delays.

Product Development Flow Theme 4. Reduce batch sizes.
Large batch sizes create unnecessary variability and cause severe delays in delivery and quality. The ART reduces batch sizes by releasing only those features to the development teams that are prioritized, elaborated sufficiently for development, and are sized to fit within the next release cycle. This avoids overloading the development teams with significant number of longer term, parallel development projects, which may or may not ever see the light of day, and in any case cause multiplexing, overhead, and thrashing. The transport (handoff) batch delay between teams is minimized as well, as face to face planning facilitates high bandwidth communication and instant feedback.

Product Development Flow Theme 5. Apply WIP constraints.
In release planning, teams plan their work and take on only the amount of features that their velocity indicates they can achieve. This forces the input rate (agreed-to, negotiated release objectives) to match capacity (what the teams can do in the release). The current release timebox prevents uncontrolled expansion of work; so the current release does not become a “feature magnet” for new ideas. The global WIP pool, consisting of features and epics in the enterprise backlog, is constrained by the local WIP pools, which reflects the team’s current backlog driven by the current release increment. When WIP is too high, lower value projects either a) never make it into development, or b) are purged during, or just prior to, release planning.

Product Development Flow Theme 6. Control flow under uncertainty – cadence and synchronization.
Planning – The release train planning cadence makes planning predictable, and lowers transaction costs (facilities, overhead, travel.) Planning can be scheduled well in advance, allowing participation by all key stakeholders in most planning events, making face to face information transport reliable and predictable.

Periodic re-planning (resynchronization) allows us to limit variance and misalignment to a single planning interval.

Releasing – The cadence and synchronization of regular, system-wide integration provides high fidelity system tests and objective assessment of project status at regular intervals. Transaction costs are lowered as teams invest in infrastructure necessary for continuous integration, automated testing, and deployment.  Since planning is bottom up, (performed by the teams and based on teams actual known velocity) and short term, delivery becomes predictable. Most all that has been planned should be reliably available as scheduled.

Product Development Flow Theme 7. Get feedback as fast as possible.
The fast feedback of the iteration and release cycle allows us to take fast corrective action. Even within the course of a release increment (or PSI), feedback is no more than two weeks (or the iteration length) away. Small incremental releases to customers allow us to track more quickly to their actual, rather than anticipated, needs. Incorrect paths can be abandoned more quickly (at worse, at the next planning cycle).

Product Development Flow Theme 8. Decentralize control.
Release plans are prepared by the teams who are doing the actual implementation, rather than by a planning office or project management function. Commitments to the plans are bottom-up, based on individual’s commitment to their teammates and team-to-team commitments reached during the planning cycle. Once planned, the teams are responsible for execution, albeit subject to appropriate lightweight governance and release management. Agile project management tooling automates routine reporting; management does not have to slow down the teams to assess actual status.


That’s it for this post, though I expect I’ll visit the topic again, as it’s certainly going to be a major theme of the next book. In the meantime, you might want to read Reinertsen’s new book, as it’s available now.


One thought on “The Agile Release Train, Strategic Alignment and Product Development Flow

  1. Nice mapping and description of key points of the book. Makes me eager to actually read it 🙂

    But this post is overall a good reading for a team, because most of these themes make you wise team, minimizing the gap between efforts and actual results.

    I would say keeping WIP under strict control and continuously (re-)planning is sort of rare virtue unfortunately and requires real team discipline. And another thing – getting rapid feedback is even more like that. Here’s funny story, the statistics I didn’t even expect: few months ago when I asked big audience (~60-70 people). I asked two simple questions: 1) How many agile team representatives here in this room (many raised hands). And then 2) How many of you consider iteration acceptance by PO as your very primary performance indicator as a team (two hands only!). Many teams think they are agile but don’t even have or will to have actual PO and interact with him/her as an ultimate “sanity guarantee”… they just work.

    …Speaking of which… not everything on this list is primarily POs domain. Obviously Themes 1 and 7 are on POs shoulders, but others are to PO + Team.

    Nice post!

Leave a Reply

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

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

Google+ photo

You are commenting using your Google+ 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 )


Connecting to %s