Principle of Alignment: There is more value created with overall alignment than with local excellence.

—Don Reinertsen

Solution Train

The Solution Train is the organizational construct used to build large and complex Solutions that require the coordination of multiple Agile Release Trains (ARTs), as well as the contributions of Suppliers. It aligns ARTs with a shared business and technology mission using the solution Vision, Backlog, and Roadmap, and an aligned Program Increment (PI).

The Solution Train builds large and complex Solutions (often described as ‘system of systems’). These may require hundreds or even thousands of people to develop. Examples include medical devices, automobiles, commercial aircraft, banking systems, and aerospace and defense systems. 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. Also, a failure of such a system can have unacceptable social or economic consequences, so an additional degree of development rigor is required. Many are subject to industry and regulatory standards, and they must provide objective evidence of their Compliance.

Details

Solution Trains allow businesses to build large and complex solutions, including cyber-physical systems (e.g., embedded systems) in a Lean-Agile manner. By aligning Agile Release Trains to a shared mission and coordinating the efforts of ARTs and Suppliers, the Solution Train helps manage the inherent risk and variability of large-scale solution development and requires the support of additional SAFe roles, artifacts, and events, as illustrated in Figure 1.

Figure 1. The Solution Train

Solution trains, like ARTs, operate with the following principles and constructs:

  • Fixed cadence – All ARTs on the Solution Train depart the station on a known, reliable schedule, as determined by the chosen Program Increment (PI) cadence. If a Capability misses a train, it can catch the next one.
  • A new solution increment every PI – During the PI, the Solution Train integrates as much of the solution as is economically feasible, and within the constraints of the Iteration timeboxes. At the end of the PI, the Solution Train delivers a fully integrated solution increment. The Solution Demo provides a mechanism for evaluating the working solution, which is an integrated solution increment from all the ARTs.
  • Solution definition – A Solution Train builds a solution specified by its intent and context.  Solution Intent is the repository for storing, managing, and communicating the knowledge of current and intended Solution behavior. The Solution Context identifies the environment in which the solution operates.
  • Compliance – Compliance describes how to use solution intent to achieve high quality while meeting regulatory and industry requirements using a Lean-Agile approach.
  • Suppliers – Often playing a pivotal role in solution development, a supplier’s agility influences the Solution Train’s agility.
  • PI timebox – All ARTs on the Solution Train use the same PI duration and iteration start/end dates.
  • An Economic Framework – The Economic Framework permits fast, effective decision-making within the scope of Value Stream budgets.
  • ARTs power the Solution Train – ARTs build the components of the solution, using Lean-Agile principles and practices.
  • Inspect and Adapt – The current state of the solution is demoed and evaluated at the Inspect and Adapt (I&A), an event held at the end of every PI for individual ARTs and the Solution Train. Solution Management then identifies improvement Backlog items via a structured, problem-solving workshop.
  • Develop on Cadence. Release on Demand – Solution trains use cadence and synchronization to help manage the inherent variability of research and development. However, releasing is typically decoupled from the development cadence. Solution trains can Release on Demand a solution, or elements of a solution, at any time—subject to requisite governance and release criteria.
  • The Solution Kanban and Backlog – The Solution Kanban and Solution Backlog are used to manage the flow of solution Epics and Capabilities. 

Agile Release Trains Power the Solution Train

Each ART within a Solution Train contributes to the development of the solution, as shown in Figure 2. All development activities typically occur within each ART and are coordinated by the Solution Train, as described below.

Figure 2. ARTs power 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.

As described in the Agile teams and Agile Release Train articles, SAFe recognizes fundamental team topologies [1] to help with the job of team and ART design, 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.

These topologies can be readily extended to help make the right trade-offs in ART design as part of a Solution Train, (Figure 3).

(Note: A possible exception when applying these topologies to ARTs is the ‘enabling’ team type. Although it is common to have two or three enabling teams working across the portfolio—all aligned to the same objective—it is unlikely this would represent an entire ART on a Solution Train.)

Scaling these topologies to organize ARTs requires some additional considerations, as highlighted in the sections below.

Stream-aligned ARTs

A stream-aligned ART, just like a stream-aligned team, will have the necessary personnel, skills, and authority to deliver value, whether it’s a full product, service, subsystem, or whatever portion of the solution they have been tasked with.

The areas of responsibility for these stream-aligned ARTs are generally the same as they are for stream-aligned teams. And the same options for aligning them around a particular aspect, as covered earlier, apply here as well.

Complicated subsystem ART

Most large systems also include extensive subsystems. This means that complicated subsystem ARTs are common when building large-scale systems, again to reduce the cognitive load on the stream-aligned ARTs. For example, a guidance system for an autonomous vehicle could well require an entire complicated subsystem ART.

Platform ARTs

Similarly, it’s common for a Solution Train to have Platform ARTs providing services that the stream-aligned ARTs extend and build on. Continuing the example of the autonomous vehicle, a communication system that manages data transferred between the various subsystems would likely be represented as a platform ART, with clearly defined interfaces.

(Note: One additional benefit of the platform topology is that it also supports a single platform ART that is providing services across multiple development value streams within the organization.)

Figure 3. A mixture of topologies applied to ARTs within a Solution Train

