SAFe Configuration Map


There are 4 configurations of SAFe, comprising of variations of the above levels:


  • Full - All 4 levels.
    • Represents the most comprehensive configuration. It supports building large, integrated solutions that typically require hundreds of people or more to develop and maintain.
  • Large Solution - Large Solution, Program and Team levels.
    • For enterprises that are building large and complex solutions, which do not require the constructs of the portfolio level.
  • Portfolio - Portfolio, Program and Team levels.
    • Provides portfolio strategy and investment funding, Agile portfolio operations, and Lean governance.
  • Essential - Program and Team levels.
    • The most basic configuration of the framework, providing the minimal elements necessary to be successful with SAFe.

Scaled Agile Framework

SAFe (Scaled Agile Framework) is a set of organisation and workflow patterns intended to guide enterprises in scaling lean and agile practices, to help businesses address the significant challenges of developing and delivering enterprise-class software and systems in the shortest sustainable lead time.


SAFe synchronises alignment, collaboration, and delivery for multiple Agile teams. Scalable and configurable, SAFe allows each organisation to adapt it to its own business needs. It supports smaller-scale solutions employing 50 – 125 practitioners, as well as complex systems that require thousands of people.


e* - Top 3


  • The Major concern is Value


  • ONLY management can change the system!
    • "It is not enough that management commit themselves to quality and productivity, they must know what it is they must do.
      • Such a responsibility cannot be delegated" - W. Edwards Deming
      • "... and if you can't come, send no one!"


Core Values e*

  1. Built-in Quality → Fail fast
  2. Program execution → The method
  3. Alignment → of the strategy
  4. Transparency → Trust

Agile Manifesto

The Agile Manifesto for Software Development consists of a set of Values and principles:


Vales of the Agile Manifesto

We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:


  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan


That is, while there is value in the items on the right, we value the items on the left more.



Principles of the Agile Manifesto

  1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  1. Welcome changing requirements, even in late development. Agile processes harness change for the customer's competitive advantage.
  1. Deliver working software frequently, from a couple of weeks to a couple of months, with a preference for the shorter timescale.
  1. Business people and developers must work together daily throughout the project.
  1. Build project around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  1. The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  1. Working software is the primary measure of progress.
  1. Agile processes promote sustainable development. The sponsors, developers and users should be able to maintain a constant pace pace indefinitely.
  1. Continuous attention to technical excellence and good design enhances agility.
  1. Simplicity - The art of maximising the amount of work not done - is essential.
  1. The best architectures, requirements and designs emerge from self-organising teams.
  1. At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behaviour accordingly.


SAFe House of Lean



  • The Goal: Value e*
    • Shortest sustainable lead time
    • Best quality and value to people and society
    • High morale, safety and customer delight
  • Respect for people and culture
    • People do all the work
    • Your customer is whoever consumes your work
      • Don't overload them
      • Don't make them wait
      • Don't force them to do wasteful work
      • Don't impose wishful thinking
    • Build long-term relationships based on trust
    • Cultural change comes first, not last
    • To change the culture, you have to change the organisation
  • Flow
    • Optimise continuous and sustainable throughput of value
    • Avoid start-stop project delays
    • build quality in; flow depends on it
    • understand, exploit and manage variability
    • Integrate frequently
    • Informed decision making via fast feedback

"Operating a product development process near full utilisation is an economic disaster" - burnout!


  • Innovation (Blue Sky)
    • Producers innovate; Customers validate
    • Get out of the office (Gemba* - the real place) - and close to the work
      • "No useful improvement  was ever invented at a desk" - Taiichi Ohno
    • Provide time and space for creativity
    • Apply innovation accounting - review
    • Pivot without mercy or guilt (emotion)
  • Relentless improvement (upon current processes)
    • A constant sense of danger
    • Optimise the whole
    • consider facts carefully, then act quickly
    • apply lean tools to identify and address root causes
    • Reflect at key milestones; identify and address shortcomings

"Those who adapt the fastest, win"


  • Leadership
    • Lead the change - Motivate
    • Know the way; emphasise life long learning. Mistakes -> Learn
    • Develop people
    • Inspire and align with mission; minimise constraints
    • Decentralise decision making
    • Unlock the intrinsic motivation of knowledge workers

"People are already doing their best; the problem is with the system.

Only management can change the system"

SAFe Lean-Agile principles

1. Take an economic view

The entire chain of leadership, management and knowledge workers must understand the economic impact of the choices they’re making. Traditionally, the economic constraints on their activities are known only to the decision-makers and authorities who understand the business, marketplace, and customer finances. However, centralising such knowledge means that a worker’s everyday decisions are either made without this information or escalated to those who have it.


Deliver early and often

*Marshmallow Challenge

Deliver value incrementally

Value is higher early on

Understand trade-off parameters

  • Sequence jobs for maximum benefit
  • Do not consider money already spent
  • Make economic choices continuously
  • Empower local decision making
  • If you only quantify one thing, quantify the cost of delay


2. Apply systems thinking


Systems thinking takes a holistic approach to solution development, incorporating all aspects of a system and its environment into the design, development, deployment, and maintenance of the system itself.


3 Aspects of Systems Thinking

  • Optimising a component does not optimise the system
  • For the system to behave well as a system, a higher level of understanding of behaviour and architecture is required
  • The value of a system passes through its interconnections
  • A system can evolve no faster than its slowest integration point

Optimise the full value stream

  • Most problems will surface as delays
  • Most of the time spent getting to market is a result of these delays
  • Reducing delays is the fastest way to reduce time to market
  • Focus on the delays!


3. Assume variability; preserve options


Developers are naturally inclined to reduce variability, since it could lead to bad outcomes. However, the opposite could also be true. More so, the economics associated with the timing and type of variability is what determines the value of the outcome and a focus on eliminating variability too soon perpetuates a risk-avoidance culture where people feel they can't make mistakes and learn from experience what does/doesn't work.


Development occurs in an uncertain world

Apply a set based approach

Lean knowledge works understand that very little is actually known at the beginning of a project. Traditional design practices, however, tend to converge upon a single option and then modify it until it eventually meets the system intent.


Alternatively, a Set-Based Design (SBD) casts a wider net, considering multiple designs at the start, followed by continuously evaluating the economic  and technical trade-offs and eliminate the weaker options over time to ultimately converge on a final design, based on knowledge gained up to that point.



4. Build incrementally with fast, integrated learning cycles


Iterative learning cycle

  • Fast feedback accelerates knowledge
  • Improves learning efficiency by decreasing the time between action and effect
  • Reduces the cost of risk-taking by truncating unsuccessful paths quickly
  • Facilitated by small batch sizes
  • Requires increased investment in development environment

Apply fast learning cycles

  • Integration points accelerate learning
  • Development can proceed no faster than the slowest learning loop
  • Improvement comes through synchronisation of design loops and faster learning cycles


Integration points reduce risk

  • The more frequent the points, the faster the learning
  • Integration points create knowledge from uncertainty



5. Base milestones on objective evaluation of working systems


Problem: Phase gate milestones

  • Force too early design
  • Assume a point solution exists and can be built right first time
  • Create huge batches and long queues
  • Centralises requirements and design in program management

