About The Author & The Article

Jonathan Bishop, Group Chairman, Bishop Phillips Consulting. [1]

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.

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.

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

SAFe organises the enterprise around value streams, not departments.

A value stream is:
The sequence of activities that delivers value to a customer.

Each value stream has:

funding
teams
architecture
governance
metrics

This is the opposite of traditional org charts.

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

Program Level
Role	Description
Product Manager	Owns the Program Backlog. Focus: What should the ART build next? Responsibilities: Define features Prioritise the Program Backlog Work with customers and stakeholders Align multiple POs Drive the Product Vision 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? Responsibilities: Facilitate PI Planning Manage cross-team flow Remove systemic impediments Coach Scrum Masters Run Inspect & Adapt 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? Responsibilities: Define architectural guidelines Ensure consistency across teams Support intentional architecture Manage technical debt at scale
Business Owners	The key stakeholders for the ART. Focus: Is the ART delivering business value? Responsibilities: Attend PI Planning Approve PI Objectives Provide strategic direction
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

Portfolio Level
Role	Description
Epic Owners	Own portfolio epics (big initiatives). Focus: Drive large-scale change. Responsibilities: Define epics Build business cases Manage the Portfolio Kanban Coordinate across ARTs
Enterprise Architect	Owns enterprise-wide architecture. Focus: Ensure technical coherence across value streams. Responsibilities: Define architectural strategy Guide Solution and System Architects Ensure alignment with enterprise standards
Lean Portfolio Manager	A group, not a person. Focus: Where should we invest? Responsibilities: Set strategy Allocate budgets Approve epics Govern value streams

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 PI Planning

What SAFe PI Planning Actually Is

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

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.

SAFe + Agentic AI (our future direction)

This is where things get exciting.

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.

Next Steps: Choose Your Path

SAFe + Agentic AI (the future model) - How agents plug into every SAFe layer.
SAFe Roles Explained - PO vs PM vs RTE vs Epic Owner.
SAFe Portfolio Kanban - How strategy flows into execution.
SAFe PI Planning - How multi‑team planning actually works.
SAFe vs Scrum vs Kanban - When to use which.
How to implement SAFe in a real organisation - Practical, not theoretical.

BackLinks

Enterprise Agile Transformation

Anonymous

Search

Agile Frameworks - SAFe