In all these examples, the ARTs are composed of teams that will also take on one of the four team types. For instance, within the complicated subsystem ART developing the guidance system may be one or more stream-aligned teams developing the features that relate to environment perception. Similarly, there might be a complicated subsystem team focused specifically on routing algorithms. In this manner, the application of the topologies is fractal.

Of course, there is an intermediate pattern where, within a single ART, there may be a collection of teams working on the same platform or complicated subsystem. In this instance, the work must be carefully allocated to minimize handoffs and dependencies.

Solution Train Roles

Three primary Solution Train roles help facilitate successful execution.

  • Solution Train Engineer (STE) is the servant leader of the train. Their oversight allows the train to run smoothly by identifying and resolving bottlenecks across the entire solution. The STE facilitates the large solution-level events and monitors the solution Kanban and solution health via appropriate metrics. They also work with Release Train Engineers (RTEs) to coordinate delivery.
  • Solution Management represents the customer’s overall needs across ARTs, as well as communicating the portfolio’s Strategic Themes. They collaborate with Product Management of each ART to define capabilities and split them into features. Solution Management, the primary content authority for the solution backlog, also contributes to the economic framework that governs the ARTs and Agile teams.
  • Solution Architect/Engineering collaboratively defines the technology and architecture that connects the solution across the ARTs. It works with the ART’s System Architect/Engineering team to help guide their portion of the solution’s design.

Also, the following roles play an essential part in the Solution Train’s success:

  • Customers (most often, Direct Customers) are the ultimate buyers of the solution and are involved at every level of SAFe. They’re part of the value stream and are inseparable from the development process. Direct customers work closely with Solution and Product Management and other key stakeholders to shape the solution intent, the Vision, and the economic framework in which development occurs.
  • A System Team is often formed for the Solution Train to address the integration issues across the ARTs.
  • Shared Services provide specialty skills—data security, information architects, and database administrators (DBAs), for example—that are necessary for the success of a solution but may not be dedicated to a specific train.

Defining the Solution

Solution behavior and decisions are managed in the solution intent, the single source of truth and the container for requirements as they move from variable to fixed.  In addition to the vision and Roadmap, the development of solution intent in an adaptive manner is supported by three additional practices, as shown in Figure 3 and described below.

Figure 4. Solution intent
  • Compliance – Describes how SAFe uses solution intent to achieve high quality and meet regulatory and industry standard requirements using Lean-Agile development
  • Model-Based Systems Engineering (MBSE) – Describes how emergent requirements and design can be developed, documented, and maintained in more flexible and accessible models
  • Set-Based Design (SBD) – Describes practices that support the preservation of options and the move from variable to fixed requirements over time, while deferring decisions to the last responsible moment

Building Solution Capabilities

Building large and complex solutions is not a trivial matter. They often require additional constructs beyond those of a single ART:

  • Solution intent as the repository for intended and actual solution behavior
  • Solution context, which describes the way a solution fits in the deployment environment
  • Capabilities and enablers, which are needed to realize the vision and roadmap for the value stream, and more importantly, to satisfy the needs of customers

The solution is described as having a set of capabilities. Like features, they represent a higher-level of solution behaviors that typically take multiple ARTs to implement, as shown in Figure 4. Capabilities are sized to fit within a PI.

Figure 5. Splitting capabilities into features facilitate implementation by multiple ARTs

The solution Kanban is used to manage the flow of work to assure the evaluation and analysis of capabilities before they reach the solution backlog, where they await implementation.  

The Kanban system also helps limit Work in Process (WIP) to ensure that all the ARTs are synchronized and have the capacity to deliver value together. Larger initiatives defined as solution epics are broken down into capabilities during analysis state in the Kanban.

Coordinating ARTs and Suppliers

Solution trains coordinate the development of solutions within a PI, and they provide for cadence and synchronization of ARTs and suppliers, including PI Planning events and the solution demo. Figure 5 shows the Solution Train events.  In many cases, large solutions require suppliers who develop components, subsystems, or capabilities for the value stream. These suppliers participate in the Solution Train events.

Figure 6. Solution Train coordination events.

At the start of each PI, planning takes place for all ARTs at (ideally) the same time, conducted by the ARTs in individually PI planning events. The Pre- and Post-PI Planning events gain alignment and create a single plan across all trains, as well as manage dependencies between the trains. These events result in summarized solution PI Objectives for communication with stakeholders.

The Solution Train holds a solution demo at the end of each PI (or may sometimes lag to the start of the next PI). Here, it presents an integrated solution across all ARTs and suppliers to customers and stakeholders from the portfolio and other value streams. After this demo, an I&A workshop is held to improve the process of the entire value stream.

Lean-Agile suppliers can be treated as another ART, participating in all Solution Train events. Traditionally, suppliers work against contractual Milestones, but they are still expected to attend pre- and post-PI planning, solution demos, and Solution Train I&A. SAFe enterprises help suppliers improve their processes and become more Lean and Agile, to the economic benefit of both organizations

Releasing and Release Governance

As we noted above, Solution Trains apply cadence and synchronization to manage development. But Solution Trains can deploy an entire solution, or the elements of a solution, at any time the business and market dictates.

In support of this, each Solution Train must establish—or operate within the governance of—a release management function. 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.

Also, release management may be concerned with other elements of the whole solution, including internationalization, packing and deployment, training requirements, internal and external communications, and ensuring compliance conformance to regulatory and standards requirements.

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.

 

Last update: 25 June 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.