Agile Release Train

Revision as of 23:05, 21 February 2021

In order to align the different teams on an equal mission, as a part of the Agile Methodology, they are organized in an Agile Release Train (ART). The ART team organization is based on a long-lived combination of Agile Teams, formed to develop and deliver one or more solutions as part of a value stream. ARTs operate based on a set of common principles of SaFe such as fixed schedules, programmed incremented schedules, and agile dedicated teams. Opposite to functional organization, ARTs focus on value forming cross-functional teams. Each team has everything it needs to define, deliver, and operate solutions and every team has well-defined responsibilities that are based on the team type. To simplify the team design it is possible to apply SaFe four fundamental team topologies, where each of them is organized around a specific set of responsibilities. The challenges that arise at the time of forming an ART are related to defining and structuring the organization around value streams, handling cross-team dependencies between ARTs, and integrating teams with fewer dependencies into ARTs.

The Agile Release Train (ART)

An Agile Release Train is a predefined cycle which has been strictly planned in advance in order to deliver a certain goal. It is divided into phases and projects teams that align in order to achieve a specified shared mission. In the Scaled Agile Framework (SAFe®), the Agile Release Train (ART) is a long-lived team of Agile teams, which, along with other stakeholders, incrementally develops and delivers one or more solutions in a value stream.

ARTs have all the people needed to define, deliver, and operate the solution. They are organized around value streams and exist to achieve a promised value by building solutions that deliver an expected benefit. Their final purpose is to deliver a continuous flow of value.

The trains operate based on a number of common principles:

• Fixed schedule: The release cycle functions as a train, it departs the station on a known and controlled schedule which is determined using the Program Increment (PI) cadence.
• Structured increments every two weeks: Each train delivers a new increment every two weeks.
• Synchronized teams: The teams that are part of the train are synchronized to a specific Program Increment length and have aligned start and end dates and duration.
• Known velocity: Each ART can estimate how many tasks can be delivered in a single PI.
• Agile Teams: The ARTs are formed by agile teams which embrace the SAFe core values and principles.
• Dedicated people: Human resources part of the ART teams are dedicated full time to the train independently of their functional reporting structure.
• PI Planning: To organize the work load needed in each PI is necessary to schedule periodic and presential sessions.
• Innovation and Planning (IP): At the end of each program increment (PI) it is necessary to perform IP iterations to keep the focus on delivering the defined goals and identify potential issues.
• Inspect and Adapt (I&A): An I&A session is organized at the end of every PI. In these sessions the state of the solution is evaluated and the teams involved work on identifying possible improvements through problem-solving workshops.
• Develop on Cadence, Release on Demand: ARTs apply a specific rhythm and synchronization to help manage the variability of research and development projects. IT is important to mention that releasing the final product is usually independent from the development cadence, ARTs can release a solution at any time while meeting the release criteria.

The way ARTs are organized breaks down the traditional functional units that organizations have. While there are advantages on these functional units, it is important to mention that the value doesn’t flow quickly as it must cross through the different units. It is necessary a close control from the managers to move the work across and as a result, progress is slow. Instead, ART applies systems thinking and organize around value to build a cross-functional organization. This structure helps the flow of value from ideation through deployment and release, and into operations. This cross-functional organization all the resources that needs to deliver solutions. This creates a far leaner structure, where daily task controls and project management are no necessarily required. This improves the value flow with a minimum of control.

It is important to mention that ARTs solve one of the most common problems with traditional Agile development, this is teams working on the same solution usually operate independently and unaligned, which makes it extremely difficult to integrate the full system. This way, the risk of bypassing problems and late discovery increases. Instead, applying cadence and synchronization, it ensures that the system is iterating as a whole focusing on the evolution and assessment of the full system rather than its separate elements.

ARTs are formed to continuously deliver value to customers. This goal is supported by a Continuous Delivery Pipeline, which contains the workflows, activities, and automation needed to support the release of new features. Each ART builds and maintains a Continuous Delivery Pipeline with the assets 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: the ongoing process of exploring the user needs and defining the 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: 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.

Solution Train

An important concept of the in the ARTs structure are Solution Trains. These are the organizational construct used to build large and complex solutions (often described as ‘system of systems’) that require the coordination of multiple Agile Release Trains (ARTs). They are useful to align ARTs with a shared business and technology mission. The Solution Train provides the additional roles, events, and artifacts necessary to coordinate the building of some of the world’s largest and most important systems.

