Today’s development processes typically deliver information asynchronously in large batches. Flow-based processes deliver information in a regular cadence in small batches. Cadence lowers transaction costs and makes small batches more economically feasible.
Principle of Alignment: There is more value created with overall alignment than local excellence.
– Don Reinertsen
Agile Release Train Abstract
The Framework’s primary scaling mechanism, the Agile Release Train (ART), is to the program what an iteration is to the team. It follows the same pattern—plan, commit, execute, demo, and reflect—but at the Program Level where it produces system-level working software every two weeks, and full, potentially shippable increments of software every 4-5 iterations. In so doing we scale:
- The backlog—by introducing features and Nonfunctional Requirements as higher level artifacts
- The teams—by introducing Release Train Engineer, Product Management, System Team, Release Management, UX Designer and System Architect
- The timebox—scaling up to an 8-10 week timeframe
Release trains are organized around the enterprise’s significant value streams—those long-lived flows of value wherein an optimized development and delivery strategy creates the greatest economic benefit. From a lean perspective, the ART aligns teams to a common mission, schedule, and cadence and helps implement continuous product development flow.
We also note that, while it is called the Agile Release Train, and teams often do release on that cadence, it is really an Agile Development Train and programs (and individual teams on a program) can release any asset any time they meet market, quality, and other governance requirements. In other words, teams are not bound to release only on the release planning boundaries; they can release more or less often, as the market opportunities mandate.
Program Level teams, roles and activities are organized around Agile Release Trains, which provide a continuing series of incremental releases of value in a value stream. The releases may be internal and used for evaluation of the system as a whole, in which case we call them Potentially Shippable Increments (PSI/Releases). The releases may be made external—made generally available to our customers—in which case the Release label is more appropriate.
In any case, development of the software asset base occurs with a standard cadence. In the Big Picture, we’ve illustrated four development iterations (indicated by a full iteration backlog), followed by one HIP (Hardening | Innovation | Planning) iteration (indicated by an empty backlog). Many enterprises follow this or a very similar pattern, creating a potentially shippable increment about every 60-90 days.
This pattern is suggestive, but arbitrary and there is no fixed rule for how many times a team iterates prior to a PSI, or how much, if any, time or investment in hardening is required. In addition, the decision as to when to actually release a PSI, is left to the judgment of each enterprise.
Principles of the Agile Release Train
We use the “train” metaphor to communicate a few key concepts.
- The train departs the station and arrives at the next destination on a reliable schedule (fixed cadence; standard velocity, predictable releases)
- It delivers its cargo to customers (Release) or is used for internal evaluation and proof of incremental system robustness and quality (PSI/Release).
- If an Agile Team wants its “cargo” (code, documentation, etc.) to go, it has to put it there on time. The train will not come to them nor wait to get their content.
In this way, the Agile Release Train aligns the teams and helps manage risk and variability by providing program level cadence and synchronization. It is based on set of common operating principles:
- Frequent, periodic planning and release (or PSI/Release) dates for the solution are fixed
- Dates are fixed – quality is fixed – scope is variable
- Scope and schedule are determined by the teams and the program (decentralized planning)
- Teams apply common iteration lengths and standardized velocities to support program level estimating, planning and integration
- Continuous integration is implemented at the system (Program), as well as at the Feature and Component (Team) level
- Tested system increments are available at iteration and PSI intervals
- HIP iterations may be used for specialized release level validation and testing
- Certain infrastructure components, such as User Experience designs, interfaces, and common components must typically track ahead
Driving Strategic Alignment and Implementing Product Development Flow
Empowering individual Agile teams to focus on rapid value delivery typically unlocks the raw energy, intrinsic motivation, and innovation that has been stilted by our pre-Agile software models. However, that alone is not enough, as the teams will naturally tend towards local optimization. They’ll do what they can to deliver requirements to their customer constituency, but they do not necessarily have a global view. However, in the lean enterprise, the highest benefit is achieved when we achieve global optimization. In this way we can align our mass to a common direction and achieve far more force to address the targets of opportunity.
In addition, the ART is the primary Framework mechanism for implementing product development flow. As such, it directly supports the key principles. (For more on this, see reference , Chapter 15, pages 305-307)
Designing the Train
When implementing the Framework, one key activity is to determine the release train domain – i.e. who will be planning and working together, and what products, services, features, or components the train will deliver. In the smaller enterprise (or business unit within an enterprise) the domain consists of everyone on the team who will participate in the outcome. That’s the easy case.
In the larger enterprise, there may be many dozens (or more) of such teams working on different solutions, and planning everything together may not be feasible or even desirable. In that case, multiple trains will be needed (one enterprise has 18 such trains), and it may also be convenient to align them on the same boundaries, so as to facilitate the implementation of cross-program epics.
Considerations for designing individual trains include:
- Trains work best with about 50-100 people dedicated to a primary value stream
- Teams with features and components that have a high degree of inter-dependencies should be on the same train
- Wherever possible, train teams should be co-located, or as geographically proximate as feasible
(Special note: often trains spread across two primary locations, often an outsourcing location and a market-centered development center. In that case, typically planning is concurrent at both locations, sharing plans overnight).
Once the parameters and the cadence for the ART have been established, the planning dates can be fixed well in advance. This lowers facility, travel, overhead, and other transaction costs associated with the release event. Given its importance, planning and executing the release event is a project unto itself. This is covered under Release Planning
Once planned, the responsibility for PSI execution resides with the Release Train itself. Many of the specialty roles, responsibilities, and activities for keeping the train on the tracks are described in the sections below.
In addition to the Agile Teams, there are a number of key roles in this process.
- The full-time Release Train Engineer serves as the uber-Scrum Master for the train
- The Release Management Team has the relevant governance authorities to make hard decisions on scope management and to understand and plan for the market impact of a release.
- Product Managers remain directly involved as well, and they work with Product Owners to actively manage scope and quality
- The System Team integrates assets, performs end-to-end system testing, evaluates compliance with Nonfunctional Requirements, and assists with the system level demo
- UX designers and System Architects help build and apply the Architectural Runway that supports new feature development as well as providing for common behaviors, common components, and separation of concerns through APIs.
Generally the RTE reports progress to the release management team on a weekly basis, with working system software being the primary measure of progress. With proper tooling, reporting is also facilitated by the release burn down chart and feature status report as illustrated in Figure 1.
Figure 1. Example Program Burn Down and Feature Complete reports
The feature status report allows more detailed tracking of the larger features which constitute the objectives for that PSI.
Scrum of Scrums
The RTE typically runs a Scrum of Scrums meeting on a twice-weekly basis. A suggested agenda for such a meeting is described in Figure 2:
Figure 2. Sample Scrum of Scrums template
Inspect and Adapt
The PSI is “done” when the PSI time box expires. (PSIs are analogous to Sprints; when the timebox is over, the Sprint/PSI is done). Each PSI is followed by a demonstration of results, determination of the Release Predictability Metric and other qualitative measures, and followed by a structured problem solving and corrective action workshop, all as described in Inspect and Adapt.
 Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.
Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.
Last update: 14 Jan, 2013
© 2010-2013 Leffingwell, LLC and Pearson Education, Inc. All rights reserved.