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 and cross-functional 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.
The Agile Release Train (ART) is the primary construct of value delivery in SAFe. Each ART is a long-lived, self-organizing team of Agile Teams, 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.
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.
The schedule is fixed – The train departs the station on a known, reliable schedule, as determined by the chosen Program Increment (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 eight to twelve 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.
Dedicated people – Most people needed by the ART are dedicated full-time to the train, regardless of their functional reporting structure.
Face-to-Face PI Planning – The ART plans its own work at periodic, largely face-to-face PI Planning events.
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 Inspect and Adapt (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.
Additionally, in larger value streams, multiple ARTs collaborate to build larger solution capabilities via a Solution Train. Some ART stakeholders participate in solution train events, including the Solution Demo and Pre- and Post-PI Planning.
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.
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, 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.
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.
Agile Teams Power the Train
ARTs include the teams that define, build, and test features and components. SAFe teams have a choice of Agile practices, based primarily on Scrum, XP, and Kanban. Software quality practices include continuous integration, test-first, re-factoring, pair work, collective ownership, and more. Hardware quality is supported by exploratory early iterations, frequent system-level integration, design verification, modeling, and set-based design. Agile architecture supports software and hardware quality.
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. Team roles include:
And of course, Agile teams within the ART are themselves cross-functional, as shown in Figure 4.
Each Agile team has dedicated individual contributors, covering all the roles necessary to build a quality increment of value for an iteration. Teams can deliver software, hardware, firmware, and any combination. Most SAFe teams apply a Scrum-XP-Kanban hybrid, with the three primary Scrum roles.
Scrum Master – The Scrum Master is the servant leader for the team, facilitating meetings, fostering Agile behavior, removing impediments, and maintaining the team’s focus.
Product Owner – The Product Owner owns the team backlog, acts as the customer for developer questions, prioritizes the work, and collaborates with Product Management to plan and deliver solutions.
Development Team – The Development Team has three to nine dedicated individual contributors, covering all the roles necessary to build a quality increment of value for an iteration.
The following program-level roles, in addition to the Agile Teams, help ensure successful execution of the ART:
Release Train Engineer (RTE) is the servant leader who facilitates program-level execution, impediment removal, risk and dependency management and continuous improvement
Product Management is responsible for “what gets built,” as defined by the Vision, Roadmap, and new Features in the Program Backlog. They work with customers and Product Owners to understand and communicate their needs, and also participate in Solution validation.
System Architect/Engineer is an individual or team that defines the overall architecture for 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.
Customers are the ultimate buyers of the solution.
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.
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.
Instead, the ART applies cadence and synchronization to assure that the system is iterating as a whole, as shown in Figure 6.
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 iterating.
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 Agile Release Train 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 is supported by DevOps, a capability of every ART. SAFe’s approach to DevOps uses the acronym CALMeR 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. 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.
ARTs Deliver All or Part of a Value Stream
The organization of an ART determines who will be planning and working together, as well as what products, services, features, or components the train will deliver. Organizing Agile Release Trains is part of the “art” of SAFe. This is covered extensively in the Implementation Roadmap article series, particularly in Identify Value Streams and ARTs and Create the Implementation Plan.
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
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.
Learn More Knaster, Richard and Dean Leffingwell. SAFe Distilled, Applying the Scaled Agile Framework for Lean Software and Systems Engineering. Addison-Wesley, 2017.  Leffingwell, Dean. Agile Software Requirements: Lean Requirements Practices for Teams, Programs, and the Enterprise. Addison-Wesley, 2011.  Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.
Last update: 9 May, 2017