Each ART within a Solution Train contributes to the development of the solution. All development activities typically occur within each ART and are coordinated by the Solution Train. To support the overall goal of continuous value delivery to the customer, each ART within the Solution Train must be designed to maximize flow across the entire Solution Train. 2

How to apply ARTs?

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

As mentioned in the previous section, Agile Release Trains are part of the Scaled Agile Framework (SAFe®). The instructions for the implementation of ARTs are part of the same path of the SAFe implementation process.

First, it is necessary to identify Value Streams and possible ARTs. During these phases, initial implementation design and planning are the key activities. Identifying Value Streams and ARTs requires an understanding of the organizational model which needs to be optimized to facilitate the flow of value across functional units. These phases follow a series of steps:

1. First it is necessary to identify the Operational Value Streams. A value stream is the primary construct block for understanding, organizing and delivering value. Value streams can be Operational which contains the steps and the people who deliver a product or service to the customer, or they can be Development which includes the sequence of activities needed to convert a business hypothesis into a finished solution that delivers customer value. Operational value streams fall into one of four types:

1. 1. Fulfillment value streams represent the steps necessary to process a customer request, deliver a digitally-enabled product or service, and receive remuneration.
   2. Manufacturing value streams convert raw materials into the products customers purchase.
   3. Software product value streams offer and support software products
   4. Supporting value streams include end-to-end workflows for various supporting activities.

1. Once the operational value stream steps are identified, the next step is to identify the solutions that are developed to support it. It’s important to map the connections from the solutions to the various steps in the value stream.

1. After identifying the solutions that support the operational value stream, the next activity is to estimate the number and locations of the people that build and maintain those solutions.

1. The next step is to identify the development value streams. These are the steps needed to develop the solutions as well as the people necessary to work on them. The solutions support and enable better operation within the operational value streams and as such the value is new or amended features in the solutions. It is called triggers to the requirements and ideas which drive these features and can be used to identify the number of development value streams. These value streams are different from the operational ones and therefore it is important to consider what the trigger and value are.

1. Development value streams strive to deliver innovative business solutions and as such require the contributions of more than just Agile teams. Everyone involved in business solution delivery are considered part of the development value stream. With this in mind the next step is to identify these additional individuals and teams who are part of the development value streams identified in the previous step.

1. The next step is to develop value streams across boundaries. Once the development value streams are identified, the next step is to start to organize the formation of the Agile Release Trains. After identifying where in the organization that value is created it becomes obvious that development value streams cross many boundaries which are necessary to link.

1. The final step is to define the ARTs that possess value. The most effective ARTs have between 50 – 125 people, they are focused on a holistic solution or related set of products or services and they are formed by long-lived, stable teams that consistently deliver value. It is important that they minimize dependencies with other ARTs and they can act with a certain degree of freedom.

1. In the case where many people are needed to deliver a single solution, multiple ARTs will need to collaborate as part of a Solution Train. To support the overall goal of continuous value delivery each ART must be designed to maximize flow across the entire Solution Train.

When forming the ARTs, there are two main patterns of design regarding the size constrains:

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

It is important to mention that, as well as organizing the ARTs around development value streams, the Agile teams that are part of the ARTs 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. Each Agile team has two specialty roles, the Scrum Master and the Product Owner.

In addition to the Agile teams, the following roles need to be present to ensure successful execution of the ART:

• Release Train Engineer (RTE): is the leader and coach for the ART. It is the person who facilitates program execution and continuous improvement. The RTE’s major responsibilities are to facilitate the ART events and processes and assist the teams in delivering value.
• Product Management: is responsible for the final product or service being developed 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.
• Business Owners: are key stakeholders of the ART and have ultimate responsibility for the business outcomes of the train.
• Customers: the ultimate buyers of the solution.

When designing ARTs and the teams that are part of them, it can also be useful to visualize these teams in terms of the topologies that they map to. To simplify the job of team design, SAFe applies four fundamental team topologies. Each of these topologies provide a clearer and better model for organizing Agile teams in SAFe.

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

ART Limitations

ART limitations can be related to the complexity of the structures or the amount of workload needed to start and define the trains. The fact that SAFe emphasizes the big picture can often lead to longer planning cycles and more fixed roles within development cycles. Challenges related to defining and structuring the organization around value streams have been reported. Furthermore, there were also identified struggles with handling cross-team dependencies between ARTs and integrating teams with less dependencies into ARTs.

Bibliography

© Scaled Agile, Inc. https://www.scaledagile.com

How Are Agile Release Trains Formed in Practice? A Case Study in a Large Financial Corporation - Abheeshta Putta, Maria Paasivaara, and Casper Lassenius