Problem: Phase gate milestones

  • Phase gates fix requirements and designs too early making adjustments costly and late as new facts emerge
  • Tracking progress via traditional milestones delays critical learning points until it's too late

Apply objective milestones

  • PI Demos are orchestrated to deliver objective progress, product and process metrics

Iterate to optimum solution

  • Objective milestones facilitate learning and allow for continuous, cost effective adjustments towards an optimum solution



6. Visualise and limit WIP, reduce batch sizes and manage queue lengths


Long queues are bad

Reduce queue lengths

  • Faster processing time decreases wait
  • Control wait times by controlling queue lengths

Visualise & limit work in process to control queues

  • BVIR - Big Visible Information Radiator

Importance of small batches

  • Small batches go through the system faster with lower variability
  • Large batches increase variability
  • High utilisation increase variability
  • Severe project slippage is the most likely result
  • Most import batch is the transport (handoff) batch
  • Proximity (col-location) enables small batch size
  • Good infrastructure enables small batches

Finding optimum batch size

  • Optimum batch size is an example of a U curve optimisation
  • Total costs are the sum of the holding costs and transaction costs
  • Higher holding costs shift batch size lower

Reduce Batch Size

  • Reducing transaction costs reduces total costs and shifts optimum batch size lower
  • Reducing batch size:
    • Increases predictability
    • Accelerates feedback
    • Reduces rework
    • Lowers cost
  • Batch size reduction probably saves twice what you think



7. Apply cadence, synchronise with cross domain planning


Cadence & Synchronisation

  • Cadence
    • Converts unpredictable events into predictable ones. Lowers cost. e*
    • Makes waiting times for new work predictable
    • Supports regular planning and cross-functional organisation
    • Limits batch sizes to a single interval
    • Controls injection of new work
    • Provides scheduled integration points
  • Synchronisation (PI Planning event)
    • Causes multiple events to happen at the same time
    • Facilitates cross-functional trade-offs
    • Provides routines dependency management
    • Supports full system and integration and assessment
  • Provides multiple feedback perspectives e*

Control variability with planning cadence

Synchronise with cross-domain planning

  • All stakeholders face-to-face
  • Management sets the mission, with minimum possible constraints
  • Requirements and design happen
  • Important stakeholder decisions are accelerated
  • Teams create and take responsibility for plans


8. Unlock the intrinsic motivation of knowledge workers


Drive: The puzzling puzzles of Harry Harlow




9. Decentralise decision making


Define the economic logic behind a decision; empower others to actually make them.


  • Infrequent - Not made very often and usually not urgent
    • e.g. internationalisation strategy
  • Long lasting - Once made, highly unlikely to change
    • e.g. common technology platform
  • Significant economies of scale - provides large and broad economic benefit
    • e.g. compensation strategy
Decentralise everything else

  • Frequent & common - routine, every day decisions
    • e.g. team & program backlog
  • Time critical - High cost of delay
    • e.g. point of release to customer
  • Require local information - Specific and local technology or customer context is required
    • e.g. feature criteria


The above Principles should be used (as a guide) in the Retrospectives

(idea: laminated copies of each of the principles available / on walls)

Program and Solution Backlogs

Program and Solution Backlogs, estimated in story points, are lists (repositories) of prioritised items managed through their respective Kanban systems.


Program Backlog

  • Holding area for upcoming features
  • Intended to address user needs and deliver business benefits for a single ART (Agile Release Train)
  • Contains enabler features necessary to build the Architectural Runway
  • Responsibility: Program Management



Solution Backlog

  • Holding area for upcoming Capabilities and enablers
    • Each of which can span multiple ARTs
    • Intended to advance the solution and build its architectural runway
  • Responsibility: Solution Management


Refining the Backlog

  • ARTs & Solutions Trains run at a steady 8-12 weeks PI cadence
    • of: planning, execution, demo and I&A
  • Appearing at a Pre-PI Planning or PI Planning without a well elaborated backlog adds unacceptable risk to the upcoming PI
  • Refinement typically includes:
    • Reviewing & updating backlog item definitions and developing Acceptance Criteria and benefit hypothesis
    • Working with teams to establish technical feasibility and scope estimates
    • Analysing ways to split the backlog items into smaller chunks of incremental value
    • Identifying the enablers to support new features and capabilities and estimating their capacity allocation


Prioritising the Backlogs

  • Critical economic driver for the solution
  • Product and Solution management utilise WSJF prioritisation for job sequencing


WSJF - Weighted Shortest Job First


Preparing for PI Planning

  • Product and Solution Management:
    • Carry out final backlog preparation
    • Update the Vision briefings
    • Work with Product Owners to further socialise the backlog before the event
  • System and Solution Architect/Engineering:
    • Update enabler definitions and models
    • Develop use cases that illustrate how the features and capabilities work together to deliver value to the end user


Optimising Value and Solution Integrity with Capacity Allocation

  • Challenges for every ART and Solution Train:
    • How to balance the backlog of business features and capabilities with the need to:
      • continuously invest in the architectural runway
      • provide time for exploration of requirements and design for future PIs
      • create prototypes and models to enhance visibility into problem areas
  • To avoid velocity reduction ARTs must invest continuously in implementing the Enablers of the solution


To address this problem, teams apply capacity allocation, where they decide how much of the total effort can be used for each type of activity in the upcoming PI.


At each PI boundary, we agree:

  • Percentage of resources to be devoted to new features or capabilities versus enablers
  • System and Solution Architects/Engineering have authority to prioritise Enabler work
  • Product and Solution Management have authority to prioritise business backlog items
  • Jointly prioritise work based on economics
  • Collaborate on sequencing work that maximises customer value


Backlogs, Queues, Little's Law and Wait Times

  • Program and Solution Backlogs can have the most significant impact on delivery time and throughput.
  • Little’s Law (Principle 6) illustrates that the average wait time for an item in a queue is equal to the average length of the queue divided by the average processing rate for an item in a queue. The longer the queue, the higher the wait time, and the higher the variability.
  • Long queues are bad (Principle 6), causing decreased motivation, poor quality, longer cycle times, higher variability (think Starbucks), and increased risk.
  • Teams must:
    • Actively manage their backlogs and keep them short for a development program to be fast and responsive
    • Limit commitment to longer term work, since other more important items might arise


The Program Kanban facilitates the flow of Features through the Continuous Delivery Pipeline:


Essential SAFe


Essential SAFe comprises of a number of Agile delivery Teams along with their various roles, activities, events, ceremonies and processes to build and deliver value, augmented by the Program level dedicated to continuously deliver solutions within an ART (Agile Release Train).


The ART is a virtual team of Agile cross-functional teams and stakeholders that develop and deliver solutions incrementally using a series of fixed length iterations within a PI (Program Increment) timebox. The ART aligns teams to a common business and technology mission.


The PI is a timebox during which the ART (Agile Release Train) delivers incremental value in the form of working, tested software and systems.


  • PI - Program Increment
    • ~10 weeks duration, comprising of 5 Sprints:
      • 4 x standard Backlog based iterations
      • 1 x Innovation & Planning iterations


The Innovation & Planning iteration provides:

  • Estimating buffer for meeting PI Objectives
  • Dedicated time for innovation, training/education, PI Planning and I&A (Inspect & Adapt) events


