If everyone is moving forward together, success takes care of itself.

—Henry Ford

Coordinate and Deliver

Coordinate and Deliver describes the practices Solution Trains use to maintain the alignment and collaboration needed to continuously deliver value to large solution customers.

Building and operating effective large solutions requires the knowledge and expertise of many solution builders across diverse disciplines. Each ART and Supplier contributes unique knowledge and technical capabilities to deliver valuable customer solutions. Solution Train leaders and developers must continuously coordinate their activities to ensure consistent, predictable results.


Alignment is not a natural state. Any lack of alignment on what the Solution is intended to do—or how it will be achieved— is very costly. When building really big systems, every day lost represents significant financial waste and negative business impact. The traditional approach to achieving better alignment was creating detailed specifications and a detailed schedule. Unfortunately, this approach doesn’t solve the problem. Indeed, it has significant adverse side effects:

  • Constraining innovation
  • Limiting the ability to explore alternatives
  • Preventing adjustment from feedback and learning

In summary, the traditional approach did not serve the purpose of adequately reducing overall risk. Building large solutions that require a high degree of innovation and contain significant uncertainty requires a different approach. Rather than one-time alignment up-front, system builders must constantly align about exactly what the system is supposed to do and how it is supposed to do it.

The first step in creating alignment is to apply a common cadence to the building and deployment of these solutions. While Agile Release Trains (ARTs) and Suppliers’ understanding may naturally diverge based on changing facts, local knowledge, and context, common PI boundaries support frequent realignment, as seen in the left side of Figure 1. But deviation, even during the PI, can also lead to significant waste and increased risks. Therefore, in addition to these shared PI timeboxes, solution builders need frequent, almost continuous alignment, as the right side of Figure 1 illustrates.

Figure 1. Solution Trains require continuous alignment
Figure 1. Solution Trains require continuous alignment

Solution Trains apply two mechanisms to create and maintain alignment throughout the PI, as shown in Figure 2. Solution Train artifacts define and communicate intent and forecasted plans, enabling Agile Teams, ARTs, and suppliers to make informed local decisions. Solution Train activities provide frequent alignment, assessment, and adjustment opportunities.

Figure 2. Solution Train artifacts and activities align ARTs and suppliers during PI execution
Figure 2. Solution Train artifacts and activities align ARTs and suppliers during PI execution

The remainder of this article describes these artifacts and activities.

Creating Alignment with Solution Train Artifacts

