Everything must be made as simple as possible. But not simpler.
—Albert Einstein
The Large Solution Level contains the roles, artifacts, and processes needed to build large and complex solutions. This includes a stronger focus on capturing requirements in Solution Intent, the coordination of multiple Agile Release Trains (ARTs) and Suppliers, and the need to ensure compliance with regulations and standards.
Einstein’s quote reminds us that we should strive to make things as simple as possible, but not simpler than what is needed. Similarly, when building large and complex systems, theoretically the simplest thing that could possibly work would be a single team. Of course, we know that even teams with more than 10 people are problematic. And a single ‘team’ of hundreds, or even thousands, of people just isn’t feasible. Instead, we scale by organizing people into ARTs (a team-of-Agile-teams) and Solution Trains (a team of multiple ARTs). Coordinating the work of a Solution Train to build large and complex solutions requires additional roles, events, and artifacts, which is the purpose of the large solution level.
The large solution level (see Figure 1) is meant for enterprises that face the biggest challenges—building large-scale solutions that are beyond the scope of a single ART to develop. Building these solutions requires additional roles, artifacts, events, and coordination.
Following are the highlights of the large solution level:
Solution – Each Value Stream produces one or more solutions, which are products, services, or systems delivered to the Customer, whether internal or external to the enterprise.
Solution Train – The key organizational element of the large solution level, it aligns the people and the work around a common solution vision, mission, and backlog.
Economic Framework – The economic framework is a set of decision rules that aligns everyone to the financial objectives of the Solution and guides the economic decision-making process.
Solution Intent – This repository for current and future solution behaviors can be used to support verification, validation, and Compliance. Solution intent is also used to extend Built-In Quality practices with systems engineering disciplines, including Set-Based Design, Model-Based Systems Engineering (MBSE), Compliance, and Agile Architecture.
Solution Context – This context describes how the system will interface and be packaged and deployed in its operating environment.
Solution Kanban and Backlog – The Solution Kanban and Solution Backlog are used to manage the flow of solution Epics and Capabilities.
The large solution level roles provide governance and help coordinate multiple ARTs and suppliers:
Customer – The ultimate buyer of every solution. An integral part of the Lean-Agile development process and value stream, customers have specific responsibilities in SAFe.
Solution Architect/Engineering – An individual or small team that defines a shared technical and architectural vision for the solution under development.
Solution Management – The representative of the customer’s overall needs across ARTs, as well as the communicator of the portfolio’s Strategic Themes. This individual collaborates with Product Management to define capabilities and split them into features. Solution Management, as the primary content authority for the solution backlog, also contributes to the economic framework that governs ARTs and Agile teams.
Solution Train Engineer (STE) – A servant leader and coach who facilitates and guides the work of all ARTs and suppliers.
Supplier – An internal or external organization that develops and delivers components, subsystems, or services, which in turn help Solution Trains deliver solutions to customers.
The large solution level uses three major activities to help coordinate multiple ARTs and suppliers:
Pre- and Post-PI Planning – An event used to prepare for, and follow up after, Program Increment (PI) Planning for ARTs and suppliers in a Solution Train.
Solution Demo – An event in which the results of all the development efforts from multiple ARTs—along with the contributions from suppliers—are integrated, evaluated, and made visible to customers and other stakeholders.
Inspect & Adapt (I&A) – A significant event where the current state of the solution is demonstrated and evaluated. Teams then reflect and identify improvement backlog items via a structured problem-solving workshop.
The following large-solution-level artifacts help coordinate multiple ARTs and suppliers:
Capabilities – Higher-level solution behaviors that typically span multiple ARTs. They are sized and split into multiple features so that they can be implemented in a single PI.
Solution Epics – Epics that apply specifically to one Solution Train.
Nonfunctional Requirements (NFRs) – System qualities such as security, reliability, performance, maintainability, scalability, and usability; they are incorporated in the solution intent.
Solution Backlog – The holding area for upcoming capabilities and enablers, each of which can span multiple ARTs and is intended to advance the solution and build its architectural runway.
Solution Kanban – A method used to visualize and manage the flow of business and enabler capabilities from ideation to analysis, implementation, and release.
The Solution Train is the organizational vehicle that is used to coordinate the efforts of multiple ARTs and suppliers to deliver the world’s largest and most complex systems. These trains align and coordinate ARTs and suppliers so that they can collaborate like a single team but have all the advantages inherent in organizing using small teams and ARTs to scale the development and release effort.
A number of unique elements are present at the large solution level, yet any individual element of this level may also be applied to the Essential SAFe or Portfolio SAFe configurations. For example, solution intent and compliance might be used by a single ART that is building a medical device of modest scale. As illustrated in Figure 2, this is part of SAFe’s scalability and configurability.