With so much dedicated focus on delivery, the team might lose focus on other aspects such as innovation, i.e. the potential "Tyranny of the urgent iteration" might override the opportunity to innovate, hence SAFe provides a dedicated Innovation & Planning iteration.


At the team level the usual Agile processes and ceremonies (Kanban, Backlog, Scrum) are followed by the ongoing Sprints to deliver NFRs (Non-Functional requirements) and Stories taken from the Team Backlog as prioritised by the PO (Product Owner).  Additionally Enablers are also delivered that provide the supporting activities required to extend the Architectural Runway to provide future business functionality.


The Architectural Runway provides the technical foundation for developing business initiatives and implementing new features and/or capabilities, consisting of exiting code, components and infrastructure to implement near term features without excessive redesign and delay. Since the development of new features and capabilities consumes the architectural runway, continual investment must be made to extend it by implementing Enablers. Some enablers fix existing problems with the Solution, such as improving the performance or UX (User Experience). Others might provide foundational capabilities that will be used to support future functionality.


At the Program level, Product Management are responsible for Program Backlog, which consists of stories defined as a result of their research and collaboration with various stakeholders such as Customers, Business Owners, Product Management, Product Owners, Systems and Solution Architects/Engineering, etc.


The Program Backlog items are identified, refined, prioritised and sequenced using WSJF (Weighted Shorted Job First) to provide an economic success for the solution.


System Demos provide an integrated view of new features for the most recent iteration delivered by all the teams in the ART and gives each stakeholder an objective measure of progress during a PI.


On top of all this we have the Continuous Delivery Pipeline (aka "pipeline") which represents the workflows, activities and automation needed to provide a continuous release of value to the Customer.


DevOps is a mindset, culture and set of technical practices, essential within a SAFe enterprise, that provides communication, integration, automation and collaboration amongst all those required to plan, develop, test, deploy, release and maintain a solution.


Built-In Quality (SAFe core principle) practices ensure that each increment's solution delivers the required quality standards throughout development and is essential to allow a rapidly changing business environment to adapt to provide new functionality within the shortest lead time.


e* Agile Team should:

  • Be Empowered, Self Organising, Self Managing, Cross-Functional
  • Deliver valuable, tested, working system every two weeks
    • Shorter iterations (because Fail Fast)
  • Use a team framework which combines the best of Scrum project management, XP inspired technical practices and Kanban for flow.
  • Team MUST be Agile trained!


Team of Agile Teams:

  • Self organising, self managing, team of Agile teams
  • Delivers working, tested full system every two weeks
  • Operates with Vision, Architecture and UX guidance
  • Common iteration lengths and estimating
  • Face-to-Face Planning for Collaboration, Alignment and Adaption

PI Planning

This is a BIG event and pays huge business benefits, including:

  • Establishing face-to-face communication across all team members and stakeholders
  • Building the social network the ART depends upon
  • Aligning development to business goals with the business context, Vision and Team & Program PI Objectives
  • Identifying dependencies and fostering cross-team and cross-ART collaboration
  • Providing the opportunity for 'just the right amount' of architecture and Lean User Experience (UX) guidance
  • Matching demand to capacity, eliminating excess WIP
  • Fast decision making



What you need to know before hand!


The Agile Release Train

  • Virtual organisation of 5 - 12 teams (50 - 125+ individuals) that plans, commits and executes together e*
  • PI (Program Increment) is a fixed timebox; default is 10 weeks
  • Synchronised iterations and PIs
  • Aligned to a common mission via a single Program Backlog
  • Operates under architectural and UX guidance
  • Frequently produces valuable and evaluable system-level Solutions



Value streams cut across organisational silos

  • Optimised for vertical communication
  • Friction across the silos
  • Location via function
  • Political boundaries between functions



Build cross-functional Agile Teams

  • Cross-functional, self organising entities that can define, build and test a feature or component
  • Optimised for communication and delivery of value
  • Deliver every two weeks



Agile Teams power the train

  • Coach the Agile team and facilitate team meetings
  • Removes impediments; protects the team from outside influence
  • Attends Scrum of Scrum meetings - mandatory! e*


  • Defines and accepts stories
  • Acts as the customer for developer questions
  • Works with product management to plan PIs


  • Create and refine user stories and acceptance criteria
  • Define / Build / Test / Deliver stories
  • Develop and commit to Team PI Objectives and iteration plans
  • Three to nine members



Cross-functional Agile Release Trains teams deliver value



Program roles govern the train


  • Release Train Engineer acts as the Chief Scrum Master for the train
  • Product Management owns, defines and prioritises the Program Backlog
  • System Architect / Engineering provides architectural guidance and technical enablement to the teams on the train
  • The System Team provides processes and tools to integrate and evaluate assets early and often
  • Business Owners are the key stakeholders on the Agile Release Train




Inputs and Outputs

  • Inputs:
    • Business context
    • Roadmap and Vision
    • Top 10 Features of the Program Backlog
  • Outputs
    • Committed PI Objectives
      • Set of SMART Objectives created by each team with Business Value assigned by Business Owners
    • Program Board
      • Highlighting new Feature delivery dates, feature dependencies among teams and with other ARTs, and relevant Milestones



  • Organisation readiness
    • Planning and scope context
    • Business alignment
    • Agile teams
  • Content readiness
    • Executive briefing
    • Product Vision briefing(s)
    • Architecture vision briefing
  • Facility readiness
    • Facility logistics
    • Facility/tech support
    • Communication channels



PI Planning Event

  • Cadence based PI Planning meetings are the pacemaker of the Agile enterprise

If you're not doing PI Planning, you're not doing SAFe!

  • Two days every 8 - 12 weeks (10 is typical)
  • Everyone attends in person
  • Product Management owns Feature priorities
  • Development teams own story planning and high level estimates
  • Architect/Engineering and UX work as intermediaries for governance, interfaces and dependencies



Estimate Stories with relative story points

  • A Story point is a singular number that represents:
    • Volume: How much is there?
    • Complexity: How hard is it?
    • Knowledge: What do we know?
    • Uncertainty: What's not know?
  • Story points are relative
    • They are not connected to any specific unit of measure
  • Compare with other stories
    • An 8 point story, should take 4 times longer than a 2 point story



Apply Estimating Poker for fast, relative estimating


  • Estimating Poker combines expert opinion, analogy and disaggregation for quick but reliable estimates
  • All team members must participate
  • Recommended to use Fibonacci series with a max of 8, due to small batching
  1. Each estimator gets a deck of cards
  1. Reads a job
  1. Estimators PRIVATELY select cards
  1. Cards are turned over
  1. Discuss differences
  1. Re-estimate
  • Estimation is a whole team exercise, that:
    • Increases accuracy by including all perspectives
    • Builds understanding
    • Creates shared commitment



Day 1 - Create & review draft PI plans

Why are we here?

  • Presented by the RTE:
    • Alignment to a common mission!
    • We are here to gain alignment and commitment around a clear set of prioritised objectives


Day 1 Agenda

08:00 - 09:00

Business Context


  • State of the business and upcoming objectives
09:00 - 10:30

Product/Solution Vision

(->Product Manager)

  • Vision and prioritised features
10:30 - 11:30

Architecture Vision and

development practices

(->System Architect)

  • Architecture, common frameworks, etc.
  • Agile tooling, engineering practices, etc.