ARTs and teams require technical competence and organizational clarity to make informed, localized decisions (see Principle #9 – Decentralize Decision Making). Solution Train artifacts provide clarity by defining and communicating intent and ensuring all solution builders have shared vision, goals, and objectives. The critical artifacts are:

  • Solution Vision – defines the solution’s purpose and how it solves customer needs
  • Solution Intent – maintains and communicates the solution’s requirements and design specifications
  • Solution Roadmap – delineates critical milestones and the solution’s longer planning horizon

Solution Management and Solution Architects continually evolve these artifacts as ARTs and suppliers build the solution, and adjust them as new facts emerge. Everyone uses this information to drive their local backlogs and roadmaps while operating as fast and independently as feasible.

Creating Alignment with Solution Train Activities

The activities in Figure 1 can help maintain alignment during solution development. Each is described below.


Preparing for PI Planning is a significant alignment activity for a Solution Train. The Pre-Plan article describes how Solution Trains align and adjust objectives before the event based on the current state of the solution.

Plan the Solution Train PI

During PI Planning, Solution Trains must align their ARTs and suppliers on a joint plan for the upcoming PI. The individual ART planning events may be conducted as a single large event, or ARTs may plan in a more distributed fashion. In either case, Solution Train PI Planning is a critical synchronization point across all the ARTs and suppliers. Figure 3 illustrates a typical two-day pattern that can be used to create alignment during a Solution Train planning event.

Figure 3. A common Solution Train PI Planning pattern
Figure 3. A typical Solution Train PI Planning pattern

This format begins with Solution Train leaders presenting the Business Context to all teams across all ARTs. The ARTs continue their first day according to the ART PI planning agenda (performing product and architectural vision briefings, team breakouts, and so on). At the end of Day 1, representatives from each ART bring their “Management Review and Problem-Solving” outcomes to a Solution Train Management Review to coordinate their planning adjustments. On Day 2, the ART leaders present the aligned adjustments and continue planning following the Day 2 agenda. Consolidated “Readouts” occur across the entire Solution Train at the end of Day 2, so every Solution Train member sees the final plan.

But that is just one such pattern; Solution Train PI Planning can vary based on the dependencies between ARTs, planning sequences, and logistic concerns. For example, if the ARTs need to plan on different days or weeks, business context and the final plan readouts may need to be recorded and shared.

During planning, teams build a Solution Train planning board (Figure 4). This board is like the ART planning board (see PI Planning) but focuses on the Capabilities to be delivered.

Figure 4. An example Solution Train planning board
Figure 4. An example Solution Train planning board

ARTs and Suppliers in a Solution Train depend on each other to deliver various solution elements. AS each dependency between ARTs is ultimately a dependency between teams, some Solution Trains find value in a more detailed planning board that shows team dependencies (Figure 5).

Figure 5. Solution Train planning board with team details
Figure 5. Solution Train planning board with team dependencies identified

When ART planning is complete, the Solution Train Engineer (STE) works with Solution Train and ART leaders to aggregate the ART’s PI Objectives into Solution Train PI Objectives. That creates the Solution Train PI Plan (see Roadmap), which defines the capabilities planned to be delivered in the upcoming PI.

Integrate Frequently

Agile development requires fast feedback. In turn, this requires frequent integration. However, the size, complexity, dependence on external suppliers, significant compliance and governance rules, and more make frequent integration of large solutions far more difficult.

In addition, the move to DevOps often suffers from legacy technologies, tightly coupled components, and a mixture of manual and automated build and test processes. In addition, cyber-physical systems often require hardware and materials that add long lead times to the integration mix.

Despite these potential impediments, frequent integration is necessary for the feedback and adjustment needed to reduce risk. While models, simulations, and lower-fidelity prototypes provide a fast and economical way to gain insights early in the product lifecycle (see Model-Based Systems Engineering (MBSE), physical integration is still required. This requires a long-term strategy, investment in solution architecture, technology modernization, and the creation of an automated, end-to-end, Continuous Delivery Pipeline.

Further, the cognitive load and infrastructure required to integrate these systems is often too large for the individual development teams. System Teams at both the ART and Solution Train levels help by building and supporting most of the Continuous Integration (CI) and Continuous Deployment (CD) infrastructure and automation (Figure 6). They enable fast feedback on changes by providing the following:

  • Automation to build, integrate, and test the system at all levels
  • Adequate environments for teams to test their part of the system
  • Telemetry across the pipeline to measure performance and detect issues
Figure 7. Frequently integrate end-to-end changes
Figure 6. Frequently integrate the end-to-end solution with the CI/CD pipeline

Synchronize Routinely

Solution Trains are ‘nested’ teams of teams. High-performing teams create high-performing ARTs, which make high-performing Solution Trains. Scaling adds technical and social complexities that can block the teams’ work. ARTs and teams need mechanisms to communicate effectively and raise risks and impediments quickly to support continuous alignment. While any team can communicate with any other team at any time, scheduled synchronization events provide the frequent alignment needed to minimize divergence (Figure 7).

Figure 6. Teams and ARTs require a channel to raise issues for fast feedback
Figure 7. Teams and ARTs use cadence-based communication events to coordinate development and delivery

Like ARTs, Solution Trains have synchronization events that provide regular communication and coordination. Their purpose is to address issues and have the conversations necessary to keep the work moving forward and help teams resolve issues. These events include:

  • RTE Sync – similar to the ‘Coach Sync’ (See PI article), this event usually runs on the same cadence as the Coach Syncs and is held soon after it to address issues that can’t be resolved directly by the ARTs. Attendees include the STE, the Release Train Engineers (RTEs), select Scrum Master/ Team Coaches, and others dictated by the agenda.
  • Product Manager Sync – similar to the PO Sync (See PO Sync in PI article), the Product Manager sync typically runs on the same cadence as the PO Sync and is held soon after it to raise and address issues from the ARTs. Attendees include Solution Managers, Product Managers, select Product Owners, and others dictated by the agenda.
  • Architect Sync – a Solution Train event used to guide emerging designs, discuss tradeoffs, and increase opportunities to align implementation approaches without becoming a source of delay. Attendees include Solution Architects, System Architects, and team members. Enterprise Architects may also attend.

Participants in the sync events may vary. Architects often attend the PM Sync to provide input or learn from the discussions. Likewise, PMs may also participate in the Architect Sync. Each event is usually held weekly, with the ART events informing the agendas. The purpose is to manage change, resolve impediments, and make decisions about execution. Like the ART Sync, the RTE, PM, and Architecture Sync events may be combined into a Solution Train Sync when the topics overlap.

Demonstrate the Full Solution

Instead of measuring progress through stage gate milestones, schedules, and other proxies for value delivery, leaders provide input and feedback directly while participating in development events. Solution Demos are one such significant event where stakeholders observe and objectively evaluate the progress of the working, large solution. Solution Management often delivers these demos to provide the proper messaging and explanation of new capabilities.

Coordinate Releases

In an ideal environment, ARTs and Agile teams independently deploy and release small increments of value. However, large solutions have several challenges that inhibit frequent deployment and release:

  • Functional dependencies between features across ARTs and suppliers may require coordination
  • Long lead times for cyber-physical system components and waterfall-based suppliers may require more extensive release coordination
  • Marketing events may govern release dates and encourage a large-batch release of new functionality to spark publicity for these high-investment solutions

The Solution Roadmap and Solution Train planning board help maintain alignment by clearly communicating release dates and dependencies. To track and coordinate dependent work across the Solution Train, STEs and RTEs work with Solution and Product Management to help ARTs release large solution value. See ‘releasing and release governance’ in the Solution Train article for more details.

Inspect & Adapt

Relentless improvement is a SAFe Core Value. That commitment requires time and space for the people doing the work to improve their processes. Solution Trains benefit from their ART’s continuous improvement practices, including team retrospectives and Inspect and Adapt (I&A) events. However, some of the impediments discovered may require attention at the Solution Train level.

Solution Trains are too large for all team members across all ARTs to participate in improvement events like I&A, and not all members can contribute to all improvement items. For this reason, select individuals across the ARTs contribute to the Solution Train I&A based on the topic. The right people must attend through self-selection or invitation to get a good outcome.


Last Updated: 13 January 2023