The more alignment you have, the more autonomy you can grant. The one enables the other.

—Stephen Bungay, Author and Strategy Consultant

Agile Release Train

The Agile Release Train (ART) is a long-lived team of Agile teams, which, along with other stakeholders, develops and delivers solutions incrementally, using a series of fixed-length Iterations within a Program Increment (PI) timebox. The ART aligns teams to a common business and technology mission.

Each ART is a virtual organization (50 – 125 people) that plans, commits, and executes together. ARTs are organized around the enterprise’s significant Value Streams and exist solely to realize the promise of that value by building Solutions that deliver benefit to the end user.

Details

ARTs are cross-functional and have all the capabilities—software, hardware, firmware, and other—needed to define, implement, test, and deploy new system functionality. An ART operates with a goal of achieving a continuous flow of value, as shown in Figure 1.

Figure 1. The long-lived Agile Release Train

The ART aligns teams to a common mission and helps manage the inherent risk and variability of solution development. ARTs operate on a set of common principles:

The schedule is fixed – The train departs the station on a known, reliable schedule, as determined by the chosen PI cadence. If a Feature misses a train, it can catch the next one.

A new system increment every two weeks – Each train delivers a new system increment every two weeks. The System Demo provides a mechanism for evaluating the working system, which is an integrated increment from all the teams.

The PI timebox is fixed – All teams on the train are synchronized to the same PI length (typically 8 – 12 weeks) and have common iteration start/end dates and duration.

The train has a known velocity – Each train can reliably estimate how much cargo (new features) can be delivered in a PI.

Innovation and Planning (IP) – IP iterations provide a guard band (buffer) for estimating and a dedicated time for PI planning, innovation, continuing education, and infrastructure work.

Inspect and Adapt (I&A) – An I&A event is held at the end of every PI. The current state of the solution is demonstrated and evaluated. Teams and management then identify improvement backlog items via a structured, problem-solving workshop.

Develop on Cadence. Release on Demand – ARTs apply cadence and synchronization to help manage the inherent variability of research and development. However, releasing is typically decoupled from the development cadence. ARTs can release a solution, or elements of a solution, at any time, subject to governance and release criteria.

Organization

ARTs are typically virtual organizations that have all the people needed to define and deliver value. This breaks down the traditional functional silos that may exist, as shown in Figure 2.

Figure 2. Traditional functional organization

In such a functional organization, developers work with developers, testers work with other testers, and architects and systems engineers work with each other. While there are reasons why organizations have evolved that way, the value doesn’t flow easily, as it must cross all the silos. The daily involvement of managers and project managers is necessary to move the work across. As a result, progress is slow, and handoffs and delays rule.

Instead, the ART applies systems thinking and builds a cross-functional organization that is optimized to facilitate the flow of value from ideation to deployment, as Figure 3 illustrates.

Figure 3. Agile Release Trains are fully cross-functional

Together, this fully cross-functional organization—whether physical (direct organizational reporting) or virtual (line of reporting is unchanged)—has everyone and everything it needs to define and deliver value. It is self-organizing and self-managing. This creates a far leaner organization, one where traditional daily task and project management is no longer required. Value flows more quickly, with a minimum of overhead.

Each Agile team has five to nine dedicated individual contributors, covering all the roles necessary to build a quality increment of value for an iteration. Teams can deliver software, hardware, and any combination. And of course, Agile teams within the ART are themselves cross-functional, as shown in Figure 4.

Figure 4. Agile teams are cross-functional

Critical Team Roles

Each Agile team has dedicated individual contributors, covering all the roles necessary to build a quality increment of value for an iteration. Most SAFe teams apply a ScrumXP and Kanban hybrid, with the three primary Scrum roles:

System Architect/Engineer is an individual or team that defines the overall architecture of the system. They work at a level of abstraction above the teams and components and define Nonfunctional Requirements (NFRs), major system elements, subsystems, and interfaces.

Business Owners are key stakeholders of the ART and have ultimate responsibility for the business outcomes of the train.

In addition to these critical program roles, the following functions play an important part in ART success:

A System Team typically provides assistance in building and maintaining the development, continuous integration, and test environments.

Shared Services are specialists—for example, data security, information architects, database administrators (DBAs)—that are necessary for the success of an ART but cannot be dedicated to a specific train.

Release Management has the authority, knowledge, and capacity to foster and approve releases. In many cases, Release Management includes Solution Train and ART representatives, as well as representatives from marketing, quality, Lean Portfolio Management, IT Service Management, operations, deployment, and distribution. This team typically meets regularly to evaluate content, progress, and quality. They are also actively involved in scope management.

Develop on Cadence

ARTs also address one of the most common problems with traditional Agile development: Teams working on the same solution operate independently and asynchronously. That makes it extremely difficult to routinely integrate the full system. In other words, “The teams are sprinting, but the system isn’t.” This increases the risk of late discovery of issues and problems, as shown in Figure 5.

Figure 5. Asynchronous Agile development

Instead, the ART applies cadence and synchronization to assure that the system is sprinting as a whole, as shown in Figure 6.

Figure 6. Aligned development: this system is sprinting

Cadence and synchronization assure that the focus is constantly on the evolution and objective assessment of the full system, rather than its individual elements. The system demo, which occurs at the end of the iteration, provides the objective evidence that the system is sprinting.

ART Execution, DevOps, and Continuous Delivery

Every two weeks (and in aggregate, every PI) the ART delivers a new system increment of value. This is supported by a Continuous Delivery Pipeline, which contains the workflows, activities, and automation needed to provide the availability of new features release. Figure 7 illustrates how these processes run concurrently and continuously, supported by the ART’s DevOps capabilities.

Each ART builds and maintains (or shares) a pipeline with the assets and technologies needed to deliver solution value as independently as possible. The first three elements of the pipeline work together to support delivery of small batches of new functionality, which are then released in accordance with market demand.

Continuous Integration is the process of taking features from the program backlog and developing, testing, integrating, and validating them in a staging environment where they are ready for deployment and release

Continuous Deployment is the process that takes validated features from continuous integration and deploys them into the production environment, where they’re tested and readied for release

Development and management of the continuous delivery pipeline are supported by DevOps, a capability of every ART. SAFe’s approach to DevOps uses the acronym ‘CALMR’ to reflect the aspects of Culture, Automation, Lean flow, Measurement, and Recovery.

Flow through the system is visualized, managed, and measured by the Program Kanban.

Release on Demand

Releasing is a separate concern from the development cadence. While many ARTs choose to release on the PI boundary, more typically releasing is independent of this cadence. Moreover, for larger systems, releasing is not an all-or-nothing event, and different parts of the solution (subsystems, services, etc.) can be released at different times, as described in Release on Demand.

One primary consideration is size. Effective ARTs typically consist of 50 – 125 people. The upper limit is based on Dunbar’s number, which suggests a limit on the number of people with whom one can form effective, stable social relationships. The lower limit is based mostly on empirical observation. However, trains with fewer than 50 people can still be very effective, and provide many advantages over legacy Agile practices for coordinating Agile teams.

Given the size constraints, there are two primary patterns that occur:

Smaller value streams can be implemented by a single ART

A larger value stream must be supported by multiple ARTs, as Figure 8 illustrates

Figure 8. ARTs realize all or part of a value stream

In the latter case, enterprises apply the elements and practices of the Large Solution Level and create a Solution Train to help coordinate the contributions of ARTs and Suppliers to deliver some of the world’s largest systems.