11:30 - 13:00

Planning context

and lunch


  • Facilitator explains planning process
13:00 - 16:00

Team breakouts


  • Teams develop draft plans and identify risks and impediments
  • Architects and product Managers circulate
16:00 - 17:00 Draft plan review
  • Teams present draft plans, risks and impediments
17:00 - 18:00

Management review and

problem solving e*


end of day 1

  • Adjustments made based on challenges, risks and impediments


Planning Guidance

  • Expect the first PI Planning to feel a bit chaotic
    • Future PI Planning meetings will become more routine
  • Product Owners - Have the content authority to make decisions at the user story level
  • Scrum Masters - Have the responsibility to manage the timebox, dependencies and ambiguities


Features are implemented by Stories

  • Features are decomposed into Stories by the teams on the train
  • Small increments of value that can be developed in days and are relatively easy to estimate
  • Teams on the train collaborate to deliver features incrementally via user Stories
  • Features fit in one PI for one ART
    • Stories fit in one iteration for one team
  • Enabler Stories represent different types of work e*:
    • Exploration (prototyping)
    • Architecture
    • Infrastructure
    • Compliance


Align to a mission with PI Objectives

  • ~ 5 - 10 Objectives are business summaries of what each team intends to deliver in the upcoming PI
  • They often map directly to the features in the backlog (but not always) e.g.:
    • Aggregation of a set of features, stated in more concise terms
    • A milestone, like a trade show
    • An Enabler Feature needed to support the implementation
    • A major refactoring


Maintain predictability with stretch objectives

  • Stretch objectives do not count in velocity/capacity
  • They are planned and aren't extra things to do, just in case you have time
  • But, they are not included in the commitment, thereby making the commitment more reliable
  • If a team has low confidence in meeting a PI Objective, encourage them to move it to a stretch
  • If an item has many unknowns, consider moving it to stretch and put in early spikes


