Large Solution SAFe


Large Solution SAFe is aimed at developing the largest and most complex solutions that typically requires multiples ARTs and suppliers, but  do not require portfolio level considerations.



1. Coordinate and integrate multiples ARTs and Suppliers


Solution Trains align ARTs to a common mission





ARTs power the Solution Train


  • Each ART within a Solution Train contributes to the development of a large solution
  • Solution Management, Solution Architect/Engineering and the STE (Solution Train Engineer) foster the coordination and the delivery of value




Suppliers play a key role in large solution development


  • Suppliers often play a key role in solution development. The overall Value Stream's agility is dependent on suppliers' agility.
  • Lean-Agile suppliers are treated as another ART, participating in all Solution Train events
  • Suppliers working traditional methodologies work against milestones, but are expected to attend pre- and post-PI Planning, Solution Demo and Solution Train Inspect & Adapt
  • SAFe enterprises help suppliers improve their processes and become more lean and Agile to the economic benefit of both organisations




Customers are inseparable from the development process


Customers are a critical aspect of development. Engaging them into the process depends on the type of the solution and the customer's impact


General Solutions


E.g: End user purchaser of a CRM system

Custom built solutions


E.g: Government purchaser of a defence system

  • Solution builder content authorities proxy the Customer
  • Solution Intent reflect facts and hypotheses
  • Frequently validates product assumptions
  • Scope, scheduled and budget at solution builders' discretion
  • Customer represents self
  • Defines fixed/variable Solution Intent
  • Directly validates product assumptions; attends planning and solution demos
  • Collaborative scope and schedule management; managed investment funding model


Prepare with Pre- and Post-PI Planning


  • Typically attended by: Customers, STE, Solution Management, Solution Architect/Engineering, Solution Train stakeholders and select representatives from ARTs and Suppliers


  • Pre-meeting helps build an aligned plan for the next PI and match solution demand to ART capacities


  • Post-meeting reviews, recaps, communicates and provides feedback


Pre-Planning structure

08:00 - 10:00 PI Summary reports


  • Align Product Managers, System Architects and other ART stakeholders to a common vision
  • Prepare content for ART PI Planning


  • Results of the previous PI execution
    • Outcomes of the Solution Demo or, if delayed, ART demos
    • Roll-up of the Program Predictability Measure to the Solution Train


  • Set of new features for every ART
  • Updates to the ART versions
10:00 - 10:30 Business context & Solution Vision
10:30 - 11:30

Top N Capabilities

11:30 - 13:30

Next PI features



Solution Train management review and problem solving


After the ARTs finish their management review and problem-solving, the STE facilitates a similar meeting for the Solution Train.


  • Common questions during the Solution Train management review and Problem-Solving:
    • What new dependencies have we identified?
    • Where do we need to adjust Vision? Scope? Resources?
    • Where are the bottlenecks?
    • What capabilities must be de-scoped?
    • What decisions must we make between now and tomorrow (for PI Planning meeting) to address these issues?


Post-Planning structure

09:00 - 12:00 PI Planning report


  • Understand the PI plan for the entire Solution Train
  • Make adjustments, if necessary, and communicate to the ARTs


  • Program PI Objectives form all ARTs
  • Solution Train board
  • Solution risks


  • Consolidated Solution Train PI Objectives
  • Solution Train roadmap updates
12:00 - 13:00 Lunch
13:00 - 15:00

Plan review, risk analysis and confidence vote

15:00 - ???

Plan re-work, if necessary

Planning retrospective and moving forward



Verify fitness for purpose with the Solution Demo


  • The Solution Demo is a major event in the life of the Solution
  • The Solution Train demos a fully integrated Solution, showing accomplishments of the previous Program Increment
  • Senior managers and high profile stakeholders review the progress
  • Action and investment decisions are based on this objective evidence



Solution Demo requires frequent solution integration


  • Frequent Solution Integration and testing provides the best objective evidence


  • A joint responsibility of ARTs and Solution Train's system teams


  • Provides early validation and regular risk reduction


  • Increases actual velocity



Solution team Inspect & Adapt


The Solution Train I&A workshop consists of three parts:

  1. Solution Demo
  2. Retrospective
  3. Problem-solving workshop

Participants are representatives from ARTs and Suppliers building the solution:

  • Release Train Engineers, Solution Train Engineers, System and Solution Architect/Engineering, Product and Solution Management, Customers
  • Portfolio stakeholders may also attend this workshop



2. Define Large Solutions


Solution and Solution Context


  • A solution is uniquely associated with one Value Stream and defined by Solution Intent
  • The Solution Context defines the environment in which the solution operates:
    • System of systems, e.g:
      • Avionics system as part of an aircraft
      • Product suite - Word Processor as part of an Office suite
    • Production infrastructure, e.g:
      • cloud environment where solution is deployed
    • Other application or systems in which the target solution is integrated


Capabilities describe Solution behaviours


A Capability describes the higher level behaviours of a Solution.


  • They are maintained in the Solution Backlog and are prioritised using WSJF
  • Written using a phrase, statement of benefits and acceptance criteria
  • Must be structured to fit within a single PI
  • Capabilities are split into Features for implementation




Capture knowledge in Solution Intent


Solution Intent:

  • Single source of truth as to the intended and actual behaviour of the Solution


  • Record and communicate requirements and design decisions
  • Facilitate continuous exploration and analysis activities
  • Align the Customer, System Builders and Suppliers to a common purpose
  • Support compliance, contractual, traceability, high assurance




Moving from variable to fixed Solution Intent


  • Preserve flexibility to enable evolution towards optimum solution alternative
  • To achieve that, fix only minimum requirements and designs
  • Consider the rest as assumptions and designs
  • Validate assumptions continuously, through repetitive learning cycles (PIs)
  • Drive exploration with Enablers
  • Converge on well defined (fixed) behaviours



Continuously evolve compliance documents


  • Evolve specifications and compliance documents each increment
  • Ensure alignment across all solution builders
  • Generate specifications and compliance documents from models to ensure single source of truth