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

—Don Reinertsen


Solution Train

The Solution Train is the SAFe 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. The solution train aligns ARTs to a shared business and technology mission using a common solution Vision, Backlog, and Roadmap, and an aligned Program Increment (PI) cadence.

The solution train is used by those who build 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. In addition, a failure of such a system can have unacceptable social or economic consequences, so an additional degree of development rigor is required. Many of such systems are subject to industry and regulatory standards, and they must provide objective evidence of their Compliance to such standards.


Solution trains allow businesses to build  large and complex solutions in a Lean-Agile manner. By aligning ARTs to a common mission and coordinating the efforts of ARTs and suppliers, the solution train helps manage the inherent risk and variability of large-scale solution development. This 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 on a set of common principles:

  • The schedule is fixed – All ARTs on the Solution Train depart the station on a known, reliable schedule, as determined by the chosen 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 – A solution is defined by its Solution Intent. The Solution Context defines the environment in which the solution operates.
  • Compliance – This describes how to use solution intent to achieve high quality while meeting regulatory and industry requirements using Lean-Agile development.
  • Suppliers – Often playing a key role in large solution development, a supplier’s agility influences the solution train’s agility.
  • The PI timebox is fixed – All ARTs on the solution train are synchronized to the same PI duration and have common PI and iteration start/end dates.
  • Uses an Economic Framework – The economic framework permits fast, effective decision-making within the scope of the Value Stream budget.
  • ARTs power the solution train – ARTs build the components of the solution, using Lean-Agile principles and practices.
  • Inspect and Adapt (I&A) – The current state of the solution is demonstrated and evaluated at the 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 (Develop on Cadence) 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 a large 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

Solution Train Roles

In addition to the members of the ARTs, three primary roles help ensure successful execution by the solution train:

  • Solution Train Engineer (STE) is the servant leader for the solution 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 its 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 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 ARTs and Agile teams.
  • Solution Architect/Engineering collaboratively defines the technology and architecture that connects the solution across ARTs. It works with the ART’s System Architect/Engineering team to help guide their portion of the solution’s design.

In addition to these three primary roles, the following play an important part in the solution train’s success:

  • 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. 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 in order to address the larger solution integration issues across ARTs.
  • Shared Services are specialists—data security, information architects, and database administrators (DBAs), for example—that are necessary for the success of a solution, but cannot be dedicated to a specific train.

Defining the Solution

Solution behavior and decisions are managed in 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 3. Solution Intent
  • Compliance – Describes how SAFe uses solution intent to achieve high quality and meet regulatory and industry standard requirements using scaled 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 – Describes practices that support 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 developed and described as having a set of  capabilities. Similar to features, capabilities are higher-level solution behaviors that typically take multiple ARTs to implement, as shown in Figure 4. Like features, capabilities are sized to fit within a PI.

Figure 4. Capabilities are split into Features to be implemented by multiple ARTs

The flow of capabilities is managed through the solution Kanban, which is used to verify that capabilities are evaluated and analyzed before they reach the solution backlog, where they are readied for implementation. The Kanban system also serves as a focusing mechanism that helps limit Work in Process (WIP) to ensure that all the ARTs are synchronized and have the capacity to deliver capabilities together. Larger initiatives are managed as solution epics and are broken down into capabilities during analysis.

Coordinating ARTs and Suppliers

Solution trains coordinate the development of solutions within a PI, which is used to synchronize value delivery across multiple ARTs. They provide for cadence and synchronization of multiple ARTs and suppliers, including PI Planning meetings and the solution demo. In many cases, large solutions require suppliers who develop components, subsystems, or capabilities for the value stream. These suppliers participate in the large solution-level events.

At the start of each PI, planning takes place for all ARTs at the same time, conducted by the ARTs individually in PI planning meetings. But to gain alignment and create a single plan across all trains, as well as manage dependencies between the trains, Pre- and Post-PI Planning meetings also take place. These events result in aggregated solution PI Objectives that can be communicated to stakeholders.

At the end of each PI (usually some time into the next one), a solution demo is held, an important event for the solution train. 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.

Suppliers often play a key role in solution development, as well. The overall value stream’s agility depends on supplier agility. Lean-Agile suppliers can be treated as another ART, participating in all solution train events. However, suppliers working in traditional methodologies work against Milestones, but are 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 release 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.

In addition, 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] Knaster, Richard and Dean Leffingwell. SAFe 4.0 Distilled: Applying the Scaled Agile Framework for Lean Software and Systems Engineering, Addison-Wesley, 2017.

Last update: 16 September, 2017