Agile Frameworks - SAFe
About The Author & The Article
Jonathan Bishop, Group Chairman, Bishop Phillips Consulting. [1]
Copyright 2020-2026 - Moral Rights Retained.
This article may be copied and reprinted in whole or in part, provided that the original author and Bishop Phillips Consulting is credited and this copyright notice is included and visible, and that a reference to this web site (http://RiskWiki.bishopphillips.com/) is included.
This article is provided to the community as a service by Bishop Phillips Consulting www.bishopphillips.com.
Introduction
SAFe (Scaled Agile Framework) is a way to align strategy, funding, architecture, and multiple Agile teams using a predictable cadence and multi‑team coordination mechanisms so the entire enterprise delivers value continuously and coherently.
It’s Agile for organisations with:
- multiple teams
- shared platforms
- shared architecture
- regulatory constraints
- long‑term funding
- enterprise‑level governance
Scrum is for teams, while SAFe is for systems.
Why SAFe Exists
SAFe solves problems that Scrum alone cannot:
- Multiple teams working on one product
- Shared architecture
- Shared platforms
- Regulatory compliance
- Long‑term funding
- Enterprise governance
- Cross‑team dependencies
- Coordinated releases
Scrum is too small for enterprise wide application so SAFe provides a scaffolding around Scrum but in the process it looses some of its agility. SAFe’s Secret: It’s Not Really About Agile. SAFe is actually about:
- alignment
- flow
- governance
- architecture
- funding
- strategy execution
Agile is the delivery mechanism while SAFe is the operating model at enterprise scale.
The Four Levels of SAFe (the real structure)
SAFe has four layers which are effectively 'zoom levels' in a value‑delivery system.
1. Team Level (Scrum/Kanban Teams)
This is the level we know from Scrum. Refer to our articles on Srum to learn the deatils of this level. Start here: Agile Frameworks - Scrum
Each team uses:
- Scrum or Kanban
- PBIs
- Sprint Goals
- Definition of Done (DoD)
- Retrospectives
Nothing changes from Scrum at this level. SAFe doesn’t replace Scrum: it connects Scrum teams.
2. Program Level (Agile Release Train — ART)
This level is the 'heart' of SAFe.
An **ART** is:
- 5–12 Agile teams
- working on one product or value stream
- synchronised on the same cadence
- delivering together every 8–12 weeks
An ART as a Scrum of Scrums with structure.
Key concepts:
- PI (Program Increment) = 5 Sprints
- PI Planning = all teams plan together
- System Demo = integrated demo across teams
- RTE (Release Train Engineer) = the Scrum Master for the whole train
- Product Management = the Scrum Product Owner at scale
- System Architect = architecture at scale
This solves the “multiple teams, one product” problem.
3. Large Solution Level (for big systems)
Used when multiple ARTs must coordinate to build a single large system.
Examples:
- Defence systems
- Banking platforms
- National infrastructure
- Enterprise‑wide platforms
Roles:
- Solution Train Engineer
- Solution Architect
- Solution Management
If you don’t have massive systems, you can ignore this layer.
4. Portfolio Level (Strategy + Funding)
This is where SAFe becomes Enterprise Agile.
Portfolio level handles:
- Lean budgeting
- Value streams
- Epic approval
- Investment horizons
- Enterprise architecture
- Governance
Key artifacts:
- Portfolio Kanban
- Strategic Themes
- Epic Owners
- Guardrails
This is where SAFe connects strategy to execution.
The Core SAFe Idea: Value Streams
Definition
A value stream is one of the most important concepts in SAFe. SAFe organises the enterprise around value streams, not departments or functions.
A value stream is: The sequence of activities that delivers value to a customer from trigger to delivery.
It is not a department, not a project, and not a team: It is the flow of value across the organisation.
Each value stream has:
- a customer(s)
- a trigger (what starts the flow)
- a series of activities
- a product or service delivered at the end
- funding
- teams / people
- architecture
- governance
- metrics
This is the opposite of traditional org charts. SAFe uses value streams because they reflect how the business actually works from the clients or customer's perspective, not how the org chart is drawn.
Two Types of Value Streams in SAFe
SAFe distinguishes between:
1. Operational Value Streams (OVS)
The OVS describe how the business makes money.
Examples:
- How a bank processes a loan
- How a retailer fulfils an order
- How a hospital treats a patient
- How a government agency processes a permit
- How a government agency proposes and applies for budget
These are the business operations.
2. Development Value Streams (DVS)
The DVS describe how the organisation builds the systems that support the operational value streams.
Examples:
- The teams building the loan processing system
- The teams building the e‑commerce platform
- The teams building the hospital EMR system
- The teams building the permit management system
These are the product development flows.
Why Value Streams Matter
SAFe’s Agile Release Trains (ARTs) are built around development value streams.
Because they determine:
- How you form Agile Release Trains
- How you fund work
- How you align teams
- How you prioritise
- How you measure flow
- How you scale Agile
If you get value streams wrong, the entire SAFe implementation collapses.
Examples of Value Streams
| No. | Industry | Operational Value Stream | Development Value Stream |
|---|---|---|---|
| 1 | Banking |
“Process a home loan application.”
|
“Build and maintain the loan origination system.” Teams:
|
| 2 | Retail / E‑Commerce |
“Customer buys a product online.” Steps:
|
“Develop and operate the e‑commerce platform.”
Teams:
|
| 3 | Healthcare |
“Treat a patient in emergency.” Steps:
|
“Build and maintain the hospital EMR system.” Teams:
|
| 4 | Government | “Issue a driver’s licence.”
Steps:
|
“Develop and maintain the licensing system.”
Teams:
|
| 5 | Defence / Aerospace | “Deploy and operate an aircraft.”
Apply SAFe’s Large Solution level. |
“Build the avionics and mission control systems.”
Apply SAFe’s Large Solution level. |
How to Identify a Value Stream (The Practical Test)
In identifying and defining a value stream we should ask:
- Who is the customer?
- What triggers the flow?
- What is the value expected and delivered?
- What steps are required to deliver it?
- Which teams contribute to those steps?
- Can the stream be funded independently?
If we have definitive answers to the first five and the answer to number six is "yes", we’ve found a value stream.
The SAFe Cadence
SAFe runs on a predictable rhythm:
- Daily: Team standups
- Every 2 weeks: Sprints
- Every 10 weeks: PI (Program Increment)
- Every PI:
- PI Planning
- System Demo
- Inspect & Adapt
This creates alignment across the entire enterprise.
The SAFe Roles
SAFe has three major layers of roles:
- Team Level — where work is done
- Program Level (ART) — where multiple teams align
- Portfolio Level — where strategy and funding live
There is also a Large Solution Level for massive systems.
These three levels have the following roles:
1. Team Level
This is the Scrum level which are explained in detail in Agile Frameworks - Scrum:
- Product Owner
- Scrum Master
- Developers
2. Program Level
This is where SAFe becomes SAFe. The ART is 5–12 teams working together on one product/value stream:
- Product Manager
- Release Train Engineer (RTE)
- System Architect
Plus two external roles:
- Business Owners
- System Team
| Role | Description |
|---|---|
| Product Manager | Owns the Program Backlog.
Focus: What should the ART build next?
PO = team-level value. PM = program-level value. |
| Release Train Engineer (RTE) | The Scrum Master for the entire ART.
Focus: How do all teams work together?
This is one of the most critical roles in SAFe. |
| System Architect / Solution Architect | Owns the architecture runway.
Focus: What technical direction ensures long-term viability?
|
| Business Owners | The key stakeholders for the ART.
Focus: Is the ART delivering business value?
|
| System Team | A specialised team that supports integration and testing.
Focus: Enable continuous integration and system demos. |
3. Portfolio Level
This is where SAFe becomes Enterprise Agile:
- Epic Owners
- Enterprise Architect
- Lean Portfolio Manager
| Role | Description |
|---|---|
| Epic Owners | Own portfolio epics (big initiatives).
Focus: Drive large-scale change.
Coordinate across ARTs |
| Enterprise Architect | Owns enterprise-wide architecture.
Focus: Ensure technical coherence across value streams.
|
| Lean Portfolio Manager | A group, not a person.
Focus: Where should we invest?
|
4. Large Solution Level (Optional)
This is where SAFe becomes Enterprise Agile:
- Solution Train Engineer (STE) - RTE for multiple ARTs.
- Solution Architect - Architect for the entire solution.
- Solution Management - Product Management at the solution level.
If you’re not building aircraft, banking platforms, or defence systems, you can ignore this layer.
These roles ensure alignment from strategy → execution.
The Real Relationships
PO vs PM
- PO = team backlog
- PM = program backlog
- PM tells PO what matters
- PO tells team what to build next
Scrum Master vs RTE
- Scrum Master = team flow
- RTE = ART flow
- RTE coaches Scrum Masters
- Scrum Masters coach teams
Architects
- System Architect = ART architecture
- Enterprise Architect = portfolio architecture
- Solution Architect = multi-ART architecture
Business Owners
- They are the customers of the ART
- They approve PI Objectives
- They ensure the ART is delivering value
SAFe Program Increment Planning
What SAFe PI Planning Actually Is
Programs define, build and/or implement "program increments" which are tangible value deliverables. PI Planning (Program Increment Planning) is a two‑day, all‑hands planning event where every team in an Agile Release Train (ART) aligns on a shared mission, identifies dependencies, resolves risks, and commits to a set of objectives for the next Program Increment. It is a big-room planning event where all teams in an ART, usually 50–125 people, come together for two days to:
- align on a shared mission
- agree on a set of objectives
- identify dependencies
- surface risks
- commit to a plan for the next 8–12 weeks
It is the heartbeat of SAFe. If the ART is the engine, PI Planning is the ignition cycle.
Why PI Planning Exists
Scrum works beautifully for a single team. But when you have 10 teams working on one product, you get:
- conflicting priorities
- hidden dependencies
- integration failures
- architectural drift
- duplicated work
- misaligned goals
PI Planning solves this by creating:
- shared context
- shared priorities
- shared cadence
- shared commitment
It is the moment the entire ART synchronises.
The Structure of PI Planning (2 Days)
DAY 1 - Alignment + Draft Planning
1. Business Context (Leadership)
Executives explain:
- market conditions
- customer needs
- strategic priorities
- upcoming deadlines
- financial constraints
This sets the "why."
2. Product Vision & Roadmap (Product Management)
Product Managers present:
- vision
- top features
- priorities
- architectural runway
This sets the "what."
3. Architecture Vision (System Architect)
Architects explain:
- technical direction
- constraints
- enablers
- risks
- integration concerns
This sets the "how."
4. Team Breakouts - Draft Plans
Teams break out and:
- pull features from the Program Backlog
- break them into stories
- estimate
- identify dependencies
- raise risks
- draft PI Objectives
This describes the "what".
5. Draft Plan Review
Teams present their draft plans to:
- Product Management
- RTE
- Business Owners
- Other teams
Feedback is given, dependencies are negotiated and scope is adjusted.
DAY 2 — Finalisation + Commitment
6. Planning Adjustments
Teams refine their plans based on feedback.
7. Management Review & Problem Solving
Leadership meets privately to:
- resolve resource conflicts
- adjust scope
- address cross-team issues
- make trade-offs
This is where the “big rocks” get moved.
8. Final Team Breakouts
Teams update:
- stories
- dependencies
- risks
- PI Objectives
9. Final Plan Review
Each team presents:
- their plan
- their risks
- their dependencies
- their PI Objectives
Business Owners score each team’s objectives (1–10) based on business value.
10. ROAMing Risks
All risks are categorised as:
- Resolved
- Owned
- Accepted
- Mitigated
This creates transparency.
11. Confidence Vote
Everyone votes (1–5 fingers) on confidence in the plan.
If confidence is low: rework.
12. PI Planning Ends → PI Execution Begins
Teams start Iteration 1 the following Monday.
The Outputs of PI Planning
By the end, the ART has:
1. Committed PI Objectives
Each team has 5–10 objectives:
- some committed
- some stretch
2. Program Board
A visual map showing:
- features
- teams
- dependencies
- milestones
This is the ART’s “single source of truth.”
3. Identified Risks
All major risks are ROAMed.
4. Shared Understanding
Everyone knows:
- what we’re building
- why we’re building it
- how we’ll work together
This is the real value.
The Intent of the PI Planning Approach
It creates alignment at scale.
- Teams align with each other
- Teams align with Product Management
- Product aligns with Architecture
- Architecture aligns with Strategy
- Everyone aligns with the Business Owners
This is impossible to achieve through documents or asynchronous communication.
PI Planning is the social synchronisation mechanism of SAFe.
Common Misconceptions
"PI Planning is waterfall."
No — it’s *collaborative planning*, not *predictive planning*.
"PI Planning locks scope."
No - scope is flexible. Objectives are the commitment, not the stories.
"PI Planning is too big."
It’s cheaper than:
- misalignment
- rework
- integration failures
- architectural drift
How to implement SAFe in a real organisation
Introduction
The Core Principle is that we don’t "install SAFe.", rather we build the conditions under which SAFe can work.
That means:
- value streams before teams
- leadership before process
- architecture before ceremonies
- flow before governance
If we skip these, SAFe collapses into theatre.
Implementing SAFe is not about installing roles and ceremonies. It is about organising around value, aligning leadership, stabilising teams, synchronising planning, building architectural runway, and creating a continuous flow of value across the enterprise.
A Question of Organisation Structure
The Value Centric Organisation
Many organisations adopting SAFe restructure around 'value streams'. While one would certainly not do that in the first interest, it is an issue that will come up at some point.
The question that could be asked is whether implementing SAFe, or indeed any other enterprise Agile model necessitates the enterprise to re-organise structurally around 'value streams'. Personally, I am not convinced such a radical rethink is always necessary or practical. The point of Agile is to 'be Agile' and be able to shift focus quickly. It is not practical to restructure with every shift in the value stream, so I would argue that an enterprise Agile model has to enable Agility without requiring the house to be rebuilt for every new guest.
Organisation structure follows other dictates from legal compliance, through geographic realities and skill concentration to functional necessities. In the days of the matrix structure experiments, enterprises were literally restructured to follow the management model, and there can be many good reasons for implementing a different physical structure, but SAFe is designed to float across and within the organisation in an intentionally multi-disciplinary environment so while some rethinking of structure and reporting arrangements might be justified a total reorganisation does not automatically seem warranted. Having said that, there is clearly a set of specific roles and skills associated with the Agile operational model that need to have a home in the organisation so this is a topic the warrants further consideration.
Matrix organisations were incredibly good at innovation but past a certain size they were often disastrous at operations. I know because I reviewed and consulted to a number of them! Organisation structure can have extensive impacts on the compliance obligations and performance of an entity, and rearranging around a single management paradigm can introduce far reaching and unintended consequences. Caution is warranted.
So the short answer is that SAFe does not require an enterprise to restructure but in practice the story might be different. Most organisations do restructure (at least to some extent) when they adopt SAFe, because SAFe exposes structural misalignments that make flow impossible. SAFe does not require it, but it may prove essential regardless. The issue is that with legal constraints, mandated operational separations (like consulting versus external audit, or fund management versus broking), geopolitical requirements; the fact is that not every organisation can simply reorganise around value streams.
SAFe strongly assumes that teams are aligned to value streams, not departments. This is the tension. SAFe’s ideal world is:
- stable, cross‑functional teams
- long‑lived Agile Release Trains (ARTs)
- value streams that cut across silos
- minimal handoffs
- minimal dependencies
But many real organisations have:
- siloed departments
- functional reporting lines
- geographic constraints
- legal separations
- compliance‑mandated walls
- legacy systems
- political realities
SAFe doesn’t require restructuring, but it often forces the conversation and this is where SAFe becomes more art than framework.
What Restructuring Does SAFe Recommend?
SAFe recommends restructuring around value streams, not functions.
In the traditional structure of a SAAS firm, for example, we might have something like:
- Frontend team
- Backend team
- Database team
- QA team
- Security team
- Infrastructure team
- Finance
- Legal
- Human Resource
- Sales & Marketing
In the ideal SAFe structure this would become:
- Value Stream 1 → ART 1
- Value Stream 2 → ART 2
- Value Stream 3 → ART 3
Each ART contains:
- frontend
- backend
- QA
- UX
- security
- ops
- architecture
This is a cross‑functional, long‑lived product team and this is the restructuring SAFe prefers.
Functions like Intern Audit, Finance, Legal, Human Resources and Sales & Marketing must be handled differently. SAFe does not restructure these functions into Agile teams. They remain functional departments, but their operating model changes. It transforms them into Lean‑Agile enablers of value streams.
Structure Agile Enabler Functions in SAFe
Finance, HR, and Sales/Marketing do not join Agile Release Trains. They remain functional departments, but they adopt Lean‑Agile ways of working and align their processes, policies, and funding models to support value streams. Legal and regulatory constraints are respected, and SAFe provides mechanisms (shared services, guardrails, LPM) to integrate these functions without violating obligations.
1. Finance in a SAFe Enterprise
Finance is the single most important non‑IT function to transform.
Traditional finance:
- annual budgeting
- project‑based funding
- cost centres
- rigid approvals
- waterfall governance
This is fundamentally incompatible with Agile. SAFe Finance becomes Lean Portfolio Management (LPM). It shifts to:
- value‑stream funding (not project funding)
- rolling budgets
- guardrails instead of approvals
- epic‑level investment decisions
- continuous forecasting
- participation in PI Planning
Finance does NOT join ARTs but Finance:
- funds value streams
- attends PI Planning
- evaluates epics
- sets economic prioritisation rules
- ensures compliance
Conflict with legal constraints is avoided because Finance remains a regulated function — it simply changes how it funds work.
2. HR in a SAFe Enterprise
HR is the second most important function to transform. Traditional HR:
- job descriptions tied to roles, not skills
- annual performance reviews
- individual KPIs
- siloed hiring
- rigid career paths
These characteristics destroy Agile flow. SAFe HR becomes People Operations (Lean‑Agile HR) and shifts to:
- team‑based performance
- continuous feedback
- skills‑based hiring
- cross‑functional career paths
- stable teams
- Agile‑aligned reward systems
HR also does NOT join ARTs but shifts to:
- supports team stability
- designs Agile‑friendly policies
- helps form value‑stream‑aligned teams
- participates in organisational design
- ensures compliance with labour law
Conflict with legal constraints is avoided with HR still enforcing employment law but it just stops enforcing anti‑Agile policies.
3. Sales & Marketing in a SAFe Enterprise
This is where SAFe becomes truly enterprise‑wide. Traditional Sales/Marketing:
- annual campaigns
- quarterly targets
- siloed messaging
- long approval cycles
- disconnected from product teams
This creates massive misalignment. SAFe Sales/Marketing becomes Agile Marketing & Lean Sales by shifting to:
- continuous campaigns
- rapid experimentation
- customer‑centric messaging
- alignment with product increments
- participation in PI Planning
- shared OKRs with product teams
Sales/Marketing do NOT join ARTs but they:
- attend PI Planning perhaps as the customer representative
- align campaigns with PI Objectives
- provide customer insights
- synchronise launches with ART cadence
Sales/Marketing still comply with advertising, privacy, and consumer law so conflict with legal obligations is avoided.
4. So What Actually Changes Structurally for the Admin Units?
The practical reality is these units often have external legal and social obligations or require scale for efficiency so Finance, HR, Sales, Marketing remain functionally distinct departments. They are not dissolved but they change how they operate:
- They adopt Lean‑Agile principles
- They align to value streams
- They participate in PI Planning
- They support continuous flow
- They remove bureaucratic blockers
- They redesign policies to support agility
And they change how they interact with delivery teams:
- No more project‑based funding
- No more annual performance reviews
- No more siloed hiring
- No more disconnected campaigns
- They become enablers, not bottlenecks.
5. What about legal, political, or social constraints?
External conditions may impose :
- legislated Chinese walls
- sovereign requirements
- local content rules
- union constraints, salary / employment awards & industrial relations laws
- privacy laws
- regulated financial controls
The rule is that the SAFe Enterprise must adapt its SAFe implementation to the prevailing legal constraints and not override them. For example:
- HR still enforces separation of duties
- Finance still enforces audit controls
- Sales still complies with advertising law
- Marketing still respects privacy regulations
- Government departments still maintain mandated functional separations
- SAFe simply changes how they collaborate with value streams.
Living In The Matrix
I referenced the matrix organisation experiment of the early 1990's earlier in this section for a reason because in the real world, SAFe is not a "pure value stream only" structure. Real enterprises always end up with a hybrid matrix.
A matrix structure is not only common in SAFe, itis necessary. ARTs deliver value vertically, while shared services, CoEs, and CoPs provide horizontal consistency, policy, specialised skills, skill development and cross team learning. This hybrid model allows enterprises to maintain legal compliance, shared standards, and scalable IT services while still organising around value streams.
1. Why a pure value‑stream structure rarely works
In theory, SAFe wants:
- long‑lived, cross‑functional ARTs
- all skills embedded in the ART
- minimal dependencies
- minimal shared services
In practice, enterprises have:
- centralised IT services
- enterprise architecture
- cybersecurity
- data governance
- HR policies
- finance controls
- legal/compliance
- procurement
- shared platforms
- shared infrastructure
- shared UX standards
- shared security standards
You cannot decentralise these without:
- violating law
- duplicating effort
- losing consistency
- increasing risk
- exploding cost
So a matrix structure emerges naturally.
2. The SAFe‑compatible matrix structure
SAFe actually expects a matrix, even though it doesn’t advertise it loudly. There are three layers of skill ownership:
A. Skills embedded in ARTs (local execution)
These are skills needed "daily" to deliver value:
- developers
- testers
- UX
- product owners
- scrum masters
- business analysts
- DevOps engineers
These belong inside the ART.
B. Skills provided by Shared Services (specialist support)
These are skills needed occasionally or cannot be decentralised:
- cybersecurity
- enterprise architecture
- data governance
- legal/compliance
- procurement
- HR policy
- finance controls
- cloud platform engineering
- infrastructure
- accessibility experts
- performance testing
- specialised QA
These remain centralised, but support ARTs on demand.
SAFe explicitly defines this as **Shared Services**.
C. Skills coordinated at the enterprise level (policy + standards)
These are skills that must be consistent across the organisation:
- coding standards
- security standards
- architecture principles
- UX design system
- data models
- cloud governance
- risk management
- audit controls
- HR frameworks
- finance guardrails
These are owned by Centers of Excellence (CoEs) or Communities of Practice (CoPs).
This is the *horizontal* dimension of the matrix.
3. The matrix is optimal design choice
A matrix structure solves the issues of intra-functional skill development, standardisation and learning at scale:
1. Shared policies must apply across all ARTs
Security, architecture, HR, finance — these cannot be localised.
2. Skills must be developed consistently across the enterprise
You need:
- common training
- common standards
- common career paths
- common certification
- common tooling
3. IT services must operate at scale
Cloud, networking, identity, data platforms — these are enterprise assets.
4. Some functions cannot legally be embedded in ARTs
Especially in:
- government
- finance
- defence
- healthcare
- regulated industries
5. Some skills are too scarce to embed everywhere
You don’t have 20 cybersecurity experts. You have 3 — and they support everyone.
4. The SAFe‑approved matrix mechanisms
SAFe provides three explicit mechanisms to support the matrix:
A. Shared Services
Specialists who support ARTs but are not embedded in them.
Examples:
- security
- architecture
- compliance
- legal
- data governance
B. Communities of Practice (CoPs)
Cross‑ART groups that maintain:
- standards
- best practices
- training
- knowledge sharing
Examples:
- UX CoP
- DevOps CoP
- Architecture CoP
- Testing CoP
C. Centers of Excellence (CoEs)
Enterprise‑level bodies that own:
- policy
- governance
- frameworks
- enterprise tooling
- skill development
Examples:
- Agile CoE
- Architecture CoE
- Data CoE
- Security CoE
5. The “Coordinator / Administrator” role=
In SAFe terms, this role appears as:
- **Practice Lead**
- **Chapter Lead** (Spotify model)
- **CoP Facilitator**
- **Enterprise Architect**
- **Security Lead**
- **Data Governance Lead**
- **Platform Owner**
- **Capability Owner**
These people:
- maintain standards
- coordinate training
- ensure consistency
- manage skill development
- support ARTs
- enforce compliance
- maintain shared platforms
This is the *horizontal* leadership layer.
The Practical Implementation Roadmap
This is the sequence used by successful transformations.
1. Start With Value Streams (Not Teams, Not Roles, Not Ceremonies)
Most failed SAFe adoptions start by reorganising teams or running PI Planning. This is the wrong first step.
You should start by mapping how value actually flows through the organisation.
Deliverables:
- Operational Value Stream Map
- Development Value Stream Map
- Identification of ART boundaries
- Identification of major bottlenecks
This matters because SAFe is built around value streams, not departments. If we get this wrong, everything else breaks.
2. Form the First Agile Release Train (ART)
An ART is 50–125 people working on one value stream.
Practical steps:
- Identify the product or service
- Identify the teams contributing to it
- Identify the shared architecture
- Identify the shared backlog
- Identify the leadership (RTE, PM, Architect)
If the teams cannot deliver value independently, they belong on the same ART.
3. Train Leadership First (Not Teams)
This is the most important step.
Executives and managers must understand:
- Lean thinking
- Flow
- Decentralised decision‑making
- Economic prioritisation
- How SAFe actually works
If leadership doesn’t change, SAFe becomes a cargo cult.
Deliverables:
- Leadership alignment
- Lean Portfolio Management understanding
- Commitment to change funding and governance
4. Train Teams and Launch the ART
Now you train the teams but only after leadership alignment.
What teams learn:
- Scrum or Kanban
- SAFe roles
- PI Planning
- Flow metrics
- DevOps basics
What you avoid:
- Overloading them with portfolio‑level theory
- Forcing them into rigid processes
- Turning SAFe into bureaucracy
5. Prepare for the First PI Planning
This is where organisations can fail because they treat PI Planning like a meeting. It is not a meeting: It is a synchronisation mechanism.
Preparation includes:
- A prioritised Program Backlog
- Architectural runway
- Clear business context
- Clear vision
- Stable teams
- A room (physical or virtual) that actually works
The backlog is critical, so if the backlog isn’t ready, don’t run PI Planning until it is.
6. Run PI Planning (The First Real Test)
This is (hopefully) the moment the organisation becomes aligned.
What should happen:
- Vision becomes Features which become Team plans
- Dependencies are identified
- Risks are surfaced
- PI Objectives are created
- The confidence vote at the end attests to the team's buy-in
What to watch for:
- Teams overloaded
- Architecture unclear
- Dependencies unmanaged
- Leadership not present
If PI Planning fails, the ART fails.
7. Execute the PI (5 Sprints)
This is where the real transformation happens.
Focus on:
- Flow
- Integration
- System demos
- Removing impediments
- Improving architecture
- Coaching teams
Avoid:
- Micromanagement
- Forcing velocity targets
- Over‑engineering ceremonies
8. Inspect & Adapt (The Most Important Event in SAFe)
This is the enterprise‑level retrospective.
Components:
- PI System Demo
- Quantitative metrics
- Problem‑solving workshop
- Improvement backlog
This is where the organisation learns. Without I&A, SAFe becomes static and dies. It is almost certain that your first increments will have a lot of issues arise as many staff may have dual reporting and responsibility lines with conflicting obligations while the organisation adjusts to the new paradigm. That issue alone will cause the 'wheels to fall off' in some projects. This is exactly what occurred in Matrix adoption initially. Further avoiding micro-management, inter-scrum coordination, processes and resourcing will likely all have to be tuned. Expect issues and learn from them: tune and adjust.
9. Expand to Additional ARTs (Only When Ready)
You do not roll out SAFe across the whole organisation at once. You start small - just 5 increments. You learn from the mistakes, you retrain and tune processes, you ADAPT the system to the organisation culture. You take little steps to achieve big results, and most important you stay focussed on whether there is actually value add accruing.
You scale when:
- The first ART is stable
- Leadership is aligned
- Architecture supports scaling
- Value streams are clear
Scaling includes:
- Additional ARTs
- Shared services
- Portfolio Kanban
- Lean budgeting
10. Implement Lean Portfolio Management (LPM)
This is the final stage — not the first. Here we are starting to impact the organisations structure.
LPM responsibilities:
- Strategy
- Funding
- Governance
- Portfolio Kanban
- Epic approval
- Guardrails
The reason we turn to LPM last is because LPM only works when:
- ARTs are stable
- Flow is visible
- Metrics are reliable
- Architecture is coherent
The Minimum Viable SAFe (MVS)
If you want the simplest version that works:
- Identify value streams
- Form an ART
- Train leadership
- Train teams
- Run PI Planning
- Deliver value
- Inspect & Adapt
Everything else is optional until the system stabilises.
The Top 10 Failure Modes to Avoid
- Starting with training instead of value streams
- Leadership not changing behaviour
- Treating PI Planning as a ceremony
- No architectural runway
- No real Product Management
- Teams not stable
- Too many dependencies
- No Inspect & Adapt
- Forcing SAFe everywhere
- Turning SAFe into bureaucracy
The Top 10 Success Patterns to Pursue
- Strong RTE
- Strong Product Manager
- Clear value streams
- Real architectural leadership
- Leadership alignment
- Good backlog hygiene
- Real system demos
- Continuous integration
- Flow metrics
- Relentless improvement
SAFe + Agentic AI (our future direction)
With the advent of Agentic AI, the SAFe model can be adapted with Agents taking on much of the integration function.
SAFe provides:
- structure
- cadence
- governance
- alignment
Agentic AI provides:
- automation
- analysis
- orchestration
- continuous sensing
- autonomous execution
Together, they create: Enterprise Agile 2.0: A hybrid human–AI operating model.
Agents can plug into:
- Portfolio Kanban (epic analysis)
- PI Planning (capacity simulation)
- Backlog refinement (PBI generation)
- Architecture runway (design evaluation)
- Flow metrics (bottleneck detection)
- Compliance (continuous monitoring)
This is the future we are moving towards.
See Also
- Managing Agents: The Discipline of Human AI - Orchestration
- Agile Frameworks - Scrum
- Agile Frameworks - Embedding Agentic AI into Scrum
- Agile Frameworks - Enterprise Agile with Agentic AI
Next Steps:
- SAFe + Agentic AI (the future model) - How agents plug into every SAFe layer.
- SAFe Portfolio Kanban - How strategy flows into execution.
- SAFe vs Scrum vs Kanban - When to use which.
- How to implement SAFe in a real organisation - Practical, not theoretical.
