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 Agile Release Train is a long-lived team of agile teams, typically consisting of 50-125 individuals, that serves as the program-level value delivery mechanism in SAFe. Release trains are organized around the enterprise’s significant value streams—those long-lived flows of products, systems, solutions, or services wherein an optimized development and delivery strategy creates the greatest economic benefit. The ART aligns teams to a common mission, provides for a routine 8-12 week planning, development and retrospective cadence, and implements continuous product development flow. Each train has the dedicated resources necessary to continuously define, built, and test valuable and evaluate-able system-level solutions every two weeks, and can release software at any time the market demands.

Details

Description

SAFe program level teams, roles and activities are organized around Agile Release Trains, a team of Agile Teams which delivers a continuing series of incremental releases of value in a Value Stream. Development of the software asset occurs with a standard cadence, but trains teams can release at any time as described in Release and Develop on Cadence. Release on demand. With respect to development cadence, the Big Picture illustrates a periodic Release Planning session followed by four development Iterations, and concluded with one Innovation and Planning iteration. SAFe calls this period a Program Increment.

Special Note: This pattern is suggestive, but arbitrary and there is no fixed rule for how many iterations are in a PI, or how much time should be reserved for IP sprints. Many enterprises also choose to release software on this cadence, but releasing can also be independent of this cadence, and is left to the judgment of each train.

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, which provides for fixed cadence; standard ART velocity, predictable planning, (and in many cases, cadence-based releases)
  • All “cargo,” including code, documentation, etc., goes on the train
  • Most people needed on the train are dedicated to the train, no matter what their functional reporting structure might be

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 program increment dates are fixed
  • Dates are fixed – quality is fixed – scope is variable
  • Scope and schedule are determined by the teams via decentralized planning
  • Teams apply common iteration lengths and standardized velocities to support program level estimating, planning and integration
  • Continuous integration is implemented across all Teams on the train
  • Every two weeks, the System Demo shows fully integrated, system level, working software to key stakeholders
  • Innovation and Planning sprints provide a guard band for estimating, and dedicated time for release planning, innovation, continuing education, and infrastructure work
  • Certain infrastructure components, such as User Experience designs, interfaces, common components, and other Architectural Runway must typically track ahead

Release Train Roles

In addition to the Agile Teams, there are a number of additional key roles:

  • The full-time Release Train Engineer serves as the chief Scrum Master for the train
  • Release Management has release governance authority, can help make hard decisions on scope management, and helps plan for the impact of a release
  • Product Managers have content authority for the Program Backlog and they work with Product Owners to actively manage scope and quality
  • Business Owners have their ultimate responsibility for outcomes and have specific responsibilities for the train
  • The System Team helps with infrastructure, helps integrate the solution, performs end-to-end system testing, is capable of evaluating conformance to Nonfunctional Requirements, and assists with the System Demo
  • UX designers and System Architects help build the architectural runway that supports new feature development as well as providing for common system behaviors, shared components, and separation of concerns
  • Shared Resources assist the team with specialty services that cannot be dedicated to the train
  • DevOps is integrated with the train, and the development teams apply specific DevOps practices to facilitate a steady set of small releases

Strategic Alignment

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 it is hard for them to have a global view. But since the highest benefit comes from global optimization, SAFe applies the release train helps align mass to a common direction and achieve far more force to address the targets of opportunity.

Designing the Train

When implementing SAFe, one key activity is to determine the Value Streams and the individual release train domains—i.e. who will be planning and working together, and what products, services, features, or components the train will deliver within that value stream. In the smaller value stream (for example, a small company or a small business unit within a larger enterprise) the train can consist simply of everyone who will participate in the outcome. That’s the easy case.

In the larger enterprise, there will be multiple value streams and many such teams working on different solutions, and planning and executing everything together may not be feasible or desirable. In that case, multiple value streams will be needed, some of which will contain multiple release trains. When that is the case, it may also be convenient to align them on the same boundaries, and to provide additional Coordination across the trains.

Release Planning and Execution

Once the domain for the ART have been established, the release planning cadence and dates can be fixed well in advance. This lowers facility, travel, overhead, and other transaction costs associated with the  event. Once planned, the responsibility for execution resides with the train itself.

Reporting

Generally, progress is measured in fortnightly basis, in the form of working system software at the System Demo. Reporting is also facilitated reports such as a release burn down chart and Feature status report as illustrated in Figure 1.

Figure 1. Example Program Burn Down and Feature Complete reports

Figure 1. Example Program Burn Down and Feature status reports

 

The feature status report allows more detailed tracking of the larger features which constitute most of the business objectives for that program increment.

Scrum of Scrums

The RTE runs a Scrum of Scrums meeting, which might occur weekly, twice weekly, or more frequently as conditions require.  A suggested agenda for such a meeting is described in Figure 2:

Figure 2. Sample Scrum of Scrums meeting template

Inspect and Adapt

The PI is “done” when the PI time box expires. (PIs are the program level analogy to Sprints; when the timebox is over, it is done). Each PI is followed by a demonstration of results, determination of qualitative ART Measures and a structured retrospective and problem solving and corrective action workshop, all as described in Inspect and Adapt.

 


Learn More

[1] Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise.  Addison-Wesley, 2011.

[2] Reinertsen, Don. Principles of Product Development Flow: Second Generation Lean Product Development. Celeritas Publishing, 2009.

Last update: 22 July, 2014

Leffingwell et al. © 2011-2014 Scaled Agile, Inc.

Information on this page is protected by US and International copyright laws. Neither images nor text can be copied from this site without the express written permission of the copyright holder. For permissions, please contact permissions@ScaledAgile.com.

XSLT by CarLake