Starting fast with capacity based planning

  • Normalised estimation technique:
    • For every full time developer and tester on the team, give the team eight points (adjust for part timers)
    • Subject on pint for every team member vacation day and holiday
    • Find a small story that would take about half a day to develop and half a day to test and validate.
      • Call it 1
    • Estimate every other story relative to that one
    • Never look back (don't worry about recalibrating)


Setup your team area

  • Estimate capacity (velocity) for each iteration (sprint)
  • Identify PI Objectives
    • Identify Stretch Objectives
  • Identify Risks


Team Breakout

  • Identify and resolve ambiguities and manage dependencies
  • Negotiate with:
    • Product Owner
    • Other teams
    • Business Owners
  • Try to limit stories to 8 points
  • PI Objectives written in CLEAR business (as opposed to technical) language
  • Stretch Objectives identified
  • Program Risks identified


SoS - Scrum of Scrums

  • RTE conducts the SoS Sync
  • Participants include all SMs and others (where appropriate)
  • Sync Questions:
    • Has capacity (velocity) been identified for each iteration?
    • Have all stories been identified and story points estimated?
    • Have dependencies with other teams been identified and/or resolved?
    • Have trade-offs and conflicting priorities been discussed with Business Owners?
    • Have any program Risks been identified?
    • Read to start writing PI Objectives?
    • Anything required to be discussed with other other SMs (in the meet after)?
  • RTE holds a Meet After to discuss any issues


Draft plan review

  • Tightly timeboxed event
  • Defined:
    • Capacity (velocity)
    • Draft PI Objectives
    • Potential Risks
    • Dependencies
    • Impediments


Management Review & Problem Solving

  • End of Day 1
  • Management meet to make adjustments to scope and objectives based on the day's planning
  • Common questions:
    • What did we just learn?
    • Where do we need to adjust the Vision? Scope? Resources?
    • Where are the bottlenecks?
    • What features must be de-scoped?
    • What decisions must we take between now and tomorrow to address these issues?



Day 2 - Finalise plans and establish Business Value


Day 2 Agenda

08:00 - 09:00

Planning adjustments


  • Planning adjustments made on previous day's management planning
09:00 - 11:00

Team breakouts


  • Teams develop final plans and refine risks and impediments
  • Business Owners circulate and assign Business Value to team objectives
11:00 - 13:00

Final plan review

and lunch

  • Teams present final plans, risks and impediments
13:00 - 14:00 Program risks
  • Remaining program level risks are discussed and ROAMed*
14:00 - 14:15 PI confidence vote
  • Team and program confidence vote
14:15 - ???

Plan rework

(if necessary)


  • If necessary, planning continues until commitment is achieved



Planning retrospective and

moving forward

  • Retrospective
  • Moving Forward
  • Final Instructions

*ROAM: Resolved, Owned, Accepted, Mitigated



Planning Adjustments

  • Management describe any changes to planning scope and resources
  • Possible changes:
    • Business priorities
    • Adjustment to plan
    • Changes to scope
    • Movement of people

Team breakout #2

  • Continue planning based on agenda from previous day, making appropriate adjustments
  • Finalise team PI Objectives
  • Business Owners assign business value to the PI Objectives from low (1) to high (10)
  • Finalise the PI plan
  • Consolidate risks, impediments and dependencies
  • Stretch objectives provide the capacity and guard band needed to increase cadence based delivery reliability

Final plan review and lunch

  • Teams and Business Owners peer review all final plans
    • Changes to capacity (velocity) and load
    • Final PI Objectives with Business Value
    • Program Risks and impediments
  • All teams present their plans to the group
  • If Business Owners accept the plans, move one, else re-plan (after the review)
  • At the end of each team's time slot, the team state their risks and impediments
    • No attempt to resolve them in this short timebox
  • Present PI Objectives and Program Risks


Program Risks

  • Resolved in front of the whole train
  • One by one
  • Addressed with honesty and transparency
  • ROAM Categorised e*:
    • Resolved - agreed no longer a concern
    • Owned - someone has taken ownership since it cannot be resolved at the meeting
    • Accepted - some risks are just facts / problems that must be understand and accepted
    • Mitigated - plan identified to reduce the impact


PI Confidence vote

  • 'Fist of Five' technique used by everyone
  • If average is three or above, management should accept the vote
  • If less than three the team reworks the plan
  • Any person voting with two fingers or fewer should be given the opportunity to voice their concern
    • Might add to risks, require re-planning, or simply be informative


Plan rework

  • If necessary, teams rework their plans until a high confidence level can be reached.
  • This is one occasion where alignment and commitment are valued more highly than adhering to a timebox.


Planning retrospective and moving forward

  • RTE leads a brief Retrospective of the PI Planning event
    • What went well?
    • What didn't?
    • What can be done better next time?
  • Next steps discussion and final instructions:
    • Capturing the team PI Objectives and user stories in the preferred Agile project management tool
    • Reviewing team and program calendars
    • Agreeing Daily Stand Up meeting times and locations
    • Reviewing locations for the iteration Planning meetings



RTE take away: Integrated PI Objectives

  • RTE and ART stakeholders summarise individual team PI Objectives into a set of Program PI Objectives




At the Program level each Feature (a service that fulfils a stakeholder need) includes a benefit hypothesis and acceptance criteria, and is sized or split to be delivered by a single ART in a PI. Features also lend themselves to the Lean UX process model which includes a MMF (Minimum Marketable Feature), benefit hypothesis and acceptance criteria. The MMF helps limit scope and investment, enhances agility and provides fast feedback.


Continuous Delivery Pipeline

The Continuous Delivery Pipeline represents the workflows, activities and automation required to provide a continuous release of value to the end user, and consists of four elements:

  • Continuous Exploration
  • Continuous Integration
  • Continuous Deployment
  • Release on Demand




Continuously deliver value with ARTs

Program events drive the train, by creating a closed loop system to keep the train on the tracks





Art Sync to coordinate progress

  • Programs coordinate dependencies through ART Sync meetings
  • SMs and POs review Program Kanban and pull in more work base on available capacity
  • Discuss new work, prioritise, schedule meet afters and make deployment and release decisions as needed
  • The PI Planning's Program Board facilitates reviewing items in the 'implementing' state, including discussions of dependencies and execution

Scrum of Scrums

  • Visibility into progress and impediments
  • Facilitated by RTE
  • Participants: SMs, other select team members / SMEs if necessary
  • Weekly or more frequently, 30 - 60 minutes
  • Timeboxed and followed by a 'meet after'

PO Sync

  • Visibility into progress, scope and priority adjustments
  • Facilitated by RTE or PrdM
  • Participants: PrdMs, POs, other stakeholders and SMEs as necessary
  • Weekly or more frequently, 30 - 60 minutes
  • Timeboxed and followed by a 'meet after'

Continuous Exploration


Consists of three separate activities:


Product Management facilitates a continuous collaborative process:

  • System Architect/Engineers
  • Customers
  • BOs & Stakeholders
  • POs and teams


Product Management uses a variety of activities and techniques:

  • Customer visits
  • Gemba walks
  • Elicitation
  • Trade studies
  • Market research


Based on the previous activities, Product Management synthesises findings into Vision, Roadmap and Program Backlog

  • Program kanban
  • Funnel, analysis and backlog make a good starting point
  • Features that make it to the Program Backlog are ready for WSJF prioritisation to determine which ones should be pulled into PI Planning


Vision inspires action

Vision provides a longer term context:

  • How will our future solution solve the larger customer problems?
  • How ill it differentiate us?
  • What is the future context that our solutions will operate?
  • What is our current business context and how must we evolve to meet this future state


Elaborate features with Lean UX

  • Define a benefit hypothesis
  • Design collaboratively
  • Build MMF (Minimum Marketable Feature)
  • Evaluate  MMF against the hypothesis



Features have Benefit Hypothesis and Acceptance Criteria

  • "Feature" is an industry standard term familiar to marketing and Product Management
  • Benefit hypothesis justify Feature implementation cost and provide business perspective when making scope decisions
  • Acceptance Criteria are typically defined during Program Backlog refinement
  • Reflects Functional and Nonfunctional requirements
  • Fits in one PI



Prioritise Features for Optimal ROI

  • In a flow system, job sequencing is the key to economic outcomes
  • To prioritise, we need to know two things:
    • What is the CoD (Cost of Delay) in delivering value?
    • What is the cost to implement the valuable thing?

In the general case, give preference to the jobs with shorter Duration and higher CoD using WSJF:




Three factors contributing to Cost of Delay:


User-Business Value - Relative value to the customer / business

  • They prefer this over that
  • Revenue impact?
  • Potential penalty or other negative impact?
Time Criticality - How User/Business Value decays over time

  • Is there a fixed deadline?
  • Will they wait for us or move to another solution?
  • What is the current effect on customer satisfaction?
RR / OE - Risk Reduction / Opportunity Enablement value - What else does this do for our business

  • Reduce the risk of this or future delivery?
  • Is there value in the information we will receive?
  • Enable new business opportunities?

Duration (Job size)

  • Could be hard to determine, especially early on when we might not know who's going to do the work or the capacity allocation for the teams.
  • In system, with fixed resources, Job size is a good proxy for duration



Architectural Runway

  • Consists of existing code, hardware components, etc. that technically enable near term business features
  • Enablers build up the runway
  • Features consume it
  • Architectural Runway must be continuously maintained
  • Use Capacity Allocation (a percentage of the train's overall capacity in a PI) for Enablers that extend the runway


Emergent design and intentional architecture

  • Every teams deserves to see the bigger picture. Every team is empowered to design their part.
  • Emergent design - teams grow the system design as user stories
  • Intentional architecture -  fosters team alignment and defines Architectural Runway
  • A balance between emergent design and intentional architecture is required for speed of development and maintainability

Continuous Integration

CI (Continuous Integration) is the process of taking features from the Program Backlog and developing, testing, integrating and validating them in a staging environment where they are ready for deployment and release, often requiring a three tier approach of Story integration, System integration and Solution integration.




Story Integration

Since Features are too abstract to be coded directly, they must be converted to Stories during PI Planning. Each story is defined, coded, tested and integrated into the baseline.


Team members integrate their work frequently and apply automated continuous integration environments.


To ensure new features work compatibly with all existing functionality, the system must be continually tested as well, so the team apply automated testing and test-first development (aka TDD).




Automate Story Tests


Developing incrementally means that the system must be continually tested as well, otherwise there is no way to assure that the new stories work compatibly with all existing functionality.


Teams therefore apply test-first development (/TDD), which includes creating unit and acceptance tested for each story that gets implemented.


To avoid building 'technical debt', Agile teams develop and apply these tests in the same iteration in which they implement the  story.


This figure illustrates Passing Vs Not (yet) Passing and broken tests are the real indicators of progress:




System Integration


To fully tested the features, system level integration and testing are required. With support of the System Team, the work of all the teams on the ART must be frequently integrated to assure that the system is evolving as anticipated:


  • Teams continuously integrate assets - leaving as little as possible to the System Team
  • Integrate every vertical slice of a user story
  • Avoid physical branching for software
  • Frequently integrate hardware branches
  • Use development by intention inc case of inter-team dependencies
    • define interface and integrate first
    • then add functionality


System level testing should be carried out as frequently as possible during the iteration, ideally daily. However, whatever the circumstances, full system integration must be carried out at least once per iteration.


All this work comes together in the system demo, which demonstrates the accumulated features and is the true indicator of ART progress.


Automate Feature Tests


As with user stories, features must be continuously tested against their acceptance criteria to ensure new functionality is developed. Again the test-first approach is applied, in this case by automating as many of the feature tests as possible.


  • Test First: Automate now!
    • Else, velocity is bottle-necked, quality is speculative and scaling is impossible
  • Automated tests are implemented in the same iteration as the functionality
  • The team builds functionality that also automates the tests
  • Created an isolated test environment
  • Actively maintain test data under version control
  • Passing vs not-yet-passing and broken automated tests are the real iteration progress indicator



Solution Integration


Building Large Solutions (i.e. those that require multiple ARTs and suppliers to develop them) requires an additional level of integration to pull all the work together.


Full or partial integration occurs over the course of a PI, with full solution integration being carried out at least once per PI, as per:



Solution Demo


  • Features are functionally complete or "toggled" so as not to disrupt demonstrable functionality
  • New features work together and with existing functionality
  • Takes place after the teams' demo
  • Carried out from the Staging environment, which should resemble Production as closely as possible




Enabling Continuous Integration

  • Integrate often
    • The more frequently teams integrate, the quicker they find problems. The harder it is to do, the more frequent the need to do it
    • Eliminate impediments and add automation along the way -> lead to faster learning cycles and less re-work
  • Make integration results visible
    • When integration processes break, everybody should know how and why it broke
    • When it's fixed, new tests should be developed to detect the problem earlier and prevent it from happening again
  • Fixing failed integrations is a top priority
    • If teams just keep working during an integration failure, it doesn't create the right sense of urgency and importance to fix the problem
    • To highlight the problem, teams often use flashing lights to draw attention to a broken build and visible indicators display the percentage of the time the system remains broken
  • Establish common cadence
    • Integration points are easier when all the teams are moving at the same constant rhythm
    • If full CI can't be accomplished during the course of an iteration, teams can make near term trade-offs on what can be integrated, while continuously improving their techniques and infrastructure toward this goal
  • Develop and maintain proper infrastructure
    • Effective continuous integration depends on the availability of test and staging environments
    • Infrastructure is an investment
    • Lean-Agile leaders take the long view and make investments today to increase velocity for the marathon ahead
  • Apply supportive engineering practices
    • Continuous integration is easier when the system is deigned with those concerns in mind
    • Test-First Development / TDD and designing for testability call for better solution modularity and separation of concerns, as well as the use of primary interfaces and physical test points.


Start Now! - it may be challenging, at first, but resistance will fade as a result of better deliveries!


  • an approach to bridge the gap between Development and Operations to deliver value faster and more reliably
  • a set of practices that automates the processes between software development and IT teams, in order that they can build, test, and release software faster and more reliably
  • a concept founded on building a culture of collaboration between teams that historically functioned in relative silos



A CALMR approach to DevOps:


  • Culture
    • Establish a culture of shared responsibility for development, deployment and operations
  • Automation
    • Automate the continuous delivery pipeline
  • Lean Flow
    • Keep batch sizes small, limit WIP and provide extreme visibility
  • Measurement
    • Measure the flow through the pipeline
    • Implement application telemetry
  • Recover
    • Architect and enable low risk releases
    • Establish fast recovery, fast reversion and fast fix-forward



DevOps is a Cultural shift first of all and requires a tolerance for failure and rapid recovery, and rewards risk taking!


Sharing discoveries, practices, tools and learning across silos must be actively encouraged.

Automate Everything


Manual processes are the enemy of fast value delivery, high productivity and safety. But automation is not just about saving time, it also enables the creation of repeatable environments and processes, which are self-documenting and therefore easier to understand, improve, secure and audit.


ALM - Application Lifecycle Management

  • CA Agile Central
  • Version One
  • Agile Craft
  • tools for Model-Based Systems Engineering


  • ANT
  • Maven
  • Bamboo
  • Jenkins


  • JUnit
  • NUnit
  • Maven
  • Cucumber
  • FitNesse

CI - Continuous Integration

  • Cruisecontrol
  • Jenkins
  • Continuum

Artifact Managament Repository

  • Artifactory
  • Archiva
  • JFrog

CD - Continuous Deployment

  • Capistrano
  • UrbanCode
  • Ansible
  • Puppet

Continuous Deployment

CD - Continuous Deployment is the process that takes features that have passed through continuous exploration and continuous integration and then deploys them into the staging and production environments, readied for release.


CD is an important practice for every team, team member and the ART




Automation of the Continuous Delivery pipeline


The deployment process needs to be automated and it is recommended that:

  • Match development environments to production as much as feasibly possible
  • Maintain a staging environment that emulates production
  • Deploy a working system to staging every iteration
  • Automate testing of Features and performance tests
  • Automate deployment
    • Everything under version control
    • Automatically build environments
    • Automate the actual deployment process


Lean Flow accelerates delivery


  • Identify bottlenecks and balance the amount of WIP against the available development and operations capacity
  • Decrease the batch sizes of the work
  • Manage and reduce queue lengths


Measure everything:


  • Collect data on business, application, infrastructure and client layers
  • Collect data about the deployment pipeline itself
  • Store logs in ways that enable analysis
  • Different telemetry for different stakeholders
  • Broadcast measurements
  • Overlay measurements with events (deploys, releases)
  • Continuously improve telemetry during and after problem solving


Architect for release-ability and Recovery


  • Stop the line mentality - all hands
  • Plan for and rehearse failures
  • Build the environment for both roll-back and fix-forward
  • Use tools such as:
    • Feature toggles - switch versions
    • Dark launches - silent updates
    • Chaos Monkey - DR
    • Canary Releases - pilots

Release on Demand


Release on Demand is the process that release deployed features gradually or immediately to customers and evaluates the hypothesis from the continuous exploration stage.


There are three major questions to consider in respect to Release on Demand:

  1. When - should we release?
  2. What - elements of the system should be released?
  3. Which - end-users should receive the release?


Release on Demands requires an organisation to develop the following capabilities:

  • Decouple the release from the development cadence
  • Decoupling the release elements from the solution
  • Architechting the solution to support incremental releases



Decouple the Release from the Development cadence


Develop on cadence is the other half of the strategy that allows ARTs and the Solution Trains to operate in a particular pattern and synchronise the efforts of multiple development teams. But when it comes to releasing value, a different set of rules may apply.


Once we have a reliable stream of value through the Continuous Deployment process, the next consideration is when and how to release. The release strategy is decoupled from the development cadence, as shown:



Several release strategies may apply depending on the context and situation:


  • Releasing on the PI cadence
    • Simplest case, since PI Planning, Releasing and I&A have predictable dates
    • IP - Innovation & Planning iterations can be timed, designed and organised to support more extensive release activities
    • IP iterations could include final V&V (Verification & Validation), UAT, and training and release documentation
  • Releasing less frequently
    • May not be feasible / desirable
    • Might constitute critical infrastructure
    • SLA and licence agreements may be prohibitive
    • Potential overhead / disruption of deployment
  • Releasing more frequently
    • For many the goal is to release more frequently
    • Requires DevOps capabilities, efficient delivery pipeline and architecture that supports incremental delivery
  • Release on Demand
    • Above cases are probably over-simplistic
    • Big systems often contain different types of components and sub-systems
    • The most general model is: Release whatever you want and whenever it makes sense, within the governance and business model



Decouple Release elements from the solution


Most solutions, even simple ones, will have multiple release elements, each operating with different release strategies:




For example, this website has multiple release cycles:


  • Ad hoc - Expedited
    • Patch / Security release to a deployed version
  • High Frequency
    • Article updates, readers notified via blog post / mail out
  • Medium Frequency
    • Add new articles whenever significant new content is created
  • Low Frequency
    • Significant changes to the back-end infrastructure / architecture

These separate flows are known as streamlets since they represent full end-to-end flow of value within a value stream. Each streamlet should be managed to deliver value according to its own needs and pace.


Identifying streamlets is critical to Release on Demand, as they allow the different elements of the solution to be release independently in a separate cadence.



Architect the Solution for Incremental Releases


Achieving different release strategies requires solutions to be architected for component (/service based) deployability, releasability and fast recovery.


  • Feature toggles
    • Toggles or switches enable deployment of features into production without making them visible to the end user
    • Help avoid the need for multiple code branches
    • Allow developers to deploy new features to production, but only activate them when the enterprise is ready to consume them
    • After the feature has been release and deemed stable, the toggles are removed to avoid technical debt
  • Canary releases
    • Technique used to reduce the risk of introducing a release into production by slowly rolling out a change to a small subset of users, before rolling it out to the whole user base
    • Allows selective production testing and feature validation without impacting everyone
  • Dark launches
    • Sometimes it's necessary to test new functionality in production before making it available to customers
    • Especially when there is a high uncertainty on how well the system will meet its NFR (Non-Functional Requirements) under a production load

Implementing these strategies might require upgrading infrastructure and architecture, including moving to standard technology stacks, decoupling monolithic applications with micro-services, data preparation and normalisation, third party APIs and data exchange, and logging and reporting tools.



Close the loop on the Feature Hypothesis


After the feature is released, the Benefit Hypothesis needs to be evaluated:

  • Were the intended outcomes achieved?
  • Should a canary release be extended to more customers?
  • Turn off the feature toggles?


The feature is considered Done, once we have an understanding of the production results. However, it might be necessary to extend the functionality (persevere) or pivot (remove the feature) to find a different solution.



Building the Release



Team Increment

  • Each Agile team ensures it produces a working increment for the stories, features and components they are responsible for, by:
    • Completing user stories from their Team Backlog, ensuring each meets its local (story) and DoD (Definition of Done)


System Increment

  • Every two weeks, teams build a system increment, integrated stack of new functionality, representing all the backlog items completed by the ART
  • During the system demo, stakeholders review the system increments and provide feedback


Solution Increment

  • ARTs typically only contribute to part of large solutions
  • Integrated, verified and validated solution increments must satisfy both functional and non-functional requirements
  • Subject of the Solution Demo, which brings all the system increments together into a working system


Release Increment

  • Additional activities might be required when releasing, such as:
    • Final release
    • Validation & Verification
    • Release Notes
    • UAT
    • Documentation
    • Training material
    • Marketing activities
  • These activities, as much as possible, are part of the DoD of the previous increments. However, some will remain as release activities


A Scaled Definition of Done

Relentlessly improve results

IP - Innovation & Planning Iteration


  • Facilitates reliability, Program Increment readiness, planning and innovation
  • Innovation: opportunity for innovation, hackathons and infrastructure improvements
  • Planning: Provides for cadence based planning
  • Estimating guard band (contingency) for cadence based delivery
  • Ensure to provide sufficient capacity margin  (contingency) to enable cadence!



IP Iteration calendar

This sample IP Iteration calendar provides a standard schedule and format. Blue items are for a single ART, whilst orange are for Solution Train events:





I&A - Inspect & Adapt


Consists of three parts:

  • The PI System demo
  • Quantitative measurement
  • The problem-solving workshop
  • Attendees: Teams and stakeholders
  • Timebox: 3 - 4 hours per PI



PI System demo


At the end of the PI, teams demonstrate the current state of the solution to the appropriate stakeholders.


  • Often led by product Management, POs and the System Team
  • Attended by Business Owners, program stakeholders, product Management, RTE, SMs and teams



Program performance reporting


As part of the Solution demo, teams compare planned vs actual PI Objectives.


  • Teams meet with their Business Owners to self-assess the business value they achieved for each objective
  • Each team's planned vs actual business value is the rolled up to the Program Level in the Program Predictability Measure



PI Predictability Measure


The PI Predictability Measure shows whether achievements fall into an acceptable process control band.


Threshold is between 80 - 100% e*




The problem-solving workshop


Team conducts a short retrospective, then systematically addresses the larger impediments that are limiting velocity.


Portfolio SAFe


Portfolio SAFe helps align portfolio execution to the enterprise strategy by organising Agile development around the flow of value, through one or more streams.


Aligns strategy / execution with LPM - Lean Portfolio Management


  1. Fund value streams, not projects
  2. Empower local decision making
  3. Provide objective evidence of fitness for purpose
  4. Manage Epic-level initiatives responsibly
  5. Forecast predictability
  6. Budget value streams dynamically


1. Fund value streams




Problem: "Projects" increase the Cost of Delay


When overruns happen, project accounting and re-budgeting increases the Cost of Delay and impacts culture



  • Wait for new budget approval; increase Cost of Delay
  • Costly variance analysis; blame game; threatens transparency
  • Resources scramble and re-assignments


Solution: Lean-Agile budgeting


Fund value streams, not projects!


Funding value streams provides for full control of spend, with:

  • No costly and delay-inducing project cost variance analysis
  • No resource re-assignments
  • No blame game for project overruns



Control Costs with increased flexibility


ART budgets and resources are unaffected by feature cost overruns or changing priorities




Strategic Themes influence funding


Business objectives that connect a SAFe portfolio to the enterprise strategy



Examples (for a retail eCommerce company):

  • Appeal to a younger demographic (18 - 30)
  • Reduce warehousing cost by 50%



2. Empower local decision making


Empower ART content authority

  • PM - Product Management has the content authority, over features


  • PO - Product Owners have the authority , over stories


  • PMs and POs represent the customer, understanding their needs and creating features and stories which drive better products


Strategic themes influence what gets built


Strategic themes influence ART funding, Portfolio Backlog, Program Vision and Roadmap.

  • Adjust ART and Value Stream funding to track to changing strategic priorities


  • Assist with Epic evaluation and decision making


  • Influence each Program Vision and Roadmap



3. Provide objective evidence of fitness for purpose


  • The system demos are an objective measurement of progress and usage of funds


  • LPM, senior managers and high level stakeholders, review the progress of the solution under development and its fitness for purpose


  • Action and investment decisions are based on this objective evidence



4. Manage Epic-level initiatives responsibly


Large initiatives require Lean Portfolio Management approval


Epics are enterprise initiatives sufficiently substantial in scope so as to warrant analysis, understanding ROI, a lightweight business case and approval.


  • Portfolio Epics cut across value streams
  • Program Epics can be implemented in a single train
  • Business Epics are customer facing
  • Enabler Epics enable solutions to address business needs
  • Developed and analysed in the kanban systems



Foster innovation with a Lean Startup cycle




Epic Hypothesis Statement template


PO / Product Management creates:





Approve Epic level initiatives

Investments in Epics is a serious matter. Analyses and informed decision making is crucial


  • Just the right amount analysis
  • Avoid over specificity
  • Understand ROI
  • Understand implementation impact
  • Develop incremental implementation strategy
  • Gain approval from LPM


Govern Epic flow with the Portfolio Kanban system


The Portfolio Kanban system manages the flow of epics


  • Makes largest business initiatives visible
  • Brings structure to analysis and decision making
  • Provides WIP limits to ensure the teams analyse responsibly
  • Helps prevent unrealistic expectations
  • Helps drive collaboration amongst the key stakeholders
  • Provides a transparent and quantitative basis for decision making



Prototypical Portfolio Kanban system




5. Forecast predictability


The business needs to forecast


  • SAFe enhances enterprise adaptability, providing faster response to changing market opportunities
  • Yet, the enterprise, its partners and customers need to plan some sense of the future
  • Estimating must:
    • Be as fast and efficient as possible to be reasonably accurate
    • Support "what if" analysis of various implementation scenarios
  • Traditional Work Breakdown Structure to task level estimating binds the teams to waterfall practices



Estimating Epics in SAFe

  1. Epics are broken down into potential features during the Portfolio Kanban analysis stage


  1. Potential features are estimated in story points
  • Typically performed at the PM-System Architecture level, based on history and relative size
  • Individual teams are engaged as necessary
  1. Feature estimates are aggregated back into the Epic estimate as part of the lightweight business case



Forecasting from the Portfolio Backlog


Given the knowledge of Epic sizes and ART velocities, applying "what if" capacity allocations informs decisions and forecasting.



Allows forecasting of which trains can work on these trains and % of their capacity can be applied?




6. Budget value streams dynamically


Exercise fiscal governance with dynamic budgeting


Financial governance is still in place. Adjust budgets dynamically to meet changing business needs.


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

Leading the Lean-Agile Enterprise



"People are already doing their best; the problem is with the system.

Only management can change the system"

  • Exhibit a Lean-Agile Mindset
  • Lead the change
  • Know the way; emphasise life long learning
  • Unlock the intrinsic motivation of knowledge workers
  • Decentralise decision making


Lead the change


"It's not enough that management commit themselves to quality and productivity, they must know what it is they must do.

Such a responsibility cannot be delegated."

W. Edwards Demming


Leading successful change management

  • Establish a sense of urgency
  • Create a powerful guiding coalition
  • Develop the vision and strategy
  • Communicate the vision
  • Empower employees for broad based action
  • Generate short term wins
  • Consolidate gains and produce more wins
  • Anchor new approaches in culture
    • Culture is realised in the habits of the organisation
    • New culture requires new habits
    • Celebrate ART wins
    • ART winning can become a habit
    • Consolidate gains; produce more wins; start another value stream
      • Repeat


Know the way and emphasise life long learning


Built-in instability

  • Management provides general goal and strategic direction -  a strong vision
  • Little / minimal / no specific work or project plans
  • Challenging requirements
  • High degree of freedom as to how teams meet requirements


The power of "ba" - "We, the work and the knowledge, are all one"

  • Dynamic interaction of individuals and organisation in the form of self organising team, the fuel of "ba" is its self organising nature
  • Team members create new points of view and resolve contradictions through dialogue
  • "Ba" is energised with intentions, vision, interest and mission
  • Leaders provide autonomy, variety, trust and commitment
  • Creative chaos via demanding performance goals
  • The team is challenged to question every form of development
  • Equal access to information at all levels is critical



Unlock the intrinsic motivation of knowledge workers


"Workers are only knowledge workers if they know more about the work they perform that their boss"

Peter Drucker


  • Workers themselves are best placed to make the decisions about how to perform their work
  • To effectively lead, the workers must be heard and respected
  • Knowledge workers have to manage themselves. They have autonomy.
  • Continuing innovation has to be part of their work, the task, and take responsibility of knowledge workers



Leadership styles


The effectiveness of your workers is determined in a large part by your personal leadership style

  • Leader as expert
  • Leader as conductor
  • Leader as developer


Leader as expert


Can be effective when manager has greater knowledge than direct reports

  • Characteristics
    • Technician or master craftsman
    • Promoted because they were the best at their job
    • Problem solver, the one people go to for answers
    • Understands the domain and the technology
    • Work is, when people leave them alone
  • Challenges
    • Limits learning and growth of direct reports
    • Focus on technical problems to the detriment of human factors


Leader as conductor


Can be effective when coordination is pre-requisite for maximum performance

  • Characteristics
    • The central decision maker, nerve centre, coordinator
    • Orchestrates all individual parts of the organisation into a harmonious whole
    • Subtle and indirect manipulation to their solution
    • Manages across individuals, teams and departments
    • Work is, coordinating others
  • Challenges
    • Narrows the focus of direct reports to their own areas
    • Conflicts tend to push upwards looking for the boss to fix
    • Use systems and procedures to control work
    • Works harder and harder, without realising full potential


Good leader myth responsibility trap


  • Negative reinforcing cycle
  • Fails to make full use of the knowledge and competencies of direct reports
  • Produces narrow and self interested direct reports


Leader as developer of people


Escape the trap with a post-heroic, lean leadership style

  • Behaviours
    • Creates a team jointly responsible for success
    • Asks, "how can each problem be solved in a way that further develops my people's commitment and capabilities?"
    • Work is, developing other's abilities
  • Benefits
    • Increased direct report ownership and responsibility
    • Increased employee engagement and motivation
    • Allows leader to spend more time managing lateral and upward
    • There is no limit to the power of getting things done


Create an environment of mutual influence


Create a safe environment for learning, growth and mutual influence.


Encourage direct reports to:

  • Disagree, where appropriate
  • Advocate for the positions they believe in
  • Push for their own needs
  • Enter into joint problem solving
  • Negotiate, compromise, agree, commit


What motivates us


3 factors lead to better performance and personal satisfaction: e*

  • Autonomy
  • Mastery
  • Purpose

Implementation Roadmap

To achieve the desired organisational change, leadership must 'Script the critical moves'. When it comes to identifying those critical moves, a successful adoption pattern has emerged, as follows:



  • The Tipping Point comes from:
    • Pro-Active Leadership e*
    • Burning Platform - Fire fighting - something that's hurting us, now


  • Create a LACE (Agile PMO):
    • Lean
    • Agile
    • Centre of
    • Excellence


  • Identify Value Streams and ARTs, to achieve KPIs.
  • Essential that Executives, Managers, Leaders are trained!
  • Focus on the Business Benefits of SAFe:
    • Improving business outcomes for companies of all sizes across the world. SAFe has produced dramatic increases in time to market, employee engagement, higher quality, higher customer satisfaction, and overall improved economic outcomes. It also helps create cultures that are more productive, rewarding, and fun.

e* 30 -75% faster time to market



Abbreviations & Acronyms

ART Agile Release Train
BO Business Owner
BV Business Value
BVIR Big Visual Information Radiator
CapEx Capital Expenses
CD Continuous Delivery
CE Continuous Exploration
CFD Cumulative Flow Diagram
CI Continuous Integration
CoD Cost of Delay
CoP Community of Practice
DoD Definition of Done
DSU Daily Stand-up
EA Enterprise Architect
EO Epic Owner
FW Firmware
HW Hardware
I&A Inspect and Adapt
IP Innovation and Planning (iteration)
LPM Lean Portfolio Management
MBSE Model-Based Systems Engineering
MMF Minimum Marketable Feature
MVP Minimum Viable Product
NFR Non-functional Requirements
OE Opportunity Enablement
OpEx Operating Expenses
PDCA Plan, Do, Check, Adjust
PI Program Increment
PM Product Manager
PO Product Owner
PO/PM Product Owner/Product Manager
ROAM Resolved, Owned, Accepted, Mitigated
RR Risk Reduction
RTE Release Train Engineer
S4T SAFe® for Teams
SA SAFe® Agilest
SAFe® Scaled Agile Framework
SBD Set-Based Design
SM Scrum Master
SoS Scrum of Scrums
SP SAFe® Practitioner
SPC SAFe® Program Consultant
STE Solution Train Engineer
SW Software
UX User Experience
VS Value Stream
VSE Value Stream Engineer
WIP Work in Process
WSJF Weighted Shortest Job First
XP Extreme Programming