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, incrementally develops, delivers, and where applicable operates, one or more solutions in a value stream.
Agile Release Trains align teams to a common business and technology mission. Each is a virtual organization (typically 50 – 125 people) that plans, commits, develops and deploys 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, deploy, release, and where applicable, operate solutions. An ART delivers a continuous flow of value, as shown in Figure 1.
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 Program Increment (PI) cadence. If a Feature misses a timed departure, and does not get planned into the current PI, 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.
- Synchronization is applied – 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.
- Agile Teams – Agile teams embrace the ‘Agile Manifesto’ and the SAFe Core Values and Principles. They apply Scrum, Extreme Programming (XP), Kanban, and other Built-In Quality practices.
- 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 work at periodic, largely face-to-face PI Planning events.
- Innovation and Planning (IP) – IP Iterations occur at the end of every PI and provide an estimating guard band (buffer) as well as 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.
Additionally, in larger value streams, multiple ARTs collaborate to build larger solutions via a Solution Train. Some ART stakeholders participate in Solution Train events, including the Pre- and Post-PI Planning and Solution Demo.
ARTs are typically virtual organizations that have all the people needed to define, deliver, and operate the solution. This new organization breaks down the traditional functional silos that may exist, as shown in Figure 2.
In such a functional organization, developers work with developers, and testers work with other testers, architects and systems engineers work with each other, and operations work by themselves. While there are reasons why organizations have evolved that way, the value doesn’t flow quickly, as it must cross all the silos. The daily involvement of managers is necessary to move the work across these silos and as a result, progress is slow, and handoffs and delays rule.
Instead, the ART applies systems thinking (SAFe Principle #2) and organize around value (SAFe Principle #10) to build a cross-functional organization that is optimized to facilitate the flow of value from ideation through deployment and release, and into operations, 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, deliver, and operate solutions. 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, as well as those that deploy, release, and operate the solution. Individual teams have a choice of Agile practices, based primarily on Scrum, XP, and Kanban. Software quality practices include architecture & design quality, code quality, systems quality, and release quality practices (see Built-In Quality). Hardware quality is supported by exploratory early iterations, frequent system-level integration, design verification, Model-Based Systems Engineering (MBSE), and Set-Based Design. Agile architecture supports both software and hardware quality.
Each Agile team has five to eleven dedicated individual contributors, covering all the roles necessary to build a quality increment of value every iteration. Teams may be technology focused—delivering software, hardware, and any combination—or business focused. And of course, Agile teams within the ART are themselves cross-functional, as shown in Figure 4.
Specialty 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 two specialty 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 a customer proxy for developer questions, prioritizes the work, and collaborates with Product Management to plan and deliver solutions.
Critical ART Roles
In addition to the Agile teams, the following roles help ensure successful execution of the ART:
- Release Train Engineer (RTE) is a servant leader who facilitates program 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 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.
- Customers are the ultimate buyers of the solution.
In addition to these critical ART roles, the following functions play an essential part in ART success:
- System Teams typically assist in building and maintaining 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.
Define the ART
The parameters and boundaries of the ART, as well as its stakeholders, and relations to the value streams can be captured and summarized in the ‘ART canvas’, as Figure 5 shows.
Cadence and Synchronization
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 integrate the full system routinely. In other words, ‘The teams are iterating, but the system isn’t.’ This increases the risk of late discovery of issues and problems, as shown in Figure 6.
Instead, the ART applies cadence and synchronization to assure that the system is iterating as a whole, as shown in Figure 7.
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 every iteration, provides the objective evidence that the system is iterating.
ART Execution, DevOps, and Continuous Delivery
ARTs aim to continuously deliver value to their customers. This is supported by a Continuous Delivery Pipeline, which contains the workflows, activities, and automation needed to support the release of new features. Figure 8 illustrates how these processes run concurrently and continuously, supported by the ART’s DevOps capabilities.
Each ART builds and maintains (or shares) a Continuous Delivery 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 the deployment of very of small batches of new functionality, which are released in accordance with market demands.
- Continuous Exploration is the process of constantly exploring market and user needs, and defining a Vision, Roadmap, and set of hypotheses to address those needs.
- 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 and deploys them into the production environment, where they’re tested and ready for release.
- Release on Demand is the process of making the value available to the end user, measuring and learning from the results of the hypotheses, as well as operating the solutions.
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 concepts of Culture, Automation, Lean flow, Measurement, and Recovery.
Flow through the system is visualized, managed, and measured by the Program Kanban.
ARTs Deliver All or Part of a Value Stream
The organization of an ART determines who will plan and work together, as well as what products, services, features, or components the train will deliver. Organizing ARTs 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 main patterns of ART design (Figure 9):
- Smaller value streams can be implemented by a single ART
- A larger value stream must be supported by multiple ARTs
In the latter case, enterprises apply the elements and practices of Large Solution SAFe and create a Solution Train to help coordinate the contributions of ARTs and Suppliers to build and 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: 23 December 2019