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.

Details

Agile Release Trains align teams to a shared 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 Development 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.

 

Figure 1. A long-lived Agile Release Train

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 ART can reliably estimate how much cargo (new features) can be delivered in a PI.
  • Agile Teams – Agile Teams embrace the ‘Agile Manifesto’ and 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, mostly 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 more significant value streams, multiple ARTs collaborate to build more extensive 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 Organized Around Value

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.

 

Figure 2. Traditional functional organization

In such a functional organization, developers work with developers, and testers collaborate 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.

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, 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, 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. Each Agile team has 5 – 11 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. Each Agile team has two specialty roles, the Scrum Master and the Product Owner. And of course, Agile teams within the ART are themselves cross-functional, as shown in Figure 4.

Figure 4. Agile teams are cross-functional

As well as organizing the ARTs around development value streams, the Agile teams on these ARTs also need to be organized around value. Otherwise the potential benefits of creating ARTs that can deliver a continuous flow of value will be lost, as the teams struggle to manage the various dependencies and interconnections between them.

To simplify this job of team design, SAFe applies four fundamental team topologies [1] which are defined as follows:

  1. Stream-aligned team – organized around the flow of work and has the ability to deliver value directly to the customer or end user.
  2. Complicated subsystem team – organized around specific subsystems that require deep specialty skills and expertise.
  3. Platform team – organized around the development and support of platforms that provide services to other teams.
  4. Enabling team – organized to assist other teams with specialized capabilities and help them become proficient in new technologies.

Each of these team topologies maps to a specific set of responsibilities and behaviors, and together they provide a clearer and better model for organizing Agile teams in SAFe. Further information, as well as guidance for applying these topologies, can be found in the Agile Teams article.

When designing ARTs, and the teams that compose them, it can also be useful to visualize these teams in terms of the topologies that they map to. In order to make the team types clear, we use the following icons, shown in Figure 5, to represent the different team types. A stream-aligned team is represented with an arrow on the end, emphasizing flow, a square is used to represent a complicated subsystem team, a rectangle for a platform team, and a dotted ellipse for an enabling team.

These icons can also be used to visualize the likely interactions between the teams through their relative positioning. The names of the specific teams can then be added to these icons for a complete picture. Visualizing the teams on the ART in this manner helps to compare and contrast the merits of competing designs and also provides an indication of how well any particular design is aligned to the flow of value.

Figure 5. Applying team topologies to Agile teams on an ART

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/Engineering 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, its stakeholders, and its relationship to the value streams can be captured and summarized in the ‘ART canvas’ (Figure 6).

 

Figure 6. The ART Canvas

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 7.

 

Figure 7. Asynchronous Agile development

 

Instead, the ART applies cadence and synchronization to assure that the system is iterating as a whole (Figure 8).

Figure 8. Aligned development: this system is iterating

Cadence and synchronization assure that the focus is continuously on the evolution and objective assessment of the full system, rather than its 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 deliver value to their customers continuously. This goal is supported by a Continuous Delivery Pipeline, which contains the workflows, activities, and automation needed to support the release of new features. Figure 9 illustrates how these processes run concurrently and continuously, supported by the ART’s DevOps capabilities.

 

Figure 9. Continuous Exploration, Continuous Integration, and Continuous Deployment are continuous, concurrent, and supported by 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 small batches of new functionality, which are released to meet market demands.

  • Continuous Exploration is the ongoing process of exploring the 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, and operating the solutions.

Development and management of the Continuous Delivery Pipeline are supported by DevOps, a capability of every ART.

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 process is covered extensively in the Implementation Roadmap article series, particularly in ‘Identify Value Streams and ARTs‘ and ‘Create the Implementation Plan.’

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 provide good value, 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 10):

  • Smaller value streams can be implemented by a single ART
  • A larger value stream must be supported by multiple ARTs

 

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

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

[1] Skelton, Mathew, and Manuel Pais. Team Topologies. IT Revolution Press, 2019.

[2] Knaster, Richard, and Dean Leffingwell. SAFe 5.0 Distilled, Achieving Business Agility with the Scaled Agile Framework. Addison-Wesley, 2020.

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

[4] Leffingwell, Dean. Scaling Software Agility: Best Practices for Large Enterprises. Addison-Wesley, 2007.

 

Last update: 11 March 2021

 

The information on this page is © 2010-2024 Scaled Agile, Inc. and 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. Scaled Agile Framework and SAFe are registered trademarks of Scaled Agile, Inc. Please visit Permissions FAQs and contact us for permissions.