RiskWiki - User contributions [en]

Main Page

2026-05-15T04:39:08Z

Bishopj:

='''The BPC RiskWiki'''=
__NOTOC__

'''''SPONSORED BY:'''''

[[Image:BPCTitle75PERC.jpg]]

{|width="100%"
|-width="100%"
|
<table align=left style="background-color:#FFEBCD;margin-right:0.9em" cellpadding="2" cellspacing="1" >
<tr>
<td>
==Quick Index==

* [[Contents]]
*'''Articles about BPC Software Systems'''
** [[BPC RiskManager Software Suite|BPC RiskManager]]
** [[BPC SurveyManager - Overview|BPC SurveyManager]]
** [[BPC RiskManager Frequently Asked Questions]]
** [[Bishop Phillips - Software Library Reference for Developers]]
*'''Articles about Governance Function Business Methods'''
** [[Internal Audit]]
** [[Risk Management]]
** [[Managing Risk in Mergers & Acquisitions]]
*'''Articles about General Management Methods'''
** [[Business Process Reengineering]]
** [[Managing Agents: The Discipline of Human AI - Orchestration]]
** [[Enterprise Agile Transformation]]
** [[Agile Frameworks - Scrum]]
** [[Agile Frameworks - SAFe]]
** [[Agile Frameworks - Embedding Agentic AI into Scrum]]
** [[Agile Frameworks - Enterprise Agile with Agentic AI]]
** [[Report Writing]]
*'''Articles about Virtual Worlds'''
** [[Virtual Learning Systems]]
*'''About The RiskWiki'''
** [[About The RiskWiki]]
** [[Contributors]]
</td>
</tr>
</table>

==Introduction to the RiskWiki==

This wiki is sponsored by Bishop Phillips Consulting (http://www.bishopphillips.com/) for the education, use and enjoyment of our clients, educators, the public and professionals involved in management consulting and risk advisory, compliance, internal audit, insurance claims management, safety, governance and risk analysis industries. It provides reference articles on management, risk and risk related functions including: Risk Management, Internal Audit, Governance, Compliance, and Process Reengineering, etc.

The RiskWiki is based on the articles, methods, manuals and papers of primarily three firms: Bishop Phillips Consulting P/L, Stanton Consulting Partners and Bishop Finance P/L. These firms are contributing a large body of work amassed over many years experience with hundreds of clients. The project to convert and upload much of our BPC software help & manuals, extended body of consulting, risk and internal audit methods and models, and education and research materials is a large and time consuming project so the RiskWiki content changes frequently and will do so for the foreseeable future.

With the exception of all software documentation, and those additional documents marked otherwise, all written material on this site may be used freely by readers for any purpose including reproduction, subject only to the retention of moral rights by the authors. Some articles may include images for which additional permission may be required prior to reproduction. Software documentation may be duplicated in hard-copy for internal use by registered users of the systems with current maintenance agreements. Other uses of software systems documentation will be considered on written request.

==Things to See in The RiskWiki==

===BPC RiskManager===

*'''''Are you looking for BPC RiskManager Documentation or to learn more about the software?'''''

<div class="imagewrap" style="float: left; margin-right:10px;" >[[image:BPC_RiskManager_V6261_Main_Screen.jpg|100px|link=BPC RiskManager Software Suite]]
</div>Bishop Phillips supplies [[BPC RiskManager Software Suite|the BPC RiskManagement suite of governance software]] that provides a complete governance solution across risk management, controls management, compliance management, insurance management, claims management, incident & hazard management, audit risk management, governance document management and survey generation and management. The system can be installed in configurations ranging from single-user to very large scale enterprise configurations.

The system is particularly suited to managing and reporting on the risk and compliance management tasks of government agencies, whole of government, special project, not-for-profits, insurance providers, service industries, utilities, and tertiary education sectors. You will find an extensive body of information covering [[BPC RiskManager Software Suite|technical, administration and user level tasks here]].

If you have questions they may be answered in our [[BPC RiskManager Frequently Asked Questions|frequently asked questions]].

<div class="mainfloatright" style="width:54%; max-width:70%; float:Right; overflow: auto; padding-left:10px; padding-right:10px;" >
{|align="left" width="100%"
|- style="background-color:#FFEBCD; padding-bottom:10px;" width="100%"
|[[BPC RiskManager Frequently Asked Questions|'''Frequently asked Questions About BPC RiskManger''']]
|-width="100%"
|
<div class="didyouknow2" STYLE="height: 400px;
border: thin solid black; display: block; overflow: auto; padding-left:10px; padding-top:20px; padding-bottom:20px; padding-right:10px;" >
{{#dpl: includepage=*
|includemaxlength=1000
|escapelinks=false
|resultsheader=__NOTOC__ __NOEDITSECTION__
|randomcount=1
|mode=userformat
|category=RiskManager FAQ
|addpagecounter=true
|listseparators=<H2>, [[%PAGE%]]</h2>\n,[[%PAGE%|Read More..]],\n
}}</div>
<div style="clear: both;">
</div>
|- style="background-color:#FFEBCD; width:100%;"
|'''Featured Article...'''
|-width="100%"
|
<div class="didyouknow2" STYLE="height: 400px; border: thin solid black; display: block; overflow: auto; padding-left:10px; padding-right:10px; padding-top:20px; padding-bottom:20px; " >
{{#dpl: includepage=*
|includemaxlength=4000
|escapelinks=false
|resultsheader=__NOTOC__ __NOEDITSECTION__
|randomcount=1
|mode=userformat
|category=Featured Article
|addpagecounter=true
|listseparators=<H2>, [[%PAGE%]]</h2>\n,[[%PAGE%| Read More..]],\n
}}
</div>
<div style="clear: both;">
</div>
|}
</div>

===BPC SurveyManager===

*'''''Are you looking for BPC SurveyManager Documentation or to learn more about the software?'''''

<div class="imagewrap" style="float: left; margin-right:10px;" >[[image:BPCSurveyManager_DTCV7_SurveyEdit_Screen.jpg|link=BPC SurveyManager - Overview|100px]]
</div>Bundled with the BPC RiskManager suite and also supplied in both hosted and installed forms, the BPC SurveyManager software solution is an outstandingly versatile interactive web page generation engine using a survey model as the design and data storage paradigm. While being outstanding at survey creation and management the software is powerful enough to build build conventional data-input web pages. The full [[BPC SurveyManager - Overview|technical and SM language programming documentation is available from here]].

===Research into Virtual Worlds in Business & Education===

*'''''Are you looking for our virtual Learning research papers?'''''

<div class="imagewrap" style="float: left; margin-right:10px;" >[[image:Second_Life_042.jpg|link=Virtual Learning Systems|100px]]
</div>Through our Virtual Worlds research group - "Waisman Learning Systems", we do extensive work in the development of virtual learning and business spaces in SecondLife, and undertake considerable formal research into the application of Virtual Worlds to learning. You will find technical and text book material in our [[Virtual Learning Systems|Virtual World Learning Systems pages]]. There is an extensive overview of the literature, and history of virtual worlds, a very large bibliography, details of our in-world networked lecture theatre control systems and lecture delivery systems, and a complete documentation of an extensive academic study undertaken by our WLS team into the effectiveness at achieving learning outcomes of different approaches in delivering course material in 3D virtual worlds.

You will find an extensive reading list and bibliography of works covering virtual worlds and virtual reality concepts, history, ideas, related technologies, and application in learning as well as relevant papers on learning taxonomies and teaching concepts relevant to [[VirtualWorldLearningReferences|virtual world learning systems here]].

===Internal Audit and Management Science===

*'''''Are you heading up an Internal Audit Team or learning internal audit methods?'''''

<div class="imagewrap" style="float: left; margin-right:10px;" >[[image:ALSBA.png|link=Internal Audit|100px]]
</div>If yes, you will find complete enterprise level internal audit methods and manuals on this site cross linked to our other management papers. The internal audit manuals cover everything from managing the audit team through planning the audit program to the detail of designing the audit, conducting interviews and undertaking the controls analysis; to reporting the results. Everything you are likely to need to [[Internal Audit|manage and train an internal audit team is here]].

*'''''Are you a manager, management consultant or student of Management Science?'''''

<div class="imagewrap" style="float: left; margin-right:10px;" >[[image:BPRAnalyticStructure.png|link=Category:Management Science|100px]]
</div>You will find articles covering topics of general management and process management methods in the RiskWiki including the detailed theory and practice of plannning, process re-engineering, control theory and our proven theories in stakeholder network organisation modelling. The work here is generally unique to this site. All methods have been used extensively and effectively in practice. Start here with [[Business Process Reengineering|process engineering]].

*'''''Are you managing a merger or an acquisition?'''''

<div class="imagewrap" style="float: left; margin-right:10px;" >[[Image:MnA_WhyMerge.jpg|link=Managing Risk in Mergers & Acquisitions|100px]]
</div>Take a look [[Managing Risk in Mergers & Acquisitions|here first and learn about the risks]] in mergers and acquisitions and successful strategies for managing them from our team who have been through it successfully from both sides or the equation multiple times.
|}

==Take A Random Look At The RiskWiki==

{|width="100%"
|- style="background-color:#FFEBCD;" width="100%"
|'''From the Vault of the BPC RiskWiki...'''
|-
|
<div class="didyouknow" width="100%" STYLE="height: 400px;
border: thin solid black; display: block; padding-left:10px; padding-right:10px; overflow: auto;" >
{{#dpl: namespace=
|includepage=*
|includemaxlength=1000
|escapelinks=false
|resultsheader=__NOTOC__ __NOEDITSECTION__
|randomcount=1
|mode=userformat
|addpagecounter=true
|listseparators=<H2>, [[%PAGE%]]</h2>\n,[[%PAGE%|Read More..]],\n
}}
</div>
<div style="clear: both;">
</div>
|}

Agile Frameworks - SAFe

2026-05-14T23:51:08Z

Bishopj: /* 5. The “Coordinator / Administrator” role */

<noinclude>
==About The Author & The Article==
[[Jonathan Bishop]], Group Chairman, Bishop Phillips Consulting. [http://www.bishopphillips.com/]

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 [http://www.bishopphillips.com/ www.bishopphillips.com].
</noinclude>

=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 [[Agile Frameworks - Scrum|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==
{| class="wikitable"
|+ Value Stream Examples
|-
! No. !! Industry !! Operational Value Stream !! Development Value Stream
|-
| 1 || Banking||
“Process a home loan application.”<br>
Steps:
# Customer applies
# Credit check
# Risk assessment
# Approval
# Settlement
|| “Build and maintain the loan origination system.”<br>
Teams:
* Frontend
* Backend
* Risk engine
* Document management
* Integration
|-
| 2|| Retail / E‑Commerce||
“Customer buys a product online.”
Steps:
# Browse
# Add to cart
# Payment
# Warehouse pick/pack
# Delivery
|| “Develop and operate the e‑commerce platform.”
Teams:
* Website
* Mobile app
* Payment gateway
* Inventory system
* Logistics integration
|-
| 3|| Healthcare||
“Treat a patient in emergency.”
Steps:
# Triage
# Diagnosis
# Treatment
# Discharge
||
“Build and maintain the hospital EMR system.”
Teams:
* Patient records
* Imaging integration
* Billing
* Clinical workflows
|-
| 4|| Government|| “Issue a driver’s licence.”
Steps:
# Application
# Identity verification
# Testing
# Issuance
|| “Develop and maintain the licensing system.”
Teams:
* Identity services
* Workflow engine
* Payment
* Document generation
|-
| 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:<br>
1. '''Team Level'''<br>
This is the Scrum level which are explained in detail in [[Agile Frameworks - Scrum]]:
* Product Owner
* Scrum Master
* Developers

2. '''Program Level'''<br>
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
<i>
Plus two external roles:
* Business Owners
* System Team
</i>

{| class="wikitable"
|+ Program Level
|-
! Role !! Description
|-
| '''Product Manager'''|| Owns the Program Backlog.
''Focus: What should the ART build next?''
<br>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?''
<br>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?''
<br>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?''
<br>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'''<br>
This is where SAFe becomes Enterprise Agile:
* Epic Owners
* Enterprise Architect
* Lean Portfolio Manager

{| class="wikitable"
|+ Portfolio Level
|-
! Role !! Description
|-
| '''Epic Owners'''|| Own portfolio epics (big initiatives).
''Focus: Drive large-scale change.''
<br>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.''
<br>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?''
<br>Responsibilities:
* Set strategy
* Allocate budgets
* Approve epics
* Govern value streams
|}

'''4. Large Solution Level (Optional)'''
<br>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.
<br>
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:
* '''''R'''''esolved
* '''''O'''''wned
* '''''A'''''ccepted
* '''''M'''''itigated

''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 '''ROAM'''ed.

===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.''

<noinclude>
[[Category:To Be Featured Article]]
[[Category:Management Science]]
[[Category:AI Responsive Management]]
{{BackLinks}}
</noinclude>

Agile Frameworks - SAFe

2026-05-14T23:50:20Z

Bishopj: /* 5. The “Coordinator / Administrator” role= */

<noinclude>
==About The Author & The Article==
[[Jonathan Bishop]], Group Chairman, Bishop Phillips Consulting. [http://www.bishopphillips.com/]

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 [http://www.bishopphillips.com/ www.bishopphillips.com].
</noinclude>

=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 [[Agile Frameworks - Scrum|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==
{| class="wikitable"
|+ Value Stream Examples
|-
! No. !! Industry !! Operational Value Stream !! Development Value Stream
|-
| 1 || Banking||
“Process a home loan application.”<br>
Steps:
# Customer applies
# Credit check
# Risk assessment
# Approval
# Settlement
|| “Build and maintain the loan origination system.”<br>
Teams:
* Frontend
* Backend
* Risk engine
* Document management
* Integration
|-
| 2|| Retail / E‑Commerce||
“Customer buys a product online.”
Steps:
# Browse
# Add to cart
# Payment
# Warehouse pick/pack
# Delivery
|| “Develop and operate the e‑commerce platform.”
Teams:
* Website
* Mobile app
* Payment gateway
* Inventory system
* Logistics integration
|-
| 3|| Healthcare||
“Treat a patient in emergency.”
Steps:
# Triage
# Diagnosis
# Treatment
# Discharge
||
“Build and maintain the hospital EMR system.”
Teams:
* Patient records
* Imaging integration
* Billing
* Clinical workflows
|-
| 4|| Government|| “Issue a driver’s licence.”
Steps:
# Application
# Identity verification
# Testing
# Issuance
|| “Develop and maintain the licensing system.”
Teams:
* Identity services
* Workflow engine
* Payment
* Document generation
|-
| 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:<br>
1. '''Team Level'''<br>
This is the Scrum level which are explained in detail in [[Agile Frameworks - Scrum]]:
* Product Owner
* Scrum Master
* Developers

2. '''Program Level'''<br>
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
<i>
Plus two external roles:
* Business Owners
* System Team
</i>

{| class="wikitable"
|+ Program Level
|-
! Role !! Description
|-
| '''Product Manager'''|| Owns the Program Backlog.
''Focus: What should the ART build next?''
<br>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?''
<br>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?''
<br>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?''
<br>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'''<br>
This is where SAFe becomes Enterprise Agile:
* Epic Owners
* Enterprise Architect
* Lean Portfolio Manager

{| class="wikitable"
|+ Portfolio Level
|-
! Role !! Description
|-
| '''Epic Owners'''|| Own portfolio epics (big initiatives).
''Focus: Drive large-scale change.''
<br>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.''
<br>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?''
<br>Responsibilities:
* Set strategy
* Allocate budgets
* Approve epics
* Govern value streams
|}

'''4. Large Solution Level (Optional)'''
<br>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.
<br>
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:
* '''''R'''''esolved
* '''''O'''''wned
* '''''A'''''ccepted
* '''''M'''''itigated

''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 '''ROAM'''ed.

===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.''

<noinclude>
[[Category:To Be Featured Article]]
[[Category:Management Science]]
[[Category:AI Responsive Management]]
{{BackLinks}}
</noinclude>

Agile Frameworks - SAFe

2026-05-14T23:48:03Z

Bishopj: /* Next Steps: */

<noinclude>
==About The Author & The Article==
[[Jonathan Bishop]], Group Chairman, Bishop Phillips Consulting. [http://www.bishopphillips.com/]

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 [http://www.bishopphillips.com/ www.bishopphillips.com].
</noinclude>

=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 [[Agile Frameworks - Scrum|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==
{| class="wikitable"
|+ Value Stream Examples
|-
! No. !! Industry !! Operational Value Stream !! Development Value Stream
|-
| 1 || Banking||
“Process a home loan application.”<br>
Steps:
# Customer applies
# Credit check
# Risk assessment
# Approval
# Settlement
|| “Build and maintain the loan origination system.”<br>
Teams:
* Frontend
* Backend
* Risk engine
* Document management
* Integration
|-
| 2|| Retail / E‑Commerce||
“Customer buys a product online.”
Steps:
# Browse
# Add to cart
# Payment
# Warehouse pick/pack
# Delivery
|| “Develop and operate the e‑commerce platform.”
Teams:
* Website
* Mobile app
* Payment gateway
* Inventory system
* Logistics integration
|-
| 3|| Healthcare||
“Treat a patient in emergency.”
Steps:
# Triage
# Diagnosis
# Treatment
# Discharge
||
“Build and maintain the hospital EMR system.”
Teams:
* Patient records
* Imaging integration
* Billing
* Clinical workflows
|-
| 4|| Government|| “Issue a driver’s licence.”
Steps:
# Application
# Identity verification
# Testing
# Issuance
|| “Develop and maintain the licensing system.”
Teams:
* Identity services
* Workflow engine
* Payment
* Document generation
|-
| 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:<br>
1. '''Team Level'''<br>
This is the Scrum level which are explained in detail in [[Agile Frameworks - Scrum]]:
* Product Owner
* Scrum Master
* Developers

2. '''Program Level'''<br>
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
<i>
Plus two external roles:
* Business Owners
* System Team
</i>

{| class="wikitable"
|+ Program Level
|-
! Role !! Description
|-
| '''Product Manager'''|| Owns the Program Backlog.
''Focus: What should the ART build next?''
<br>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?''
<br>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?''
<br>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?''
<br>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'''<br>
This is where SAFe becomes Enterprise Agile:
* Epic Owners
* Enterprise Architect
* Lean Portfolio Manager

{| class="wikitable"
|+ Portfolio Level
|-
! Role !! Description
|-
| '''Epic Owners'''|| Own portfolio epics (big initiatives).
''Focus: Drive large-scale change.''
<br>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.''
<br>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?''
<br>Responsibilities:
* Set strategy
* Allocate budgets
* Approve epics
* Govern value streams
|}

'''4. Large Solution Level (Optional)'''
<br>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.
<br>
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:
* '''''R'''''esolved
* '''''O'''''wned
* '''''A'''''ccepted
* '''''M'''''itigated

''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 '''ROAM'''ed.

===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.''

<noinclude>
[[Category:To Be Featured Article]]
[[Category:Management Science]]
[[Category:AI Responsive Management]]
{{BackLinks}}
</noinclude>

Agile Frameworks - SAFe

2026-05-14T23:45:28Z

Bishopj: /* 3. Why the matrix is not only acceptable — it’s optimal */

<noinclude>
==About The Author & The Article==
[[Jonathan Bishop]], Group Chairman, Bishop Phillips Consulting. [http://www.bishopphillips.com/]

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 [http://www.bishopphillips.com/ www.bishopphillips.com].
</noinclude>

=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 [[Agile Frameworks - Scrum|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==
{| class="wikitable"
|+ Value Stream Examples
|-
! No. !! Industry !! Operational Value Stream !! Development Value Stream
|-
| 1 || Banking||
“Process a home loan application.”<br>
Steps:
# Customer applies
# Credit check
# Risk assessment
# Approval
# Settlement
|| “Build and maintain the loan origination system.”<br>
Teams:
* Frontend
* Backend
* Risk engine
* Document management
* Integration
|-
| 2|| Retail / E‑Commerce||
“Customer buys a product online.”
Steps:
# Browse
# Add to cart
# Payment
# Warehouse pick/pack
# Delivery
|| “Develop and operate the e‑commerce platform.”
Teams:
* Website
* Mobile app
* Payment gateway
* Inventory system
* Logistics integration
|-
| 3|| Healthcare||
“Treat a patient in emergency.”
Steps:
# Triage
# Diagnosis
# Treatment
# Discharge
||
“Build and maintain the hospital EMR system.”
Teams:
* Patient records
* Imaging integration
* Billing
* Clinical workflows
|-
| 4|| Government|| “Issue a driver’s licence.”
Steps:
# Application
# Identity verification
# Testing
# Issuance
|| “Develop and maintain the licensing system.”
Teams:
* Identity services
* Workflow engine
* Payment
* Document generation
|-
| 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:<br>
1. '''Team Level'''<br>
This is the Scrum level which are explained in detail in [[Agile Frameworks - Scrum]]:
* Product Owner
* Scrum Master
* Developers

2. '''Program Level'''<br>
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
<i>
Plus two external roles:
* Business Owners
* System Team
</i>

{| class="wikitable"
|+ Program Level
|-
! Role !! Description
|-
| '''Product Manager'''|| Owns the Program Backlog.
''Focus: What should the ART build next?''
<br>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?''
<br>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?''
<br>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?''
<br>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'''<br>
This is where SAFe becomes Enterprise Agile:
* Epic Owners
* Enterprise Architect
* Lean Portfolio Manager

{| class="wikitable"
|+ Portfolio Level
|-
! Role !! Description
|-
| '''Epic Owners'''|| Own portfolio epics (big initiatives).
''Focus: Drive large-scale change.''
<br>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.''
<br>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?''
<br>Responsibilities:
* Set strategy
* Allocate budgets
* Approve epics
* Govern value streams
|}

'''4. Large Solution Level (Optional)'''
<br>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.
<br>
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:
* '''''R'''''esolved
* '''''O'''''wned
* '''''A'''''ccepted
* '''''M'''''itigated

''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 '''ROAM'''ed.

===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.''

<noinclude>
[[Category:To Be Featured Article]]
[[Category:Management Science]]
[[Category:AI Responsive Management]]
{{BackLinks}}
</noinclude>

Agile Frameworks - SAFe

2026-05-14T23:41:21Z

Bishopj: /* 2. The SAFe‑compatible matrix structure (the real one) */

<noinclude>
==About The Author & The Article==
[[Jonathan Bishop]], Group Chairman, Bishop Phillips Consulting. [http://www.bishopphillips.com/]

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 [http://www.bishopphillips.com/ www.bishopphillips.com].
</noinclude>

=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 [[Agile Frameworks - Scrum|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==
{| class="wikitable"
|+ Value Stream Examples
|-
! No. !! Industry !! Operational Value Stream !! Development Value Stream
|-
| 1 || Banking||
“Process a home loan application.”<br>
Steps:
# Customer applies
# Credit check
# Risk assessment
# Approval
# Settlement
|| “Build and maintain the loan origination system.”<br>
Teams:
* Frontend
* Backend
* Risk engine
* Document management
* Integration
|-
| 2|| Retail / E‑Commerce||
“Customer buys a product online.”
Steps:
# Browse
# Add to cart
# Payment
# Warehouse pick/pack
# Delivery
|| “Develop and operate the e‑commerce platform.”
Teams:
* Website
* Mobile app
* Payment gateway
* Inventory system
* Logistics integration
|-
| 3|| Healthcare||
“Treat a patient in emergency.”
Steps:
# Triage
# Diagnosis
# Treatment
# Discharge
||
“Build and maintain the hospital EMR system.”
Teams:
* Patient records
* Imaging integration
* Billing
* Clinical workflows
|-
| 4|| Government|| “Issue a driver’s licence.”
Steps:
# Application
# Identity verification
# Testing
# Issuance
|| “Develop and maintain the licensing system.”
Teams:
* Identity services
* Workflow engine
* Payment
* Document generation
|-
| 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:<br>
1. '''Team Level'''<br>
This is the Scrum level which are explained in detail in [[Agile Frameworks - Scrum]]:
* Product Owner
* Scrum Master
* Developers

2. '''Program Level'''<br>
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
<i>
Plus two external roles:
* Business Owners
* System Team
</i>

{| class="wikitable"
|+ Program Level
|-
! Role !! Description
|-
| '''Product Manager'''|| Owns the Program Backlog.
''Focus: What should the ART build next?''
<br>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?''
<br>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?''
<br>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?''
<br>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'''<br>
This is where SAFe becomes Enterprise Agile:
* Epic Owners
* Enterprise Architect
* Lean Portfolio Manager

{| class="wikitable"
|+ Portfolio Level
|-
! Role !! Description
|-
| '''Epic Owners'''|| Own portfolio epics (big initiatives).
''Focus: Drive large-scale change.''
<br>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.''
<br>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?''
<br>Responsibilities:
* Set strategy
* Allocate budgets
* Approve epics
* Govern value streams
|}

'''4. Large Solution Level (Optional)'''
<br>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.
<br>
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:
* '''''R'''''esolved
* '''''O'''''wned
* '''''A'''''ccepted
* '''''M'''''itigated

''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 '''ROAM'''ed.

===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. Why the matrix is not only acceptable — it’s optimal====
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.''

<noinclude>
[[Category:To Be Featured Article]]
[[Category:Management Science]]
[[Category:AI Responsive Management]]
{{BackLinks}}
</noinclude>

Agile Frameworks - SAFe

2026-05-14T23:40:03Z

Bishopj: /* How to Identify a Value Stream (The Practical Test) */

<noinclude>
==About The Author & The Article==
[[Jonathan Bishop]], Group Chairman, Bishop Phillips Consulting. [http://www.bishopphillips.com/]

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 [http://www.bishopphillips.com/ www.bishopphillips.com].
</noinclude>

=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 [[Agile Frameworks - Scrum|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==
{| class="wikitable"
|+ Value Stream Examples
|-
! No. !! Industry !! Operational Value Stream !! Development Value Stream
|-
| 1 || Banking||
“Process a home loan application.”<br>
Steps:
# Customer applies
# Credit check
# Risk assessment
# Approval
# Settlement
|| “Build and maintain the loan origination system.”<br>
Teams:
* Frontend
* Backend
* Risk engine
* Document management
* Integration
|-
| 2|| Retail / E‑Commerce||
“Customer buys a product online.”
Steps:
# Browse
# Add to cart
# Payment
# Warehouse pick/pack
# Delivery
|| “Develop and operate the e‑commerce platform.”
Teams:
* Website
* Mobile app
* Payment gateway
* Inventory system
* Logistics integration
|-
| 3|| Healthcare||
“Treat a patient in emergency.”
Steps:
# Triage
# Diagnosis
# Treatment
# Discharge
||
“Build and maintain the hospital EMR system.”
Teams:
* Patient records
* Imaging integration
* Billing
* Clinical workflows
|-
| 4|| Government|| “Issue a driver’s licence.”
Steps:
# Application
# Identity verification
# Testing
# Issuance
|| “Develop and maintain the licensing system.”
Teams:
* Identity services
* Workflow engine
* Payment
* Document generation
|-
| 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:<br>
1. '''Team Level'''<br>
This is the Scrum level which are explained in detail in [[Agile Frameworks - Scrum]]:
* Product Owner
* Scrum Master
* Developers

2. '''Program Level'''<br>
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
<i>
Plus two external roles:
* Business Owners
* System Team
</i>

{| class="wikitable"
|+ Program Level
|-
! Role !! Description
|-
| '''Product Manager'''|| Owns the Program Backlog.
''Focus: What should the ART build next?''
<br>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?''
<br>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?''
<br>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?''
<br>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'''<br>
This is where SAFe becomes Enterprise Agile:
* Epic Owners
* Enterprise Architect
* Lean Portfolio Manager

{| class="wikitable"
|+ Portfolio Level
|-
! Role !! Description
|-
| '''Epic Owners'''|| Own portfolio epics (big initiatives).
''Focus: Drive large-scale change.''
<br>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.''
<br>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?''
<br>Responsibilities:
* Set strategy
* Allocate budgets
* Approve epics
* Govern value streams
|}

'''4. Large Solution Level (Optional)'''
<br>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.
<br>
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:
* '''''R'''''esolved
* '''''O'''''wned
* '''''A'''''ccepted
* '''''M'''''itigated

''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 '''ROAM'''ed.

===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 (the real one)====
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. Why the matrix is not only acceptable — it’s optimal====
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.''

<noinclude>
[[Category:To Be Featured Article]]
[[Category:Management Science]]
[[Category:AI Responsive Management]]
{{BackLinks}}
</noinclude>

Agile Frameworks - SAFe

2026-05-14T23:38:26Z

Bishopj: /* Examples of Value Streams */

<noinclude>
==About The Author & The Article==
[[Jonathan Bishop]], Group Chairman, Bishop Phillips Consulting. [http://www.bishopphillips.com/]

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 [http://www.bishopphillips.com/ www.bishopphillips.com].
</noinclude>

=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 [[Agile Frameworks - Scrum|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==
{| class="wikitable"
|+ Value Stream Examples
|-
! No. !! Industry !! Operational Value Stream !! Development Value Stream
|-
| 1 || Banking||
“Process a home loan application.”<br>
Steps:
# Customer applies
# Credit check
# Risk assessment
# Approval
# Settlement
|| “Build and maintain the loan origination system.”<br>
Teams:
* Frontend
* Backend
* Risk engine
* Document management
* Integration
|-
| 2|| Retail / E‑Commerce||
“Customer buys a product online.”
Steps:
# Browse
# Add to cart
# Payment
# Warehouse pick/pack
# Delivery
|| “Develop and operate the e‑commerce platform.”
Teams:
* Website
* Mobile app
* Payment gateway
* Inventory system
* Logistics integration
|-
| 3|| Healthcare||
“Treat a patient in emergency.”
Steps:
# Triage
# Diagnosis
# Treatment
# Discharge
||
“Build and maintain the hospital EMR system.”
Teams:
* Patient records
* Imaging integration
* Billing
* Clinical workflows
|-
| 4|| Government|| “Issue a driver’s licence.”
Steps:
# Application
# Identity verification
# Testing
# Issuance
|| “Develop and maintain the licensing system.”
Teams:
* Identity services
* Workflow engine
* Payment
* Document generation
|-
| 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:<br>
1. '''Team Level'''<br>
This is the Scrum level which are explained in detail in [[Agile Frameworks - Scrum]]:
* Product Owner
* Scrum Master
* Developers

2. '''Program Level'''<br>
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
<i>
Plus two external roles:
* Business Owners
* System Team
</i>

{| class="wikitable"
|+ Program Level
|-
! Role !! Description
|-
| '''Product Manager'''|| Owns the Program Backlog.
''Focus: What should the ART build next?''
<br>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?''
<br>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?''
<br>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?''
<br>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'''<br>
This is where SAFe becomes Enterprise Agile:
* Epic Owners
* Enterprise Architect
* Lean Portfolio Manager

{| class="wikitable"
|+ Portfolio Level
|-
! Role !! Description
|-
| '''Epic Owners'''|| Own portfolio epics (big initiatives).
''Focus: Drive large-scale change.''
<br>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.''
<br>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?''
<br>Responsibilities:
* Set strategy
* Allocate budgets
* Approve epics
* Govern value streams
|}

'''4. Large Solution Level (Optional)'''
<br>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.
<br>
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:
* '''''R'''''esolved
* '''''O'''''wned
* '''''A'''''ccepted
* '''''M'''''itigated

''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 '''ROAM'''ed.

===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 (the real one)====
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. Why the matrix is not only acceptable — it’s optimal====
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.''

<noinclude>
[[Category:To Be Featured Article]]
[[Category:Management Science]]
[[Category:AI Responsive Management]]
{{BackLinks}}
</noinclude>

Agile Frameworks - SAFe

2026-05-14T23:37:24Z

Bishopj: /* The Core SAFe Idea: Value Streams */

<noinclude>
==About The Author & The Article==
[[Jonathan Bishop]], Group Chairman, Bishop Phillips Consulting. [http://www.bishopphillips.com/]

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 [http://www.bishopphillips.com/ www.bishopphillips.com].
</noinclude>

=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 [[Agile Frameworks - Scrum|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==
{| class="wikitable"
|+ Value Stream Examples
|-
! No. !! Industry !! Operational Value Stream !! Development Value Stream
|-
| 1 || Banking||
“Process a home loan application.”<br>
Steps:
# Customer applies
# Credit check
# Risk assessment
# Approval
# Settlement
|| “Build and maintain the loan origination system.”<br>
Teams:
* Frontend
* Backend
* Risk engine
* Document management
* Integration
|-
| 2|| Retail / E‑Commerce||
“Customer buys a product online.”
Steps:
# Browse
# Add to cart
# Payment
# Warehouse pick/pack
# Delivery
|| “Develop and operate the e‑commerce platform.”
Teams:
* Website
* Mobile app
* Payment gateway
* Inventory system
* Logistics integration
|-
| 3|| Healthcare||
“Treat a patient in emergency.”
Steps:
# Triage
# Diagnosis
# Treatment
# Discharge
||
“Build and maintain the hospital EMR system.”
Teams:
* Patient records
* Imaging integration
* Billing
* Clinical workflows
|-
| 4|| Government|| “Issue a driver’s licence.”
Steps:
# Application
# Identity verification
# Testing
# Issuance
|| “Develop and maintain the licensing system.”
Teams:
* Identity services
* Workflow engine
* Payment
* Document generation
|-
| 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.
|-
| Example || Example || Example || Example
|}

==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:<br>
1. '''Team Level'''<br>
This is the Scrum level which are explained in detail in [[Agile Frameworks - Scrum]]:
* Product Owner
* Scrum Master
* Developers

2. '''Program Level'''<br>
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
<i>
Plus two external roles:
* Business Owners
* System Team
</i>

{| class="wikitable"
|+ Program Level
|-
! Role !! Description
|-
| '''Product Manager'''|| Owns the Program Backlog.
''Focus: What should the ART build next?''
<br>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?''
<br>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?''
<br>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?''
<br>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'''<br>
This is where SAFe becomes Enterprise Agile:
* Epic Owners
* Enterprise Architect
* Lean Portfolio Manager

{| class="wikitable"
|+ Portfolio Level
|-
! Role !! Description
|-
| '''Epic Owners'''|| Own portfolio epics (big initiatives).
''Focus: Drive large-scale change.''
<br>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.''
<br>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?''
<br>Responsibilities:
* Set strategy
* Allocate budgets
* Approve epics
* Govern value streams
|}

'''4. Large Solution Level (Optional)'''
<br>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.
<br>
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:
* '''''R'''''esolved
* '''''O'''''wned
* '''''A'''''ccepted
* '''''M'''''itigated

''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 '''ROAM'''ed.

===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 (the real one)====
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. Why the matrix is not only acceptable — it’s optimal====
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.''

<noinclude>
[[Category:To Be Featured Article]]
[[Category:Management Science]]
[[Category:AI Responsive Management]]
{{BackLinks}}
</noinclude>

Agile Frameworks - SAFe

2026-05-14T15:53:58Z

Bishopj: /* A Question of Organisation Structure */

<noinclude>
==About The Author & The Article==
[[Jonathan Bishop]], Group Chairman, Bishop Phillips Consulting. [http://www.bishopphillips.com/]

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 [http://www.bishopphillips.com/ www.bishopphillips.com].
</noinclude>

=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 [[Agile Frameworks - Scrum|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:<br>
1. '''Team Level'''<br>
This is the Scrum level which are explained in detail in [[Agile Frameworks - Scrum]]:
* Product Owner
* Scrum Master
* Developers

2. '''Program Level'''<br>
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
<i>
Plus two external roles:
* Business Owners
* System Team
</i>

{| class="wikitable"
|+ Program Level
|-
! Role !! Description
|-
| '''Product Manager'''|| Owns the Program Backlog.
''Focus: What should the ART build next?''
<br>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?''
<br>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?''
<br>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?''
<br>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'''<br>
This is where SAFe becomes Enterprise Agile:
* Epic Owners
* Enterprise Architect
* Lean Portfolio Manager

{| class="wikitable"
|+ Portfolio Level
|-
! Role !! Description
|-
| '''Epic Owners'''|| Own portfolio epics (big initiatives).
''Focus: Drive large-scale change.''
<br>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.''
<br>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?''
<br>Responsibilities:
* Set strategy
* Allocate budgets
* Approve epics
* Govern value streams
|}

'''4. Large Solution Level (Optional)'''
<br>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.
<br>
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:
* '''''R'''''esolved
* '''''O'''''wned
* '''''A'''''ccepted
* '''''M'''''itigated

''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 '''ROAM'''ed.

===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 (the real one)====
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. Why the matrix is not only acceptable — it’s optimal====
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.''

<noinclude>
[[Category:To Be Featured Article]]
[[Category:Management Science]]
[[Category:AI Responsive Management]]
{{BackLinks}}
</noinclude>

Agile Frameworks - SAFe

2026-05-14T10:29:24Z

Bishopj: /* Introduction */

Agile Frameworks - SAFe

2026-05-14T10:15:18Z

Bishopj: /* The Top 10 Success Patterns to Pursue */

Agile Frameworks - SAFe

2026-05-14T10:14:44Z

Bishopj: /* The Top 10 Failure Modes to Avoid */

Agile Frameworks - SAFe

2026-05-14T10:13:47Z

Bishopj: /* The Minimum Viable SAFe (MVS) */

Agile Frameworks - SAFe

2026-05-14T10:12:38Z

Bishopj: /* Why SAFe Exists */

Agile Frameworks - SAFe

2026-05-14T09:15:40Z

Bishopj: /* Introduction */

Agile Frameworks - SAFe

2026-05-13T23:02:17Z

Bishopj: /* SAFe + Agentic AI (our future direction) */

Agile Frameworks - SAFe

2026-05-13T22:58:50Z

Bishopj: /* 1. Team Level (Scrum/Kanban Teams) */

Agile Frameworks - SAFe

2026-05-13T22:54:37Z

Bishopj: /* SAFe PI Planning */

Agile Frameworks - SAFe

2026-05-13T22:51:19Z

Bishopj: /* The Real Relationships */

Agile Frameworks - SAFe

2026-05-13T22:50:56Z

Bishopj: /* The Real Relationships */

Agile Frameworks - SAFe

2026-05-13T22:39:55Z

Bishopj: /* SAFe + Agentic AI (our future direction) */

Agile Frameworks - SAFe

2026-05-13T22:38:11Z

Bishopj: /* Next Steps: Choose Your Path */

Agile Frameworks - SAFe

2026-05-13T22:37:18Z

Bishopj: /* "PI Planning is too big." */

Agile Frameworks - SAFe

2026-05-13T22:36:24Z

Bishopj: /* 12. PI Planning Ends → PI Execution Begins */

Agile Frameworks - SAFe

2026-05-13T22:35:44Z

Bishopj: /* The Real Relationships */

Agile Frameworks - SAFe

2026-05-13T21:31:36Z

Bishopj: /* The Core SAFe Idea: Value Streams */

Agile Frameworks - SAFe

2026-05-13T16:14:07Z

Bishopj: /* The SAFe Roles (simplified) */

Agile Frameworks - SAFe

2026-05-13T16:13:42Z

Bishopj: /* The SAFe Roles (simplified) */

Agile Frameworks - SAFe

2026-05-13T15:54:54Z

Bishopj: /* The SAFe Roles (simplified) */

Agile Frameworks - SAFe

2026-05-13T13:11:30Z

Bishopj: Created page with "<noinclude> ==About The Author & The Article== Jonathan Bishop, Group Chairman, Bishop Phillips Consulting. [http://www.bishopphillips.com/] 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. Thi..."

Enterprise Agile Transformation

2026-05-13T12:24:42Z

Bishopj: /* Content of this Section */

Agile Frameworks - Enterprise Agile with Agentic AI

2026-05-13T10:12:36Z

Bishopj: /* 1. What is Enterprise Agile? */

Agile Frameworks - Enterprise Agile with Agentic AI

2026-05-13T10:11:27Z

Bishopj: /* Next Steps */

Agile Frameworks - Enterprise Agile with Agentic AI

2026-05-13T10:09:47Z

Bishopj: /* Next Steps */

Agile Frameworks - Embedding Agentic AI into Scrum

2026-05-13T10:08:32Z

Bishopj: /* Next Steps */

==About The Author & The Article==
[[Jonathan Bishop]], Group Chairman, Bishop Phillips Consulting. [http://www.bishopphillips.com/]

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 [http://www.bishopphillips.com/ www.bishopphillips.com].
</noinclude>

=Introduction=
Embedding agents into Scrum teams means integrating autonomous AI systems as bounded‑role collaborators that support backlog refinement, planning, development, testing, documentation, risk management, and flow optimisation while humans retain all strategic and ethical accountabilities. It is a mixture of both Agentic AI (AI coordinating and running other agents) and embedded AI Agents (humans coordinating and running specific AI Agents).

The obvious first step is that, at least in IT projects, the software developer or systems implementer roles become ''coordinators of a team of AI code‑writers'', but this is only one small slice of what embedding agents into Scrum teams really means.
What’s coming is far bigger:
''Scrum teams will evolve into hybrid human–AI systems, where agents participate in every Scrum event, every artifact, and every workflow — not as tools, but as '''team members with bounded autonomy'''.''

In this paper we explore this strategy and how to implement it.

=The Core Idea=
Embedding agents into Scrum teams means giving AI explicit roles, responsibilities, and boundaries inside the Scrum framework - without violating Scrum’s human‑centric accountabilities.

In this model:
* Humans still own the *accountabilities*.
* Agents take on *capabilities*.

This distinction is crucial. In the real world a human (manager) must own the risk and be accountable for the outcome of the team he or she manages. It is not acceptable for the manager to say "Ah, that mistake was one of the team members, so not my responsibility." He is responsible for the governance of the team and everything the team does because the manager:
* approve, re/defines and (possibly) selects the destination/ objective / strategy,
* selects the team & resources to deploy or how they are deployed,
* decides the training & skills the team requires to perform the work,
* inspires & motivates the team,
* prioritizes team activities,
* tunes & monitors performance (efficiency and effectiveness),
* owns the consequences of all these decisions made.

This is true whether the team is 100% human, a mixture of human and machine, or 100% AI. That is the manager's role.

What changes when we augment the human 'worker' team member with AI agents is that every human worker becomes a manager of a little automated workforce. Whereas before he or she just administered themselves and their own workload, now they are administering a team of separate AI minds to do that work at much higher speeds and depth than they could do before on their own.

The correct model going forward will be that every worker with agent augmentation will need the at least some of the skills of management that were previously reserved for those in human supervisory positions. Indeed, while it should be obvious that directing (prompting) the Agent is a required skill transported from the management layer to the worker, so also are the verification (testing) and monitoring skills - something that may need to be specifically trained and equipped into the humans agentic workflow.

With that shift in focus must come the recognition that, just as before, the human was responsible for his or her output, that does not change just because that output is now produced by a team of AI agents working for that human.

=The Agent Skill Master=

=1. Where Agents Fit Inside the Scrum Roles=

==A. Product Owner (PO)==
This role becomes AI‑Augmented, not AI‑Replaced. The PO remains human, but agents become a ''Product Owner’s staff''.

Agents can:
* Secretarial functions:
** Schedule meetings and draft/read team, customer, Project Manager and Steering Committee communications
** Book facilities
** Prepare reports and summaries
** Record meeting transcripts
** Liaise with customer, project manager and steering committee AI liaison agents
* Analyse customer behaviour
* Interpret customer feedback and update product backlog details and prepare supporting materials
* Undertake ad-hoc research
* Propose backlog items
* Draft acceptance criteria
* Estimate value and risk
* Simulate ROI scenarios
* Detect dependencies
* Monitor regulatory changes
* Suggest backlog ordering

The human PO:
* Makes decisions
* Sets priorities
* Owns value
* Ensures ethics, strategy, and context
* Agent Skill Master

This turns the PO into a ''strategic decision‑maker'', not a backlog administrator.

==B. Scrum Master==
The Scrum Master becomes an ''AI‑Enhanced Flow Coach'', but remains human. The agents fill the roles of ''secretary, flow analyst and impediment detector''.

Agents can:
* Secretarial functions:
** Schedule meetings and draft/read team and Project Manager communications
** Book facilities
** Prepare reports and summaries
** Record meeting transcripts
** Liaise with product owner, project manager and developer AI liaison agents
* Train staff in team processes and policies
* Monitor cycle time, WIP, throughput
* Detect bottlenecks
* Identify anti‑patterns (e.g., too much WIP, stalled PBIs)
* Suggest process improvements
* Analyse team sentiment (retrospective input)
* Monitor and flag risk events early

The human Scrum Master:
* Coaches
* Facilitates
* Inspires & protects the team
* Drives organisational change

The Scrum Master becomes a ''systems thinker'', supported by AI diagnostics and secretarial functions.

==C. Developers==
This is the biggest transformation as this sees the developer transform into a ''Human–AI Hybrid Delivery Team''. The previous two roles were already managerial functions, but this role is the one that transforms from a sole operator into a team manager.

Agents become:
* Secretarial functions:
** Schedule meetings and draft/read team and Scrum Master communications
** Book facilities
** Prepare reports and summaries
** Record meeting transcripts
** Liaise with user, scrum master and other developer AI liaison agents
* Skills trainer & and interactive help library
* Code generators
* Test writers
* Debuggers
* Documentation writers
* Refactoring assistants
* Architecture evaluators
* Security scanners
* Data analysts

Humans adopt the role of a senior dev:
* System designers
* Integrators
* Developer agent supervisor & debugging director
* Code Reviewer
* Decision‑makers
* Problem framers
* Ethical & standards overseers

Developers evolve into ''senior orchestrators of agentic work'' but with far more breadth. It is probable that the velocity metrics change under this model with higher story point throughput and greater complexity being able to be covered in the same Sprint as before. Team sizes should ideally stay approximately the same as before as this is a function of the human supervisor to staff ratio rather than the velocity to supervisor ratio.

=2. Where Agents Fit Inside Scrum Events=

==Sprint Planning==
Agents:
* Secretarial functions
** Schedule meetings and draft/read team communications
** Book facilities
** Prepare reports and summaries
** Record meeting transcripts
** Liaise with team AI liaison agents
* Propose Sprint Goal options
* Suggest PBIs based on value + capacity
* Estimate complexity
* Identify risks
* Generate initial task breakdowns

Humans:
* Choose the Sprint Goal
* Select PBIs
* Validate the plan

==Daily Scrum==
Agents:
* Secretarial functions
** Schedule meetings and draft/read team communications
** Book facilities
** Prepare reports and summaries
** Record meeting transcripts
** Liaise with team AI liaison agents
* Summarise progress
* Highlight blockers
* Predict whether the Sprint Goal is at risk
* Suggest adjustments

Humans:
* Decide what to do
* Coordinate
* Adapt the plan

==Sprint Review==
Agents:
* Secretarial functions
** Schedule meetings and draft/read team communications
** Book facilities
** Prepare reports and summaries
** Record meeting transcripts
** Liaise with team AI liaison agents
* Generate demo scripts
* Summarise metrics
* Analyse stakeholder feedback
* Propose backlog updates

Humans:
* Present the Increment
* Engage stakeholders
* Make decisions

==Sprint Retrospective==
Agents:
* Secretarial functions
** Schedule meetings and draft/read team communications
** Book facilities
** Prepare reports and summaries
** Record meeting transcripts
** Liaise with team AI liaison agents
* Analyse flow metrics
* Detect patterns in team behaviour
* Suggest improvements
* Identify systemic issues

Humans:
* Reflect
* Decide
* Commit to improvements

=3. Where Agents Fit Inside Scrum Artifacts=

==Product Backlog==
Agents maintain:
* PBI descriptions
* Acceptance criteria
* Estimates
* Dependencies
* Value scoring
* Risk scoring
* Refinement suggestions

The backlog becomes a **living, self‑maintaining system**.

==Sprint Backlog==
Agents:
* Break PBIs into tasks
* Estimate task effort
* Monitor task progress
* Update burndown automatically

Humans:
* Validate
* Adjust
* Execute

==Increment==
Agents:
* Generate code
* Test code
* Validate DoD compliance
* Produce documentation
* Perform static analysis

Humans:
* Review
* Integrate
* Approve

=4. The Boundaries (what agents must NOT do)=
To preserve Scrum’s integrity Agents must NOT:
* Make product decisions
* Prioritise the backlog autonomously
* Commit to Sprint Goals
* Approve increments
* Replace human accountability
* Override ethical or strategic judgement

Agents are ''capability providers'', not ''accountability holders''.

=5. The Deeper Transformation=
Under this model Scrum becomes a *coordination protocol* for humans + agents. Scrum’s structure of roles, events and artifacts becomes the ''coordination layer'' for a hybrid workforce.

Humans provide:
* judgement
* ethics
* creativity
* strategy
* context

Agents provide:
* speed
* analysis
* automation
* consistency
* continuous monitoring

This, I believe, is the future of Agile delivery.

=6. The new hybrid team model=

'''Human Team Members'''
* Product Owner
* Scrum Master
* Senior Developers / Solution Architects

'''Embedded Agents'''
* Backlog Agent
* Planning Agent
* Coding Agent
* Testing Agent
* Documentation Agent
* Risk Agent
* Flow Agent
* Compliance Agent

Each agent has:
* a defined scope
* a bounded autonomy level
* a human owner
* a clear interface

This is the **Agent‑Augmented Scrum Team**.

=Next Steps=
* Define the Agent Roles - formally (Backlog Agent, Flow Agent, Risk Agent, etc.)
* Design the Agent–Human interaction model
* Create a Scrum Team Operating Model with Agents
* Show how to build an AI‑augmented Definition of Done
* Show how to embed agents into Risk Management

<noinclude>
[[Category:Featured Article]]
[[Category:Management Science]]
[[Category:AI Responsive Management]]
{{BackLinks}}
</noinclude>

Agile Frameworks - Embedding Agentic AI into Scrum

2026-05-13T10:06:31Z

Bishopj: /* Next Steps */

==About The Author & The Article==
[[Jonathan Bishop]], Group Chairman, Bishop Phillips Consulting. [http://www.bishopphillips.com/]

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 [http://www.bishopphillips.com/ www.bishopphillips.com].
</noinclude>

=Introduction=
Embedding agents into Scrum teams means integrating autonomous AI systems as bounded‑role collaborators that support backlog refinement, planning, development, testing, documentation, risk management, and flow optimisation while humans retain all strategic and ethical accountabilities. It is a mixture of both Agentic AI (AI coordinating and running other agents) and embedded AI Agents (humans coordinating and running specific AI Agents).

The obvious first step is that, at least in IT projects, the software developer or systems implementer roles become ''coordinators of a team of AI code‑writers'', but this is only one small slice of what embedding agents into Scrum teams really means.
What’s coming is far bigger:
''Scrum teams will evolve into hybrid human–AI systems, where agents participate in every Scrum event, every artifact, and every workflow — not as tools, but as '''team members with bounded autonomy'''.''

In this paper we explore this strategy and how to implement it.

=The Core Idea=
Embedding agents into Scrum teams means giving AI explicit roles, responsibilities, and boundaries inside the Scrum framework - without violating Scrum’s human‑centric accountabilities.

In this model:
* Humans still own the *accountabilities*.
* Agents take on *capabilities*.

This distinction is crucial. In the real world a human (manager) must own the risk and be accountable for the outcome of the team he or she manages. It is not acceptable for the manager to say "Ah, that mistake was one of the team members, so not my responsibility." He is responsible for the governance of the team and everything the team does because the manager:
* approve, re/defines and (possibly) selects the destination/ objective / strategy,
* selects the team & resources to deploy or how they are deployed,
* decides the training & skills the team requires to perform the work,
* inspires & motivates the team,
* prioritizes team activities,
* tunes & monitors performance (efficiency and effectiveness),
* owns the consequences of all these decisions made.

This is true whether the team is 100% human, a mixture of human and machine, or 100% AI. That is the manager's role.

What changes when we augment the human 'worker' team member with AI agents is that every human worker becomes a manager of a little automated workforce. Whereas before he or she just administered themselves and their own workload, now they are administering a team of separate AI minds to do that work at much higher speeds and depth than they could do before on their own.

The correct model going forward will be that every worker with agent augmentation will need the at least some of the skills of management that were previously reserved for those in human supervisory positions. Indeed, while it should be obvious that directing (prompting) the Agent is a required skill transported from the management layer to the worker, so also are the verification (testing) and monitoring skills - something that may need to be specifically trained and equipped into the humans agentic workflow.

With that shift in focus must come the recognition that, just as before, the human was responsible for his or her output, that does not change just because that output is now produced by a team of AI agents working for that human.

=The Agent Skill Master=

=1. Where Agents Fit Inside the Scrum Roles=

==A. Product Owner (PO)==
This role becomes AI‑Augmented, not AI‑Replaced. The PO remains human, but agents become a ''Product Owner’s staff''.

Agents can:
* Secretarial functions:
** Schedule meetings and draft/read team, customer, Project Manager and Steering Committee communications
** Book facilities
** Prepare reports and summaries
** Record meeting transcripts
** Liaise with customer, project manager and steering committee AI liaison agents
* Analyse customer behaviour
* Interpret customer feedback and update product backlog details and prepare supporting materials
* Undertake ad-hoc research
* Propose backlog items
* Draft acceptance criteria
* Estimate value and risk
* Simulate ROI scenarios
* Detect dependencies
* Monitor regulatory changes
* Suggest backlog ordering

The human PO:
* Makes decisions
* Sets priorities
* Owns value
* Ensures ethics, strategy, and context
* Agent Skill Master

This turns the PO into a ''strategic decision‑maker'', not a backlog administrator.

==B. Scrum Master==
The Scrum Master becomes an ''AI‑Enhanced Flow Coach'', but remains human. The agents fill the roles of ''secretary, flow analyst and impediment detector''.

Agents can:
* Secretarial functions:
** Schedule meetings and draft/read team and Project Manager communications
** Book facilities
** Prepare reports and summaries
** Record meeting transcripts
** Liaise with product owner, project manager and developer AI liaison agents
* Train staff in team processes and policies
* Monitor cycle time, WIP, throughput
* Detect bottlenecks
* Identify anti‑patterns (e.g., too much WIP, stalled PBIs)
* Suggest process improvements
* Analyse team sentiment (retrospective input)
* Monitor and flag risk events early

The human Scrum Master:
* Coaches
* Facilitates
* Inspires & protects the team
* Drives organisational change

The Scrum Master becomes a ''systems thinker'', supported by AI diagnostics and secretarial functions.

==C. Developers==
This is the biggest transformation as this sees the developer transform into a ''Human–AI Hybrid Delivery Team''. The previous two roles were already managerial functions, but this role is the one that transforms from a sole operator into a team manager.

Agents become:
* Secretarial functions:
** Schedule meetings and draft/read team and Scrum Master communications
** Book facilities
** Prepare reports and summaries
** Record meeting transcripts
** Liaise with user, scrum master and other developer AI liaison agents
* Skills trainer & and interactive help library
* Code generators
* Test writers
* Debuggers
* Documentation writers
* Refactoring assistants
* Architecture evaluators
* Security scanners
* Data analysts

Humans adopt the role of a senior dev:
* System designers
* Integrators
* Developer agent supervisor & debugging director
* Code Reviewer
* Decision‑makers
* Problem framers
* Ethical & standards overseers

Developers evolve into ''senior orchestrators of agentic work'' but with far more breadth. It is probable that the velocity metrics change under this model with higher story point throughput and greater complexity being able to be covered in the same Sprint as before. Team sizes should ideally stay approximately the same as before as this is a function of the human supervisor to staff ratio rather than the velocity to supervisor ratio.

=2. Where Agents Fit Inside Scrum Events=

==Sprint Planning==
Agents:
* Secretarial functions
** Schedule meetings and draft/read team communications
** Book facilities
** Prepare reports and summaries
** Record meeting transcripts
** Liaise with team AI liaison agents
* Propose Sprint Goal options
* Suggest PBIs based on value + capacity
* Estimate complexity
* Identify risks
* Generate initial task breakdowns

Humans:
* Choose the Sprint Goal
* Select PBIs
* Validate the plan

==Daily Scrum==
Agents:
* Secretarial functions
** Schedule meetings and draft/read team communications
** Book facilities
** Prepare reports and summaries
** Record meeting transcripts
** Liaise with team AI liaison agents
* Summarise progress
* Highlight blockers
* Predict whether the Sprint Goal is at risk
* Suggest adjustments

Humans:
* Decide what to do
* Coordinate
* Adapt the plan

==Sprint Review==
Agents:
* Secretarial functions
** Schedule meetings and draft/read team communications
** Book facilities
** Prepare reports and summaries
** Record meeting transcripts
** Liaise with team AI liaison agents
* Generate demo scripts
* Summarise metrics
* Analyse stakeholder feedback
* Propose backlog updates

Humans:
* Present the Increment
* Engage stakeholders
* Make decisions

==Sprint Retrospective==
Agents:
* Secretarial functions
** Schedule meetings and draft/read team communications
** Book facilities
** Prepare reports and summaries
** Record meeting transcripts
** Liaise with team AI liaison agents
* Analyse flow metrics
* Detect patterns in team behaviour
* Suggest improvements
* Identify systemic issues

Humans:
* Reflect
* Decide
* Commit to improvements

=3. Where Agents Fit Inside Scrum Artifacts=

==Product Backlog==
Agents maintain:
* PBI descriptions
* Acceptance criteria
* Estimates
* Dependencies
* Value scoring
* Risk scoring
* Refinement suggestions

The backlog becomes a **living, self‑maintaining system**.

==Sprint Backlog==
Agents:
* Break PBIs into tasks
* Estimate task effort
* Monitor task progress
* Update burndown automatically

Humans:
* Validate
* Adjust
* Execute

==Increment==
Agents:
* Generate code
* Test code
* Validate DoD compliance
* Produce documentation
* Perform static analysis

Humans:
* Review
* Integrate
* Approve

=4. The Boundaries (what agents must NOT do)=
To preserve Scrum’s integrity Agents must NOT:
* Make product decisions
* Prioritise the backlog autonomously
* Commit to Sprint Goals
* Approve increments
* Replace human accountability
* Override ethical or strategic judgement

Agents are ''capability providers'', not ''accountability holders''.

=5. The Deeper Transformation=
Under this model Scrum becomes a *coordination protocol* for humans + agents. Scrum’s structure of roles, events and artifacts becomes the ''coordination layer'' for a hybrid workforce.

Humans provide:
* judgement
* ethics
* creativity
* strategy
* context

Agents provide:
* speed
* analysis
* automation
* consistency
* continuous monitoring

This, I believe, is the future of Agile delivery.

=6. The new hybrid team model=

'''Human Team Members'''
* Product Owner
* Scrum Master
* Senior Developers / Solution Architects

'''Embedded Agents'''
* Backlog Agent
* Planning Agent
* Coding Agent
* Testing Agent
* Documentation Agent
* Risk Agent
* Flow Agent
* Compliance Agent

Each agent has:
* a defined scope
* a bounded autonomy level
* a human owner
* a clear interface

This is the **Agent‑Augmented Scrum Team**.

=Next Steps=
* Define the **Agent Roles** formally (Backlog Agent, Flow Agent, Risk Agent, etc.)
* Design the **Agent–Human interaction model**
* Create a **Scrum Team Operating Model with Agents**
* Map this into **SAFe / Enterprise Agile**
* Show how to build an **AI‑augmented Definition of Done**
* Show how to embed agents into **RiskManagement**

<noinclude>
[[Category:Featured Article]]
[[Category:Management Science]]
[[Category:AI Responsive Management]]
{{BackLinks}}
</noinclude>

Agile Frameworks - Scrum

2026-05-13T10:05:50Z

Bishopj: /* Cover Product & Sprints */

<noinclude>
==About The Author & The Article==
[[Jonathan Bishop]], Group Chairman, Bishop Phillips Consulting. [http://www.bishopphillips.com/]

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 [http://www.bishopphillips.com/ www.bishopphillips.com].
</noinclude>

==Definition: What It Is & What It Isn't==
[[File:AgileScrumInProjectContext01.webp|frameless|right|500px|alt=Scrum in the context of the Project Management Ecosystem|Scrum in the context of the Project Management Eco-system]]
Scrum is a lightweight product development framework in the Agile philosophical epoch that aims to create 'adaptive solutions to complex problems'. It asserts that knowledge and hence value comes from shared experience (which requires transparency) and making decisions on what is observed while minimising waste and focussing on essentials. Minimising waste flows, in part, from discovering missteps as early as possible in the process (transparency again). Complexity is broken down into incremental steps (realised in 'sprints') that are time constrained (to force them to be small and keep investment low before course change is required). Ideally task steps should represent an evaluable endpoint - like a screen mock-up (perhaps without functionality) so ideas and endpoints can be incrementally refined. It adopts a project organisation structure that aims to realise these concepts within the structure itself as well as the product design.

There was a phrase there that is deliberately selected and easy to miss: Scrum is a 'product development framework'. It is NOT a project management method. It <i>is a component</i> of a project management method, but it omits a group of essential components required for a full project management solution in the 'real world'. It addresses a portion of project organisation that is often glossed over in project management approaches and it fundamentally re-orients the thinking of managing deliverables but it does not address all of what is required. Scrum deliberately avoids:
* budgets
* schedules
* resource allocation
* risk registers
* governance structures
* critical path analysis

These belong to:
* BPCPM
* PRINCE2
* SAFe
* organisational governance
* portfolio management

In fact Scrum implicitly assumes the project goal is defined, and the project is already staffed and resourced. Scrum's focus is on how teams deliver value, not how the organisation funds them.

The idea that Scrum means "we don't plan - we just iterate" is a dangerous anti-pattern. This is how projects blow up. Scrum reduces risk through empiricism, but it does not replace:
* risk identification
* mitigation planning
* dependency management
* financial oversight

We still need these.

===How Do We Approach these Omissions?===

====Handling Risk====
BPC's success in project management over three decades was predicated on the incorporation of active management of risk in projects. We cannot countenance a model that does not incorporate active risk management, so in this discussion we address that ommission directly.

In the guide below we have sewn into the Scrum components the responsibilities that are needed in a real-world project that are omitted from the Scrum guide and the published Scrum training materials. We have attempted to do this while preserving the focus and objectives of Scrum, so these adjustments are not a complete solution but reflective of what has to be done at the identified role levels to integrate the Scrum framework into a larger project management method.

====Steering Committees and Project managers====
Still omitted but essential are the roles of '''Executive Sponsor/Steering Committee''' and '''Project Manager'''.

The Steering Committee's roles include:
* Approves funding
* Sets overall budget envelope
* Makes investment decisions
* Decides whether to continue, pivot, or stop the product
* Project risk ownership & monitoring the risk register
* Reporting to executive & board on project status

The Project manager's roles include literally the ones listed above as omitted (and a few more):
* risk identification & monitoring & advising the steering committee
* steering committee liaison
* mitigation & continuity planning
* dependency management
* project resourcing & budgeting (advice to steering committee)
* financial oversight & reporting
* contract & contractor administration
* facilitating and oversight of:
** business, use-case & needs analysis
** acceptance & security testing
** rollout, documentation and user training

In a minimal project adopting Scrum as its delivery paradigm the role of Project Manager should be either separately resourced or collapsed into the Scrum Master role. We would advise against collapsing the Project Manager role into the Product Owner role as philosophically these two positions represent the buyer and the supplier and it is arguably better to retain the tension between these two roles in the interests of efficiency and accountability for deadlines and outcomes. In any-case the Scrum Master must be diligent in not confusing the two roles (project manager & scrum master) when performing Scrum Master functions as they are fundamentally different in objective. Scrum events must be preserved as exclusively 'Scrum Events' and not mixed up with project management activities or the scrum ethos will be corrupted. In this discussion we specifically do not merge the Project Management role into the Scrum as that would fundamentally distort the model. We only recognise that somewhere this role is still required - just not in Scrum itself.

==The Key Components of Scrum==
Scrum has ''three roles'', ''five events'', and ''three artifacts'' (with respective commitments) — a structure confirmed consistently across authoritative sources. These components form the '''''entire''''' Scrum framework; nothing more is defined in the Scrum Guide[https://deckary.com/blog/scrum-framework-guide][https://scrumguides.org/scrum-guide.html].

The foundational resource (artifact) from which all Scrum activity flows is the Product Backlog controlled by the Product Owner and representing his 'wish list' of things that need to be delivered by the project team. The Product Backlog is a list of Product Backlog Items (PBI's) or value outcomes for delivery and the purpose of the Scrum team is to realise value by clearing the Product Backlog of the items it contains - translating opportunity for value-add into realised value-add.

===PBI's Are Not Tasks===
In the Scrum model a project is broken down into a partially ordered set of Product Backlog Item's (PBI) which are 'outcome items' or 'value deliverables' (not quite tasks), which may have sequential dependencies and priorities (defined by 'value' or inter-dependency) as defined by the product owner. These 'value deliverables' start life in the 'product backlog' from which they are drawn into sprints via the 'sprint backlog' for breakout into tasks and implementation and ultimately residing in the 'increment' when they reach the 'definition of done'.

While seemingly 'task-like' a PBI (value deliverable) and task are different because it is a 'unit of outcome value' for which a number of 'units of work' (i.e. tasks and sub-tasks) may be required to realise.

An example may help clarify this concept: "Enhance login process with MFA" might be seen as a PBI (value outcome) and placed on the project backlog, and drawn into a sprint backlog, where it is then expanded into a set of tasks required to achieve that deliverable like: 'assess MFA options', 'update the login screen', 'liaise with telco provider to confirm access', 'acquire modem', 'install modem', 'get finance approval for telecom budget', 'build connection to the messaging API', 'update the audit trail logger', 'build & run unit tests', etc. The backlog item has the value-add, while the tasks are essential to achieve the item, they don't themselves carry the value add or an allocatable portion of that value. Now in this case, there might also end up being multiple approaches (email, SMS, authenticator app, etc.) each with different costs and therefore different value-add measures, which are identified in the course of the sprint (assuming they were missed in pre-planning). In that case the developers might pursue one (as/if specified) in the current sprint and log the alternative strategies for consideration on the project backlog by the product owner, who would then assign a value and a priority for scheduling to later sprints, or refer the entire family for clarification and selection by the product owner where no option had been pre-defined. Clearly in this case there are different operating costs and effectiveness measures in play which may or may not have been considered in the original ask and might need prioritisation now.

While I prefer 'Value Deliverable' as an alternative to PBI other alternative terms that are in common use (although none of these are really complete) include:
* User Story - Useful when work is user facing. Eg. 'As a user I want X so that Y'
* Feature - Good for larger value oriented items.
* Enhancement - Useful for improvements to existing functionality
* Bug/Defect - Obvious.
* Spike - For research or investment work
* Epic - A large body of work that must be split into multiple PBI's

Whatever name is adopted, the PBI must go onto the product backlog in the first instance and should reflect:
* value (not effort)
* outcome (not activity)
* what (not how)

===Scrum components===
Scrum consists of:

* 3 Roles
** Product Owner,
** Scrum Master,
** Developers
* 5 Events
** Sprint,
** Sprint Planning,
** Daily Scrum,
** Sprint Review,
** Sprint Retrospective
* 3 Artifacts
** Product Backlog,
** Sprint Backlog,
** Increment
* 3 Commitments tied to the artifacts
** Product Goal,
** Sprint Goal,
** Definition of Done

These elements enable transparency, inspection, and adaptation — the pillars of Scrum.

===The 3 Scrum Roles (Accountabilities)===

====1. Product Owner====
{| class="wikitable"
|+ Product Owner
|-
! Role !! Responsibilities
|-
| <div>
=====Accountability: product value=====
=====Characteristics:=====

* Represents the external (to the project) stakeholders
* Owns the <b>Product Backlog</b> and is responsible for:
** Defining and communicating the <b>Product Goal</b> (the value outcome rather than just a deliverable)
** The definition of the product that achieves that goal
** Defining and communicating the measurement and definition of product value to the team
** Prioritizing and refining tasks in the backlog based on value, strategy and sequential dependence
* Must have authority to make product decisions
* Should be a single person accountable for maximising product value, not a committee
</div>
||
<div>
=====Risk Responsibility:=====
Owns:
* Business risk (will the product of the project deliver the expected value)
* Market risks
* Stakeholder risks
* Value/ROI risks

=====Budget Responsibility:=====
* Prioritises work to maximise value within the budget
* Makes scope trade‑offs
* Communicates ROI
* May request more funding via the project manager or direct to the steering committee

But the PO does not hire people, set salaries, or allocate headcount.
</div>
|}

====2. Scrum Master====
{| class="wikitable"
|+ Scrum Master
|-
! Role !! Responsibility
|-
|
<div>
=====Accountability: Team Effectiveness=====
=====Characteristics:=====
* Acts as the team facilitator, teacher, coach, & mentor
** Ensures Scrum is understood and enacted by the team
** Coaches the team and organization as required
** Facilitate continuous goal focus & team self-management
* Project administration
** Removes impediments and escalates same to the product owner as required
** Facilitates Scrum events, in particular daily standup team meetings
** Inter-scrum collaboration on multi-scrum projects
** Ensures artifacts are created and updated
** Task board administration
* Project reporting and Liaison
** Preparation of status updates for product owner and stakeholders
** Communicating and interpreting product owner and stakeholder feedback to the team
* Assist the product owner with backlog prioritisation decisions
</div>
||
<div>
=====Risk Responsibility:=====
The Scrum Master is responsible for project process & implementation risks and owns:
* Process risks
* Impediments
* Organisational blockers
* Team dysfunction risks

=====Budget Responsibility=====
* Task budgets (usually time based)
* Sprint budget (usually time based)
</div>
|}

====3. Developers====
{| class="wikitable"
|+ Developers
|-
! Role !! Responsibilities
|-
|style="width: 50%"|
<div>
=====Accountability: Achieving Definition of Done=====
=====Characteristics:=====
* Build the Increment each Sprint
* Assist in planning the Sprint Backlog
* Undertake the work necessary to deliver the task assigned or selected.
* In an agentic AI augmented production the developer is responsible for prompting and managing the AI agents assembled to undertake the work and reviewing and tuning their output.
* Ensure work meets the **Definition of Done**

</div>
||
<div>
=====Risk Responsibility:=====
* Technical risks
* Architectural risks
* Quality risks
* Integration risks
* AI context drift minimisation
* AI delivery evaluation & testing framework

=====Budget Responsibility:=====
* Individual task budget hours
* AI token budget

</div>
|}

===The 5 Scrum Events===

====1. The Sprint (the container event)====
* Fixed timebox: one to four weeks
* Contains all other events
* Produces a **usable Increment**

====2. Sprint Planning====
* Defines the **Sprint Goal**
* Selects Product Backlog items for the Sprint
* Creates the Sprint Backlog plan

====3. Daily Scrum====
* 15‑minute daily inspection of progress
* Developers adjust the plan toward the Sprint Goal

====4. Sprint Review====
* Inspect the Increment with stakeholders
* Adapt the Product Backlog based on feedback
* Review risks and mitigation strategies

====5. Sprint Retrospective====
* Inspect team processes, tools, and collaboration
* Identify improvements for the next Sprint
* Review risks and mitigation strategies

===Implementing The Sprint===

[[File:AgileSprint01.webp|frame|alt=The Agile Sprint Events & Artifacts|The Agile Sprint Events & Artifacts]]
The Sprint is the atomic unit of progress measurement in Scrum and defines a period required to deliver an 'increment'. It is usually set to between one and four weeks with a specific 'sprint goal' to achieve. The goal should be a tangible outcome like a defined potentially releasable 'increment' of the system being developed. The scope and duration is timeboxed and cannot be altered after commencement.

Sprints should be aligned to the product vision, goals and priorities. At the completion of each sprint there is a review and retrospective stage to inspect and assess the success of the methods and approaches used in the sprint for opportunities for continuous learning and improvement.

A sprint is structured in five stages:
* '''Sprint Pre-Planning'''. This is not really a stage of the Sprint, but something that comes before all Sprints and perhaps each Sprint. This is the initial set-up stage where resources are collected, Backlogs are reviewed for completeness & prioritisation, risks are reassessed and ratings updated, story points a reviewed and affirmed or modified, perhaps resource availability is confirmed, etc.
* '''Sprint planning'''. A sprint goal is determined between the Scrum Master and the Product Owner in consultation with the Developers. Product backlog items are selected based on the sprint goal and added to the Sprint backlog.
* '''Implementation''' & '''Daily Scrum'''. The implementation phase is where the work gets done and it is marked by the daily scrum which is a 15 to 30 minute daily stand-up meeting during which the developer team:
** Coordinates resources as needed
** Identifies and (if possible resolves) impediments
** Seeks clarification
** Agrees immediate priorities and shares progress
During implementation PBI's and their tasks are pulled from the backlog and rolled into the ready & work-in-progress columns of the Kanboard while they are acted on by the developers, ultimately moving the tasks (and the parent PBI's) to the review stage and done stages.
* '''Sprint Review'''. Held at the completion of each sprint with all the stakeholders, the review inspects the increment the team is releasing, gathering stakeholder and testing feedback and updating the product backlog as required. The sprint review is focussed on the increment released rather than the effectiveness of the processes used to produce it.
* '''Sprint retrospective'''. Held after review at the end of sprint, the retrospective focusses on the processes of the sprint itself and is a continuous improvement function assessing what went well and what can be improved resulting in an improvement implementation strategy to be employed in the next sprint. The retrospective also reviews the project direction and tunes the product backlog if necessary to align the project with shifts in project requirements

===The 3 Scrum Artifacts (with Commitments)===

==== Overview====
Artifacts are the 'physical' documents produced by the process. There are two backlogs which are essentially ordered lists of 'work items' to be undertaken and the third artifact is increment being built. Each artifact has a linked 'commitment'. We will explore the backlogs in more detail below.

====The Commitments====
A commitment in Scrum is a guiding objective that gives each Scrum artifact a clear purpose and a measurable target. It ensures the team knows why the work exists and what success looks like.

Commitments in Scrum are about alignment, not guarantees.

A commitment in Scrum has a very specific meaning. It is not a promise to deliver a fixed scope, a contract or a guarantee of output. A commitment is a stabilising anchor attached to each artifact. It provides clarity, focus, and transparency — not pressure.

Scrum deliberately avoids the old project‑management meaning of “commitment.” A Scrum commitment is not:
* a deadline
* a fixed scope promise
* a contract
* a guarantee of output
* a personal pledge
* a performance metric

Scrum commitments are team‑level alignment tools, not pressure mechanisms. They exist to solve three problems:
<ol>
<li>''Lack of clarity''<br>
Teams often don’t know what they’re trying to achieve.
<li>''Lack of transparency''<br>
Stakeholders can’t see what “done” means.
<li>''Lack of focus''<br>
Teams get lost in tasks instead of outcomes.
</ol>

Perhaps a better term like alignment, objective or intent could have been chosen - then we wouldn't have had to spend so much time explaining what they aren't!

There are three commitments - one for each artifact:
<ol>
<li> '''Product Goal'''<br>
''Commitment for'': '''Product Backlog'''<br>
''Meaning'':
A long‑term objective for the product.
It gives direction and coherence to the entire backlog.

Think of it as the “north star.”

<li> '''Sprint Goal'''<br>
''Commitment for'': '''Sprint Backlog'''<br>
''Meaning'':
A single, unifying objective for the Sprint.
It explains why the selected work matters.

It is not a promise to finish every PBI — it’s a promise to pursue the Sprint Goal.

<li> '''Definition of Done (DoD)'''<br>
''Commitment for'': '''Increment'''<br>
''Meaning'':
A shared quality standard that every Increment must meet.
It ensures transparency and prevents “half‑done” work.

This is the only commitment that is truly binary:
Done or not done.

</ol>

====How PBI's Relate to Sprint Goals====
=====Why versus What=====
The PBI is the ''means'' by which the Sprint Goal is realised.

PBIs support the Sprint Goal — not the other way around.

Think of it like this:
* The '''Sprint Goal''' is the ''why''
* The '''PBI''' is the ''what''
* The '''Tasks''' are the ''how''

During Sprint Planning, the Scrum Team first answers:

''“Why is this Sprint valuable?”''

This becomes the Sprint Goal — the commitment for the Sprint Backlog. It is a single, coherent, unifying objective.

Once the Sprint Goal is defined, the team selects PBIs that:
* contribute directly to achieving the Sprint Goal
* can reasonably be completed within the Sprint
* form a coherent set of work

PBIs are chosen because they help achieve the Sprint Goal — not because they “fit the timebox.”

Only after PBIs are selected do developers break them into tasks.

So the hierarchy is:
Sprint Goal → PBIs → Tasks

This is the correct conceptual model and this structure gives the team:
* '''Focus''' - Everyone is working toward the same outcome.
* '''Flexibility''' - If a PBI turns out to be bigger than expected, the team can renegotiate scope as long as the Sprint Goal remains achievable.
* '''Coherence''' - The Sprint is not a bucket of unrelated work — it is a purposeful step toward the Product Goal.

The anti‑pattern to avoid:
“The Sprint Goal is to complete these 8 PBIs.”

This is not a Sprint Goal: That’s just a list.

''A Sprint Goal must describe an outcome, not a collection of items.''

=====An Example=====
'''Sprint Goal:'''
“Enable secure user authentication.”

'''PBIs selected:'''
* Add MFA to login
* Implement password reset flow
* Add audit logging for authentication events

'''Tasks (examples):'''
* Build MFA UI
* Integrate SMS provider
* Write unit tests
* Update database schema

Notice how the PBIs all support the Sprint Goal, and the tasks support the PBIs.

====What happens if PBIs change mid‑Sprint?====

Scrum Guide:

Scope may be renegotiated with the Product Owner as more is learned, without affecting the Sprint Goal.

This is the power of the model:
* PBIs can change
* Tasks can change

The Sprint Goal stays stable as the Sprint Goal is the anchor.

====The Artifacts====
====='''1. Product Backlog'''=====
* Ordered list of everything needed for the product by value
* Use story points to measure complexity
* Continuously refined
* ''Commitment'': '''Product Goal'''

======'''2. Sprint Backlog'''======
* Selected Product Backlog items for the Sprint
* Plan for delivering the Increment
* May be broken down into tasks (tied to each backlog item)
* ''Commitment'': '''Sprint Goal'''

======'''3. Increment'''======
* The sum of all completed work
* Must be usable and meet the 'Definition of Done'
* ''Commitment'': '''Definition of Done'''

====Backlog Items====

The Backlog, whether product or sprint is a list of backlog items (PBI's). PBI's items breakdown into tasks (usually in the sprint backlog), but they are intended to represent 'value outcomes' (the what) rather than just effort (the how - which is the domain of tasks). One backlog item might equal one task in the sprint backlog but it is generally better to break them down into at least three tasks - eg. setup, implement & test. Backlog items drive planning, forecasting and value delivery so they are a little more than the traditional kanban or task.

So what is recorded in a good PBI?

A good backlog item would contain:
{| class="wikitable"
|+ Backlog Items
|-
! No. !! Item !! Description
|-
| 1|| Title || A short, clear label that should communicate the essence at a glance.

<i>Example:
“Add MFA to login process”</i>
|-
| 2|| Description|| A concise explanation of the need, problem, or value. This is not a detailed spec — just enough context for conversation.

<i>Example:
“Users need stronger authentication to reduce account takeover risk.”</i>
|-
| 3|| Value / Purpose (the ‘Why’)|| Scrum Guide emphasises value above all. This is the most commonly missing field.

<i>Example:
“Improves security posture and meets compliance requirements.”</i>
|-
| 4 || Acceptance Criteria|| Clear, testable conditions that define “done.” This is literally the 'Definition of Done'. This is essential for transparency and forecasting.

<i>Example:
* MFA required on next login
* Supports SMS and authenticator apps
* Works on mobile and desktop
* Logged in audit trail
</i>
|-
| 5|| Size / Estimate|| Scrum uses estimation for forecasting, not commitment. Usually story-points or T‑shirt sizes.

<i>
Example:
5 points or Medium
</i>
|-
| 6|| Dependencies / Constraints|| Optional but extremely useful.
Helps avoid surprises during Sprint Planning.

<i>
Example:
“Depends on user profile service refactor.”
</i>
|-
| 7|| Priority / Ordering|| This is the Product Owner’s job.
The backlog is ordered, not “ranked” or “sorted.”

<i>
Example:
PBI #3 in the backlog.
</i>
|-
| 8|| Definition of Done alignment|| Every PBI must be deliverable to the DoD. This is field that would be populated in the Sprint Backlog (rather than in the Product Backlog - although it might be partially populated at that level). If it can’t meet the DoD, it must be split. There is DoD for the Sprint which should rollup the DoD's for the PBI's in the Sprint. Likewise individual Tasks will also have a DoD which (it could be argued) roll up to the PBI.
|-
| 9|| Business owner / stakeholder|| This is the person/group who will ultimately accept the deliverable. This should include contact details or link to a contact management system.
|-
| 10|| Mockups or attachments|| Guiding materials relating to design, presentation, behaviours, etc. This might be a link to the document management system.
|-
| 11|| Technical notes|| Technical configuration, or advisory documentation related to the deliverable.
|-
| 12|| Story Points|| This is a complexity measurement metric which is used to help identify how big the PBI is and hence how many PBI's can be done in a single sprint. It is discussed elsewhere in this paper.
|-
| 13|| Inherent Risk Rating|| The inherent risk rating is the combination of the likelihood and impact of the threats to the value realisation arising from the environment before mitigation strategies are implemented. This may be a value or a link to a risk management system where threats (risk events) and mitigations (controls) are defined in detail. Accurate formulation of this contributes significantly to the steering committee responding to risk events in a timely fashion. Failure to deliver on a PBI - which is rolled up from failure to complete Tasks the meet DoD is an automatic risk.
|-
| 14|| Residual Risk Rating || The residual risk is the rating AFTER mitigating strategies have been applied and current active risk events applied. Eg. If a risk event is active, its probability goes from likely/unlikely to certain resulting in the impact assessment becoming 100% of the estimated impact value, but reduced by the mitigating controls. This value should be continuously monitored by the Scrum Master / Product Owner and Project Manager and ultimately the Steering Committee.
|-
| 15|| Workflow State|| Product or Sprint workflow stage as appropriate. See discussion below.
|-
| 16|| Tasks|| This is the task list representing the break-put of the PBI in the Sprint Backlog. In the Product Backlog this value is usually empty except as populated during pre-planning. It is relevant to the Sprint Backlog where it should be populated. It may be a swimlane link in a Kanboard which contains the detailed tasks.
|-
| 17 || Custom Fields || Your project might need other fields to be tracked in the PBI, for example in a larger multi-sprint Epoc this field might contain links to Sprints or PBI's running in other Product Backlogs, or project managers or parent steering committees where multiple projects/managers/steering committees are active.
|}

====A Note on Task Cards====
While Remembering that Scrum does not cover task structuring or definitions, the practical reality is that in the Sprint the PBI is translated to Tasks and subtasks for implementation. So in the interests of completeness we will spare a word on the content of Task objects to help contrast the Task from the PBI.

When the PBI is broken down into tasks '''the task object (task card)''' -which may be implemented using a Kanboard, for example - would be created with additional fields more familiar to traditional project managers:
* subtasks
* detailed specifications
* effort hours
* start/end dates
* assigned developers
* workflow states beyond “in progress”

===PBI Workflow States===
====Introduction====
The Scrum guide defines no workflow states for PBIs — neither at the Product Backlog level nor inside a Sprint.

The Scrum Guide notes that:
* The Product Backlog is an ordered list of work.
* The Sprint Backlog is the Sprint Goal + selected PBIs + the plan.

The only official “states” Scrum cares about are:
* Done (meets the Definition of Done)
* Not Done (everything else)

Scrum intentionally avoids prescribing workflow states because they are context‑specific. So here we will define a set of measures that are generally workable. You should modify these as you see fit for your project management needs, but these are a good starting point.

You will need a workable set of states for efficient management and transparency and the larger or more complex the project, the more important the states will become. I see that there are two groups of workflows:
* Product Backlog Set
* Sprint Set

We will look at each in turn.

====Product (Backlog) Workflow (before & after the Sprint)====

{| class="wikitable"
|+ Product (Backlog) States
|-
! No. !! Label !! Description
|-
| 1.|| Idea / Proposed|| A raw concept, request, or need.
Not refined, not sized, not ready.
|-
| 2.|| Defined / Described|| The PBI has a clear description and value statement eg. Business case.
|-
| 3.|| Ready for Refinement|| The team can now discuss it meaningfully.
|-
| 4.|| Refined|| Acceptance criteria added, dependencies known, risks identified.
|-
| 5.|| Submitted to Steering Committee|| Meets the team’s Definition of Ready (DoR):
* clear
* valuable
* small enough
* testable
* estimated
|-
| 6.|| Ready for Sprint|| Steering Committee / Project Manager has accepted the proposal / business case & agreed to fund it. This is the state from which PBIs can be selected during Sprint Planning.
|-
| 7.|| Done|| PBI has completed the Sprint and meets the definition of done (and has been accepted by the client)
|}

====Sprint Workflow (during the Sprint)====

{| class="wikitable"
|+ Product Backlog States
|-
! No. !! Label !! Description
|-
| 1.|| Selected for Sprint<br>(Sprint Backlog)|| Chosen during Sprint Planning because they support the Sprint Goal.
|-
| 2.|| Ready|| Scrum Master is satisfied that Task / sub tasks have been mapped out, cross dependencies / blocks determined / non-human resources required are allocated / blockages cleared .
|-
| 3.|| In Progress|| Developers are actively working on the PBI (and its tasks).
|-
| 4.|| In Review / In Testing|| Work is completed but not yet meeting the Definition of Done.
This may include:
* peer review
* testing
* integration
* UX review
* security checks
|-
| 5.|| Done|| Meets the Definition of Done.
This is the only state Scrum formally recognises.
|}

===Story Points & the Roll in PBI Selection===

====Definition====
While 'Value' might be key metric for the Product Owner in determining priority of PBI's, the Story Points measure is a key metric for the Scrum Master and Developers in determining how much can be accomplished in each Sprint and thus the scope of the Sprint.

Story Points are a relative measure of complexity, uncertainty, and effort — a way for teams to compare work items to each other rather than guess exact durations:

* Complexity — how hard is this compared to other work
* Uncertainty — how much is unknown
* Effort — roughly how much work is involved

Teams usually use a Fibonacci scale:
1, 2, 3, 5, 8, 13…
''because complexity grows non‑linearly''.

Story points do not translate linearly into time: A 5‑point story is not “5 hours” — it’s “bigger than a 3, smaller than an 8.”, however for a stable team, or an experienced developer the numbers correlate loosely to a passage of time, so an individual developer thinks of story points as an internalised relative scale. If something he rates at 3 takes a couple of days, then something he rates as five will likely take in his mind 2 to 3 times longer. There is a directional correlation but not a direct relation.

====Why Use Story Points?====
Story Points are used in Scrum because of a belief by the conceivers that most people are bad at estimating time for projected work. Over the years many strategies have been employed in project management to estimate the probable time requirements for coding such as line counts, function point analysis, etc. All tend to do better with extensive statistical data to underpin the calculations in a predictable and stable code base, known languages, but reliability correlates most heavily with years of experience. The more dynamic the environment, the younger the code base, the more developers who have worked on it, the less experienced the coders, the newer the development environment: the less reliable are the time estimates.

When it comes to PBI's however, the problem is much greater as at the point a PBI is being estimated it doesn't even have a task breakdown - it is a value deliverable proposition, an objective - not a plan, and certainly not a coding effort commitment vector. At this point it is really only possible to estimate the probable complexity compared to other PBI's in the list.

The idea is that while you may not be easily able to estimate how long it will take to climb hill 'A' (particularly if all you have is a vague description), you can much more reliably estimate whether hill 'A' seems bigger/harder than hill 'B'.

At the point the PBI appears on the Product Backlog an hour estimate would likely introduce a false precision, leading to unfounded commitments, encourage micro-management and most importantly undermine empiricism. Remember the point of Agile is to literally be 'agile' and allow for rapid adjustments to plans and scopes based on learnings acquired during delivery.

====When Are Hour Estimates Appropriate?====

In Scrum hour estimates belong only in one place:

''Task breakdown inside the Sprint Backlog''

Once a PBI is selected for the sprint, developers may break it into tasks and estimate hours for their own planning, not for reporting.
<i>
Example:

PBI: “Add MFA to login” — 5 story points
Tasks:
- Add UI elements (3 hours)
- Integrate SMS provider (4 hours)
- Add audit logging (2 hours)
- Write tests (3 hours)
These hours are not tracked outside the team.
</i>

From a Project Manager's perspective, the project runs in Sprints of, say, 4 weeks with a team of N developers at a monthly cost of Y$ per Sprint. The team finds they can deliver X story points of output in that time period, so PBI's up to around X points can be allocated for each Sprint. On that basis the Project Manager can estimate the approximate cost of the PBI's in the Product Backlog at any given point.

===Why these components matter===
Scrum is intentionally minimal. The combination of:

* '''roles''' (clear accountability)
* '''events''' (regular inspection/adaptation)
* '''artifacts''' (transparency of work)

It creates an empirical system that allows teams to navigate complexity and deliver value iteratively.

==Measuring Performance in Scrum==
Scrum is an empirical framework, so it relies on multiple complementary metrics to give transparency into value, flow, quality, and predictability.

Scrum metrics should measure 4 buckets of data:
* Value (are we building the right thing?)
* Flow (how efficiently does work move?)
* Predictability (can we forecast?)
* Quality (is the product healthy?)

===1. Value Metrics (Most important)===

Scrum is about value, not output. These metrics tell you whether the team is building the right things.
<ol>
<li> Sprint Goal Success Rate
* How often the team achieves the Sprint Goal.
''Why: Measures focus, alignment, and value delivery.''
<br>
<br>
<li> Value Delivered per Sprint
Could be:
* business value points
* revenue impact
* risk reduction
* customer satisfaction
''Why: Shows whether the product is moving toward the Product Goal.''
<br>
<br>
<li> Customer / Stakeholder Satisfaction
* Surveys, NPS, feedback.
''Why: Scrum is customer‑centric.''
</ol>

===2. Flow Metrics (Kanban‑friendly and extremely useful)===
<ol>
These measure how efficiently work moves through the system:

<li> Cycle Time
* Time from “work started” → “work done.”
''Why: Predictability and bottleneck detection.''
<br>
<br>

<li> Lead Time
* Time from “requested” → “delivered.”
''Why: Measures responsiveness to stakeholders.''
<br>
<br>

<li> Work in Progress (WIP)
* How many PBIs are being worked on simultaneously.
''Why: High WIP = slow flow, context switching, delays.''
<br>
<br>

<li> Throughput
* Number of PBIs completed per Sprint.
''Why: Helps forecast delivery without story points.''
</ol>

===3. Predictability Metrics===
<ol>
These help you forecast future delivery.

<li> Velocity
* Story points completed per Sprint.
''Why: Helps forecast capacity, not performance.''

<li> Forecast Accuracy
* How close the team’s forecast was to actual delivery.
''Why: Measures planning realism.''

<li> Sprint Burndown / Burnup
* Shows progress toward the Sprint Goal.
''Why: Early detection of scope creep or blockers.''

<li> Release Burnup
* Tracks progress toward a larger Product Goal.
''Why: Helps stakeholders understand long‑term delivery.''
</ol>

===4. Quality Metrics===
<ol>
Scrum requires a high‑quality Increment every Sprint. These metrics measure quality:.

<li> Defect Rate / Escaped Defects
* Bugs found after release.
''Why: Indicates quality of the Increment.''

<li> Technical Debt Trend
* How much debt is accumulating or being paid down.
''Why: Predicts future slowdown.''

<li> Definition of Done Compliance
* How often PBIs meet the DoD without exceptions.
''Why: Ensures transparency and quality.''

<li> Code Quality Metrics
* Examples: test coverage, static analysis scores.
''Why: Supports sustainable development.''
</ol>

===Which metrics matter most?===
If you track only five, track these:
* Sprint Goal Success Rate
* Cycle Time
* Throughput
* Velocity (trend, not target)
* Defect Rate

These give you a complete picture of value, flow, predictability, and quality.

===What NOT to track for Scrum(anti‑patterns)===
These destroy agility:
* Hours worked
* Individual velocity
* Lines of code
* Number of tasks completed
* Story points as performance metrics
* “Commitment vs delivered” charts
* Utilisation (100% utilisation = slowest flow)

Scrum is about value, not busyness.

==Creating a Dashboard For Tracking Scrum Metrics==
A Scrum Dashboard would start with the 'purpose' and it should answer five questions:
* Are we delivering value?
* Are we improving flow?
* Are we predictable?
* Is quality improving or degrading?
* Are we moving toward the Product Goal?

Everything else is noise.

===Choose the right metrics (not too many)===
A good dashboard has 8–12 metrics, grouped by category.

* Value
** Sprint Goal Success Rate
** Value Delivered (business value points, risk reduction, etc.)
** Stakeholder Satisfaction (simple 1–5 score per Sprint)

* Flow
** Cycle Time (PBI start → Done)
** Lead Time (request → Done)
** Throughput (PBIs per Sprint)

* WIP (Work in Progress)
** Predictability
** Velocity (trend, not target)

* Forecast Accuracy
** Sprint Burnup
** Release Burnup

* Quality
** Defect Rate
** Escaped Defects
** Technical Debt Trend
** DoD Compliance

These give a complete picture without overwhelming you.

===Design the dashboard layout (Kanboard‑friendly)===
'''Top row: Value'''
* Sprint Goal Success (traffic light)
* Value Delivered (bar)
* Stakeholder Score (line)

'''Middle row: Flow'''
* Cycle Time (control chart)
* Throughput (bar)
* WIP (gauge)

'''Bottom row: Predictability + Quality'''
* Velocity (trend line)
* Forecast Accuracy (percentage)
* Defects (bar)
* DoD Compliance (gauge)
<br>
This layout mirrors how decisions are made:
Value → Flow → Predictability → Quality.

===Data sources (conceptually)===
You don’t need complex integrations. You can derive everything from:
* PBI timestamps (Created, Started, Done)
* Sprint boundaries
* PBI metadata (value, type, estimate)
* Defect logs
* Sprint Goal outcomes
* DoD checks

===How the dashboard actually works (the logic)===
'''Cycle Time'''
Cycle Time = Done Date − Start Date
'''Throughput'''
Count of PBIs Done per Sprint.
'''Velocity'''
Sum of story points Done per Sprint.
'''Forecast Accuracy'''
Accuracy = Delivered Points / Forecast Points
'''Sprint Goal Success'''
Binary: Achieved / Not Achieved.
'''Defect Rate'''
Number of defects created per Sprint.
'''DoD Compliance'''
PBIs meeting DoD / Total PBIs Done
'''Value Delivered'''
Sum of value points (or risk reduction score).

===The philosophy behind the dashboard===
A Scrum dashboard should:
* Reveal bottlenecks (flow metrics)
* Expose risks early (quality + predictability)
* Show whether we’re building the right thing (value metrics)
* Support empirical decision‑making

It should not be a management surveillance tool.

===Cover Product & Sprints===
Use a '''dual‑layer dashboard'''
* Sprint Dashboard (short‑term health)
* Product Dashboard (long‑term trajectory)

'''With these visualisations''':
* Control charts for cycle time
* Burnup charts for Sprint and Release
* Velocity trend line
* Defect trend line
* WIP gauge
* Value delivered bar chart
* Sprint Goal success indicator

'''And these integrations'''
* Pull PBI timestamps from the Kanboard (or tool used for tracking PBI / Task Kanbans)
* Use custom fields for value, risk, and DoD
* Auto‑calculate metrics at Sprint close
* Store historical metrics for trend analysis

This gives us a complete empirical control system for Scrum.

Next: [[Agile Frameworks - Embedding Agentic AI into Scrum]]
<noinclude>
[[Category:Featured Article]]
[[Category:Management Science]]
[[Category:AI Responsive Management]]
{{BackLinks}}
</noinclude>

Managing Agents: The Discipline of Human AI - Orchestration

2026-05-13T10:05:13Z

Bishopj: /* Next Steps */

Enterprise Agile Transformation

2026-05-13T10:04:34Z

Bishopj: /* Content of this Section */

Main Page

2026-05-13T10:02:29Z

Bishopj:

='''The BPC RiskWiki'''=
__NOTOC__

'''''SPONSORED BY:'''''

[[Image:BPCTitle75PERC.jpg]]

{|width="100%"
|-width="100%"
|
<table align=left style="background-color:#FFEBCD;margin-right:0.9em" cellpadding="2" cellspacing="1" >
<tr>
<td>
==Quick Index==

* [[Contents]]
*'''Articles about BPC Software Systems'''
** [[BPC RiskManager Software Suite|BPC RiskManager]]
** [[BPC SurveyManager - Overview|BPC SurveyManager]]
** [[BPC RiskManager Frequently Asked Questions]]
** [[Bishop Phillips - Software Library Reference for Developers]]
*'''Articles about Governance Function Business Methods'''
** [[Internal Audit]]
** [[Risk Management]]
** [[Managing Risk in Mergers & Acquisitions]]
*'''Articles about General Management Methods'''
** [[Business Process Reengineering]]
** [[Managing Agents: The Discipline of Human AI - Orchestration]]
** [[Enterprise Agile Transformation]]
** [[Agile Frameworks - Scrum]]
** [[Agile Frameworks - Embedding Agentic AI into Scrum]]
** [[Agile Frameworks - Enterprise Agile with Agentic AI]]
** [[Report Writing]]
*'''Articles about Virtual Worlds'''
** [[Virtual Learning Systems]]
*'''About The RiskWiki'''
** [[About The RiskWiki]]
** [[Contributors]]
</td>
</tr>
</table>

==Introduction to the RiskWiki==

This wiki is sponsored by Bishop Phillips Consulting (http://www.bishopphillips.com/) for the education, use and enjoyment of our clients, educators, the public and professionals involved in management consulting and risk advisory, compliance, internal audit, insurance claims management, safety, governance and risk analysis industries. It provides reference articles on management, risk and risk related functions including: Risk Management, Internal Audit, Governance, Compliance, and Process Reengineering, etc.

The RiskWiki is based on the articles, methods, manuals and papers of primarily three firms: Bishop Phillips Consulting P/L, Stanton Consulting Partners and Bishop Finance P/L. These firms are contributing a large body of work amassed over many years experience with hundreds of clients. The project to convert and upload much of our BPC software help & manuals, extended body of consulting, risk and internal audit methods and models, and education and research materials is a large and time consuming project so the RiskWiki content changes frequently and will do so for the foreseeable future.

With the exception of all software documentation, and those additional documents marked otherwise, all written material on this site may be used freely by readers for any purpose including reproduction, subject only to the retention of moral rights by the authors. Some articles may include images for which additional permission may be required prior to reproduction. Software documentation may be duplicated in hard-copy for internal use by registered users of the systems with current maintenance agreements. Other uses of software systems documentation will be considered on written request.

==Things to See in The RiskWiki==

===BPC RiskManager===

*'''''Are you looking for BPC RiskManager Documentation or to learn more about the software?'''''

<div class="imagewrap" style="float: left; margin-right:10px;" >[[image:BPC_RiskManager_V6261_Main_Screen.jpg|100px|link=BPC RiskManager Software Suite]]
</div>Bishop Phillips supplies [[BPC RiskManager Software Suite|the BPC RiskManagement suite of governance software]] that provides a complete governance solution across risk management, controls management, compliance management, insurance management, claims management, incident & hazard management, audit risk management, governance document management and survey generation and management. The system can be installed in configurations ranging from single-user to very large scale enterprise configurations.

The system is particularly suited to managing and reporting on the risk and compliance management tasks of government agencies, whole of government, special project, not-for-profits, insurance providers, service industries, utilities, and tertiary education sectors. You will find an extensive body of information covering [[BPC RiskManager Software Suite|technical, administration and user level tasks here]].

If you have questions they may be answered in our [[BPC RiskManager Frequently Asked Questions|frequently asked questions]].

<div class="mainfloatright" style="width:54%; max-width:70%; float:Right; overflow: auto; padding-left:10px; padding-right:10px;" >
{|align="left" width="100%"
|- style="background-color:#FFEBCD; padding-bottom:10px;" width="100%"
|[[BPC RiskManager Frequently Asked Questions|'''Frequently asked Questions About BPC RiskManger''']]
|-width="100%"
|
<div class="didyouknow2" STYLE="height: 400px;
border: thin solid black; display: block; overflow: auto; padding-left:10px; padding-top:20px; padding-bottom:20px; padding-right:10px;" >
{{#dpl: includepage=*
|includemaxlength=1000
|escapelinks=false
|resultsheader=__NOTOC__ __NOEDITSECTION__
|randomcount=1
|mode=userformat
|category=RiskManager FAQ
|addpagecounter=true
|listseparators=<H2>, [[%PAGE%]]</h2>\n,[[%PAGE%|Read More..]],\n
}}</div>
<div style="clear: both;">
</div>
|- style="background-color:#FFEBCD; width:100%;"
|'''Featured Article...'''
|-width="100%"
|
<div class="didyouknow2" STYLE="height: 400px; border: thin solid black; display: block; overflow: auto; padding-left:10px; padding-right:10px; padding-top:20px; padding-bottom:20px; " >
{{#dpl: includepage=*
|includemaxlength=4000
|escapelinks=false
|resultsheader=__NOTOC__ __NOEDITSECTION__
|randomcount=1
|mode=userformat
|category=Featured Article
|addpagecounter=true
|listseparators=<H2>, [[%PAGE%]]</h2>\n,[[%PAGE%| Read More..]],\n
}}
</div>
<div style="clear: both;">
</div>
|}
</div>

===BPC SurveyManager===

*'''''Are you looking for BPC SurveyManager Documentation or to learn more about the software?'''''

<div class="imagewrap" style="float: left; margin-right:10px;" >[[image:BPCSurveyManager_DTCV7_SurveyEdit_Screen.jpg|link=BPC SurveyManager - Overview|100px]]
</div>Bundled with the BPC RiskManager suite and also supplied in both hosted and installed forms, the BPC SurveyManager software solution is an outstandingly versatile interactive web page generation engine using a survey model as the design and data storage paradigm. While being outstanding at survey creation and management the software is powerful enough to build build conventional data-input web pages. The full [[BPC SurveyManager - Overview|technical and SM language programming documentation is available from here]].

===Research into Virtual Worlds in Business & Education===

*'''''Are you looking for our virtual Learning research papers?'''''

<div class="imagewrap" style="float: left; margin-right:10px;" >[[image:Second_Life_042.jpg|link=Virtual Learning Systems|100px]]
</div>Through our Virtual Worlds research group - "Waisman Learning Systems", we do extensive work in the development of virtual learning and business spaces in SecondLife, and undertake considerable formal research into the application of Virtual Worlds to learning. You will find technical and text book material in our [[Virtual Learning Systems|Virtual World Learning Systems pages]]. There is an extensive overview of the literature, and history of virtual worlds, a very large bibliography, details of our in-world networked lecture theatre control systems and lecture delivery systems, and a complete documentation of an extensive academic study undertaken by our WLS team into the effectiveness at achieving learning outcomes of different approaches in delivering course material in 3D virtual worlds.

You will find an extensive reading list and bibliography of works covering virtual worlds and virtual reality concepts, history, ideas, related technologies, and application in learning as well as relevant papers on learning taxonomies and teaching concepts relevant to [[VirtualWorldLearningReferences|virtual world learning systems here]].

===Internal Audit and Management Science===

*'''''Are you heading up an Internal Audit Team or learning internal audit methods?'''''

<div class="imagewrap" style="float: left; margin-right:10px;" >[[image:ALSBA.png|link=Internal Audit|100px]]
</div>If yes, you will find complete enterprise level internal audit methods and manuals on this site cross linked to our other management papers. The internal audit manuals cover everything from managing the audit team through planning the audit program to the detail of designing the audit, conducting interviews and undertaking the controls analysis; to reporting the results. Everything you are likely to need to [[Internal Audit|manage and train an internal audit team is here]].

*'''''Are you a manager, management consultant or student of Management Science?'''''

<div class="imagewrap" style="float: left; margin-right:10px;" >[[image:BPRAnalyticStructure.png|link=Category:Management Science|100px]]
</div>You will find articles covering topics of general management and process management methods in the RiskWiki including the detailed theory and practice of plannning, process re-engineering, control theory and our proven theories in stakeholder network organisation modelling. The work here is generally unique to this site. All methods have been used extensively and effectively in practice. Start here with [[Business Process Reengineering|process engineering]].

*'''''Are you managing a merger or an acquisition?'''''

<div class="imagewrap" style="float: left; margin-right:10px;" >[[Image:MnA_WhyMerge.jpg|link=Managing Risk in Mergers & Acquisitions|100px]]
</div>Take a look [[Managing Risk in Mergers & Acquisitions|here first and learn about the risks]] in mergers and acquisitions and successful strategies for managing them from our team who have been through it successfully from both sides or the equation multiple times.
|}

==Take A Random Look At The RiskWiki==

{|width="100%"
|- style="background-color:#FFEBCD;" width="100%"
|'''From the Vault of the BPC RiskWiki...'''
|-
|
<div class="didyouknow" width="100%" STYLE="height: 400px;
border: thin solid black; display: block; padding-left:10px; padding-right:10px; overflow: auto;" >
{{#dpl: namespace=
|includepage=*
|includemaxlength=1000
|escapelinks=false
|resultsheader=__NOTOC__ __NOEDITSECTION__
|randomcount=1
|mode=userformat
|addpagecounter=true
|listseparators=<H2>, [[%PAGE%]]</h2>\n,[[%PAGE%|Read More..]],\n
}}
</div>
<div style="clear: both;">
</div>
|}

Agile Frameworks - Enterprise Agile with Agentic AI

2026-05-13T10:01:01Z

Bishopj:

Agile Frameworks - Enterprise Agile with Agentic AI

2026-05-13T09:59:57Z

Bishopj: /* 6. The biggest shift: From “Agile ceremonies” to **AI‑driven continuous flow** */

=Introduction=

Enterprise Agile is an attempt to capture the perceived benefits experience in IT systems development of the Agile delivery framework and apply them to the Enterprise context across all areas, not just the IT space. These perceived benefits include alignment with business goals, value focus, lean operations, continuous improvement and market responsiveness. Enterprise Agile + Agentic AI is not just “Agile at scale.” It’s a fundamental shift in how work is orchestrated, how decisions are made, and how value flows across the enterprise.

This article considers Enterprise Agile and investigates ''how Agile evolve when the enterprise is augmented by autonomous agents, LLM‑powered workflows, and agentic AI ecosystems''

=1. What is Enterprise Agile?=
Enterprise Agile is not "Scrum but bigger." It is a ''multi‑team, multi‑value‑stream operating model'' that attempts to align:

* strategy
* funding
* architecture
* governance
* delivery
* operations

into a ''continuous flow of value'' and ''improvement'' across the entire organisation.

Frameworks like '''SAFe, LeSS, Nexus,''' and '''Disciplined Agile''' are simply different ways of achieving this, but none of them were designed with **agentic AI** in mind — which is why this article is timely.

=2. Why Agentic AI changes the game=

Agentic AI introduces capabilities that traditional Agile never anticipated:

* '''Secretarial support'''
The first agent most people implement is essentially a secretarial agent that scans emails and summarises for critical issues, arranges appointments, establishes reminders and assists with communication drafting. The significant productivity improvement offered by this capability alone at the individual level should not be underestimated as it means that every worker with a device has the opportunity to have an intelligent assistant addressing routine tasks that take potentially 12% to 20% of their time.

* '''Research & Training'''
Competing with the Secretarial function of AI is the librarian function of research and self-directed training & skilling that even an AI chat-bot delivers. Where a person's role involves skilling in processes, knowledge spaces or investigating, summarising or extracting data from either internal documentation or external data (including the web itself) an agent can represent a significant productivity and knowledge gain.

* '''Autonomous work execution'''
Agents can perform tasks, not just assist humans. Further through skill sharing AI's can educate each other, and humans can draft and test skills on one agent and then roll out those skills almost instantly across the entire organisation. Further agents can be equipped with skills to construct, test and use tools required but absent from their tool libraries to accomplish tasks defined by their human.

* '''Continuous sensing'''
Agents can monitor systems, markets, risks, and customer behaviour 24/7 and provide alerts based on complex threshold models or even enact responses.

* '''Real‑time decision support'''
Agents can propose backlog changes, risk mitigations, architectural options based on monitored sensors or user / customer feedback or environment changes. The lost in a report-awaiting-review syndrome evaporates where the agent can directly inject suggestions into the change management workflow for human consideration and approval.

* '''Cross‑team orchestration'''
Agents can coordinate dependencies across teams faster than humans as part of its secretarial role and detect and escalate blockages to either other agents or responsible humans instantly.

* '''Self‑optimising workflows'''
Agents can analyse flow metrics and propose process improvements.

These differences mean Enterprise Agile must evolve from '''''human‑centric coordination''''' to '''''human‑AI hybrid orchestration'''''.

=3. How SAFe fits into this=
SAFe is (possibly) the most widely adopted Enterprise Agile framework because it provides:

* Portfolio‑level governance
* Lean budgeting
* Value stream alignment
* Architectural runway
* Cross‑team synchronisation (ARTs)
* Cadence + flow
* Built‑in quality
* DevOps integration

On the face of it, these structures are '''perfect''' for integrating agentic AI because they already define:

* where decisions are made
* how value flows
* how teams coordinate
* how governance works

But SAFe needs to be extended to fully leverage AI.

=4. The Enterprise Agile model with Agentic AI=
Here’s the emerging opportunity pattern I see across advanced organisations:

==A. Portfolio Level (Strategy + Funding)==

AI‑enabled capabilities:
* Agents analyse market signals and propose new epics
* Agents forecast ROI and risk
* Agents simulate portfolio scenarios
* Agents monitor compliance and regulatory changes

Human role:
* Make strategic decisions
* Validate & augment AI‑generated insights
* Set ethical and governance boundaries

==B. Value Stream Level (Flow of Value)==

AI‑enabled capabilities:
* Agents map value streams automatically
* Agents detect bottlenecks in real time
* Agents propose WIP limits and flow optimisations
* Agents coordinate cross‑team dependencies

Human role:
* Approve structural changes
* Manage organisational constraints
* Provide context AI cannot infer

==C. ART / Program Level (Multi‑team coordination)==

AI‑enabled capabilities:
* Agents generate draft PI plans
* Agents identify risks across teams
* Agents propose backlog ordering
* Agents run simulations of capacity, load, and dependencies

Human role:
* Validate plans
* Resolve conflicts
* Make trade‑off decisions

==D. Team Level (Scrum / Kanban)==

AI‑enabled capabilities:
* Agents refine PBIs
* Agents write acceptance criteria
* Agents generate tests
* Agents perform code reviews
* Agents update documentation
* Agents monitor quality metrics

Human role:
* Make product decisions
* Ensure alignment with Sprint Goal
* Provide creativity, judgement, and domain expertise

=5. The new Enterprise Agile roles (AI‑augmented)=

'''AI‑Augmented Product Owner'''
* Uses agents to refine backlog
* Uses AI to analyse value, risk, and dependencies
* Focuses on strategic decisions, not admin work

'''AI‑Augmented Scrum Master / Flow Coach'''
* Uses agents to detect impediments
* Uses AI to analyse flow metrics
* Focuses on team health and organisational change

'''AI‑Augmented Architect'''
* Uses agents to evaluate design options
* Uses AI to detect technical debt
* Focuses on long‑term coherence

'''AI‑Augmented Developer'''
* Uses agents for coding, testing, debugging, and outside the coding space for product design, simulation, market testing design and coordination, process design, and documentation and training material construction.
* Focuses on system‑level thinking and creative problem‑solving

=6. The biggest shift: From "Agile ceremonies" to "AI‑driven continuous flow"=

Traditional Agile relies on:

* meetings
* human coordination
* manual backlog refinement
* manual risk management
* manual dependency tracking

Agentic AI replaces or augments much of this. Indeed one criticism of Scrum style agile implementations is the heavy reliance on meetings as a coordination and synchronisation strategy. Agentic AI offers an opportunity to completely rethink this part of Agile design and insert intelligent agents into that coordination space, while simultaneously equipping each human with their own team of 'staff members' to deliver the outputs.

The enterprise shifts from:

* ''Cadence'' → '''Continuous'''
* ''Manual'' → '''Autonomous'''
* ''Reactive'' → '''Predictive'''
* ''Human‑only'' → '''Human‑AI hybrid'''

This is the future of Enterprise Agile.

=7. Is SAFe the right model for the Agentic-AI Enterprise?=
SAFe is a ''good starting point'', but not the end state.

I believe the future looks more like:

* Lean Portfolio Management
* AI‑augmented value streams
* Autonomous agents embedded in every team
* Continuous planning instead of PI Planning
* AI‑driven governance and compliance
* Self‑optimising flow systems

We could approach this question by thinking of SAFe as the ''scaffolding'' while Agentic AI becomes the ''engine''. Is it still SAFe under this model? That is a fair question. While I can see Scrum being cleanly augmented by Agentic AI (as we have detailed in another article in this series), whether the incorporation of Agentic AI preserves enough of SAFe for it to be recognisably the same model is reasonably debatable. What is arguable at this stage is that SAFe can be a stepping stone to a new agentic organisational model, by first implementing SAFe and then replacing key components with Agentic AI solutions.

=Next Steps=
- How SAFe specifically integrates AI at each level
- How to design an **AI‑augmented Agile Operating Model**
- How to embed agents into Scrum teams
- How to redesign governance for AI‑enabled enterprises
- How to build an **AI‑driven Portfolio Kanban**
- How to architect a **secure, on‑prem agentic AI platform** for government‑grade environments (aligns with your earlier interests)

Agile Frameworks - Enterprise Agile with Agentic AI

2026-05-13T09:58:20Z

Bishopj:

=Introduction=

Enterprise Agile is an attempt to capture the perceived benefits experience in IT systems development of the Agile delivery framework and apply them to the Enterprise context across all areas, not just the IT space. These perceived benefits include alignment with business goals, value focus, lean operations, continuous improvement and market responsiveness. Enterprise Agile + Agentic AI is not just “Agile at scale.” It’s a fundamental shift in how work is orchestrated, how decisions are made, and how value flows across the enterprise.

This article considers Enterprise Agile and investigates ''how Agile evolve when the enterprise is augmented by autonomous agents, LLM‑powered workflows, and agentic AI ecosystems''

=1. What is Enterprise Agile?=
Enterprise Agile is not "Scrum but bigger." It is a ''multi‑team, multi‑value‑stream operating model'' that attempts to align:

* strategy
* funding
* architecture
* governance
* delivery
* operations

into a ''continuous flow of value'' and ''improvement'' across the entire organisation.

Frameworks like '''SAFe, LeSS, Nexus,''' and '''Disciplined Agile''' are simply different ways of achieving this, but none of them were designed with **agentic AI** in mind — which is why this article is timely.

=2. Why Agentic AI changes the game=

Agentic AI introduces capabilities that traditional Agile never anticipated:

* '''Secretarial support'''
The first agent most people implement is essentially a secretarial agent that scans emails and summarises for critical issues, arranges appointments, establishes reminders and assists with communication drafting. The significant productivity improvement offered by this capability alone at the individual level should not be underestimated as it means that every worker with a device has the opportunity to have an intelligent assistant addressing routine tasks that take potentially 12% to 20% of their time.

* '''Research & Training'''
Competing with the Secretarial function of AI is the librarian function of research and self-directed training & skilling that even an AI chat-bot delivers. Where a person's role involves skilling in processes, knowledge spaces or investigating, summarising or extracting data from either internal documentation or external data (including the web itself) an agent can represent a significant productivity and knowledge gain.

* '''Autonomous work execution'''
Agents can perform tasks, not just assist humans. Further through skill sharing AI's can educate each other, and humans can draft and test skills on one agent and then roll out those skills almost instantly across the entire organisation. Further agents can be equipped with skills to construct, test and use tools required but absent from their tool libraries to accomplish tasks defined by their human.

* '''Continuous sensing'''
Agents can monitor systems, markets, risks, and customer behaviour 24/7 and provide alerts based on complex threshold models or even enact responses.

* '''Real‑time decision support'''
Agents can propose backlog changes, risk mitigations, architectural options based on monitored sensors or user / customer feedback or environment changes. The lost in a report-awaiting-review syndrome evaporates where the agent can directly inject suggestions into the change management workflow for human consideration and approval.

* '''Cross‑team orchestration'''
Agents can coordinate dependencies across teams faster than humans as part of its secretarial role and detect and escalate blockages to either other agents or responsible humans instantly.

* '''Self‑optimising workflows'''
Agents can analyse flow metrics and propose process improvements.

These differences mean Enterprise Agile must evolve from '''''human‑centric coordination''''' to '''''human‑AI hybrid orchestration'''''.

=3. How SAFe fits into this=
SAFe is (possibly) the most widely adopted Enterprise Agile framework because it provides:

* Portfolio‑level governance
* Lean budgeting
* Value stream alignment
* Architectural runway
* Cross‑team synchronisation (ARTs)
* Cadence + flow
* Built‑in quality
* DevOps integration

On the face of it, these structures are '''perfect''' for integrating agentic AI because they already define:

* where decisions are made
* how value flows
* how teams coordinate
* how governance works

But SAFe needs to be extended to fully leverage AI.

=4. The Enterprise Agile model with Agentic AI=
Here’s the emerging opportunity pattern I see across advanced organisations:

==A. Portfolio Level (Strategy + Funding)==

AI‑enabled capabilities:
* Agents analyse market signals and propose new epics
* Agents forecast ROI and risk
* Agents simulate portfolio scenarios
* Agents monitor compliance and regulatory changes

Human role:
* Make strategic decisions
* Validate & augment AI‑generated insights
* Set ethical and governance boundaries

==B. Value Stream Level (Flow of Value)==

AI‑enabled capabilities:
* Agents map value streams automatically
* Agents detect bottlenecks in real time
* Agents propose WIP limits and flow optimisations
* Agents coordinate cross‑team dependencies

Human role:
* Approve structural changes
* Manage organisational constraints
* Provide context AI cannot infer

==C. ART / Program Level (Multi‑team coordination)==

AI‑enabled capabilities:
* Agents generate draft PI plans
* Agents identify risks across teams
* Agents propose backlog ordering
* Agents run simulations of capacity, load, and dependencies

Human role:
* Validate plans
* Resolve conflicts
* Make trade‑off decisions

==D. Team Level (Scrum / Kanban)==

AI‑enabled capabilities:
* Agents refine PBIs
* Agents write acceptance criteria
* Agents generate tests
* Agents perform code reviews
* Agents update documentation
* Agents monitor quality metrics

Human role:
* Make product decisions
* Ensure alignment with Sprint Goal
* Provide creativity, judgement, and domain expertise

=5. The new Enterprise Agile roles (AI‑augmented)=

'''AI‑Augmented Product Owner'''
* Uses agents to refine backlog
* Uses AI to analyse value, risk, and dependencies
* Focuses on strategic decisions, not admin work

'''AI‑Augmented Scrum Master / Flow Coach'''
* Uses agents to detect impediments
* Uses AI to analyse flow metrics
* Focuses on team health and organisational change

'''AI‑Augmented Architect'''
* Uses agents to evaluate design options
* Uses AI to detect technical debt
* Focuses on long‑term coherence

'''AI‑Augmented Developer'''
* Uses agents for coding, testing, debugging, and outside the coding space for product design, simulation, market testing design and coordination, process design, and documentation and training material construction.
* Focuses on system‑level thinking and creative problem‑solving

=6. The biggest shift: From “Agile ceremonies” to **AI‑driven continuous flow**=

Traditional Agile relies on:

* meetings
* human coordination
* manual backlog refinement
* manual risk management
* manual dependency tracking

Agentic AI replaces or augments much of this. Indeed one criticism of Scrum style agile implementations is the heavy reliance on meetings as a coordination and synchronisation strategy. Agentic AI offers an opportunity to completely rethink this part of Agile design and insert intelligent agents into that coordination space, while simultaneously equipping each human with their own team of 'staff members' to deliver the outputs.

The enterprise shifts from:

* ''Cadence'' → '''Continuous'''
* ''Manual'' → '''Autonomous'''
* ''Reactive'' → '''Predictive'''
* ''Human‑only'' → '''Human‑AI hybrid'''

This is the future of Enterprise Agile.

=7. Is SAFe the right model for the Agentic-AI Enterprise?=
SAFe is a ''good starting point'', but not the end state.

I believe the future looks more like:

* Lean Portfolio Management
* AI‑augmented value streams
* Autonomous agents embedded in every team
* Continuous planning instead of PI Planning
* AI‑driven governance and compliance
* Self‑optimising flow systems

We could approach this question by thinking of SAFe as the ''scaffolding'' while Agentic AI becomes the ''engine''. Is it still SAFe under this model? That is a fair question. While I can see Scrum being cleanly augmented by Agentic AI (as we have detailed in another article in this series), whether the incorporation of Agentic AI preserves enough of SAFe for it to be recognisably the same model is reasonably debatable. What is arguable at this stage is that SAFe can be a stepping stone to a new agentic organisational model, by first implementing SAFe and then replacing key components with Agentic AI solutions.

=Next Steps=
- How SAFe specifically integrates AI at each level
- How to design an **AI‑augmented Agile Operating Model**
- How to embed agents into Scrum teams
- How to redesign governance for AI‑enabled enterprises
- How to build an **AI‑driven Portfolio Kanban**
- How to architect a **secure, on‑prem agentic AI platform** for government‑grade environments (aligns with your earlier interests)

Agile Frameworks - Enterprise Agile with Agentic AI

2026-05-13T07:02:33Z

Bishopj: Created page with "**Enterprise Agile + Agentic AI** is not just “Agile at scale.” It’s a **fundamental shift in how work is orchestrated**, how decisions are made, and how value flows across the enterprise. **SAFe is one of the major Enterprise Agile frameworks**, but it’s only one expression of a broader movement. What you’re really asking is: > *How does Agile evolve when the enterprise is augmented by autonomous agents, LLM‑powered workflows, and agentic AI ecosystems?*..."

**Enterprise Agile + Agentic AI** is not just “Agile at scale.” It’s a **fundamental shift in how work is orchestrated**, how decisions are made, and how value flows across the enterprise.

**SAFe is one of the major Enterprise Agile frameworks**, but it’s only one expression of a broader movement.
What you’re really asking is:

> *How does Agile evolve when the enterprise is augmented by autonomous agents, LLM‑powered workflows, and agentic AI ecosystems?*

Let’s build this out properly.

---

# 🧭 1. What Enterprise Agile *actually* is
Enterprise Agile is not “Scrum but bigger.”
It is a **multi‑team, multi‑value‑stream operating model** that aligns:

- strategy
- funding
- architecture
- governance
- delivery
- operations

…into a **continuous flow of value** across the entire organisation.

Frameworks like SAFe, LeSS, Nexus, and Disciplined Agile are simply different ways of achieving this.

But none of them were designed with **agentic AI** in mind — which is why your question is so timely.

---

# 🧩 2. Why Agentic AI changes the game
Agentic AI introduces capabilities that traditional Agile never anticipated:

### **Autonomous work execution**
Agents can perform tasks, not just assist humans.

### **Continuous sensing**
Agents can monitor systems, markets, risks, and customer behaviour 24/7.

### **Real‑time decision support**
Agents can propose backlog changes, risk mitigations, architectural options.

### **Cross‑team orchestration**
Agents can coordinate dependencies across teams faster than humans.

### **Self‑optimising workflows**
Agents can analyse flow metrics and propose process improvements.

This means Enterprise Agile must evolve from **human‑centric coordination** to **human‑AI hybrid orchestration**.

---

# 🧱 3. How SAFe fits into this
SAFe is the most widely adopted Enterprise Agile framework because it provides:

- **Portfolio‑level governance**
- **Lean budgeting**
- **Value stream alignment**
- **Architectural runway**
- **Cross‑team synchronisation (ARTs)**
- **Cadence + flow**
- **Built‑in quality**
- **DevOps integration**

These structures are *perfect* for integrating agentic AI because they already define:

- where decisions are made
- how value flows
- how teams coordinate
- how governance works

But SAFe needs to be **extended** to fully leverage AI.

---

# 🧠 4. The Enterprise Agile model *with* Agentic AI
Here’s the emerging pattern I see across advanced organisations:

---

## **A. Portfolio Level (Strategy + Funding)**
### AI‑enabled capabilities:
- Agents analyse market signals and propose new epics
- Agents forecast ROI and risk
- Agents simulate portfolio scenarios
- Agents monitor compliance and regulatory changes

### Human role:
- Make strategic decisions
- Validate AI‑generated insights
- Set ethical and governance boundaries

---

## **B. Value Stream Level (Flow of Value)**
### AI‑enabled capabilities:
- Agents map value streams automatically
- Agents detect bottlenecks in real time
- Agents propose WIP limits and flow optimisations
- Agents coordinate cross‑team dependencies

### Human role:
- Approve structural changes
- Manage organisational constraints
- Provide context AI cannot infer

---

## **C. ART / Program Level (Multi‑team coordination)**
### AI‑enabled capabilities:
- Agents generate draft PI plans
- Agents identify risks across teams
- Agents propose backlog ordering
- Agents run simulations of capacity, load, and dependencies

### Human role:
- Validate plans
- Resolve conflicts
- Make trade‑off decisions

---

## **D. Team Level (Scrum / Kanban)**
### AI‑enabled capabilities:
- Agents refine PBIs
- Agents write acceptance criteria
- Agents generate tests
- Agents perform code reviews
- Agents update documentation
- Agents monitor quality metrics

### Human role:
- Make product decisions
- Ensure alignment with Sprint Goal
- Provide creativity, judgement, and domain expertise

---

# 🧩 5. The new Enterprise Agile roles (AI‑augmented)

### **AI‑Augmented Product Owner**
- Uses agents to refine backlog
- Uses AI to analyse value, risk, and dependencies
- Focuses on strategic decisions, not admin work

### **AI‑Augmented Scrum Master / Flow Coach**
- Uses agents to detect impediments
- Uses AI to analyse flow metrics
- Focuses on team health and organisational change

### **AI‑Augmented Architect**
- Uses agents to evaluate design options
- Uses AI to detect technical debt
- Focuses on long‑term coherence

### **AI‑Augmented Developer**
- Uses agents for coding, testing, debugging
- Focuses on system‑level thinking and creative problem‑solving

---

# 🧨 6. The biggest shift: From “Agile ceremonies” to **AI‑driven continuous flow**
Traditional Agile relies on:

- meetings
- human coordination
- manual backlog refinement
- manual risk management
- manual dependency tracking

Agentic AI replaces or augments much of this.

The enterprise shifts from:

**Cadence → Continuous**
**Manual → Autonomous**
**Reactive → Predictive**
**Human‑only → Human‑AI hybrid**

This is the future of Enterprise Agile.

---

# 🧭 7. So is SAFe the right model?
SAFe is a **good starting point**, but not the end state.

The future looks more like:

- **Lean Portfolio Management**
- **AI‑augmented value streams**
- **Autonomous agents embedded in every team**
- **Continuous planning instead of PI Planning**
- **AI‑driven governance and compliance**
- **Self‑optimising flow systems**

Think of SAFe as the **scaffolding**.
Agentic AI becomes the **engine**.

---

Next Steps
- How SAFe specifically integrates AI at each level
- How to design an **AI‑augmented Agile Operating Model**
- How to embed agents into Scrum teams
- How to redesign governance for AI‑enabled enterprises
- How to build an **AI‑driven Portfolio Kanban**
- How to architect a **secure, on‑prem agentic AI platform** for government‑grade environments (aligns with your earlier interests)

Enterprise Agile Transformation

2026-05-13T06:59:03Z

Bishopj: /* Content of this Section */

Main Page

2026-05-13T06:55:47Z

Bishopj:

='''The BPC RiskWiki'''=
__NOTOC__

'''''SPONSORED BY:'''''

[[Image:BPCTitle75PERC.jpg]]

{|width="100%"
|-width="100%"
|
<table align=left style="background-color:#FFEBCD;margin-right:0.9em" cellpadding="2" cellspacing="1" >
<tr>
<td>
==Quick Index==

* [[Contents]]
*'''Articles about BPC Software Systems'''
** [[BPC RiskManager Software Suite|BPC RiskManager]]
** [[BPC SurveyManager - Overview|BPC SurveyManager]]
** [[BPC RiskManager Frequently Asked Questions]]
** [[Bishop Phillips - Software Library Reference for Developers]]
*'''Articles about Governance Function Business Methods'''
** [[Internal Audit]]
** [[Risk Management]]
** [[Managing Risk in Mergers & Acquisitions]]
*'''Articles about General Management Methods'''
** [[Business Process Reengineering]]
** [[Managing Agents: The Discipline of Human AI - Orchestration]]
** [[Enterprise Agile Transformation]]
** [[Agile Frameworks - Scrum]]
** [[Agile Frameworks - Embedding Agentic AI into Scrum]]
** [[Report Writing]]
*'''Articles about Virtual Worlds'''
** [[Virtual Learning Systems]]
*'''About The RiskWiki'''
** [[About The RiskWiki]]
** [[Contributors]]
</td>
</tr>
</table>

==Introduction to the RiskWiki==

This wiki is sponsored by Bishop Phillips Consulting (http://www.bishopphillips.com/) for the education, use and enjoyment of our clients, educators, the public and professionals involved in management consulting and risk advisory, compliance, internal audit, insurance claims management, safety, governance and risk analysis industries. It provides reference articles on management, risk and risk related functions including: Risk Management, Internal Audit, Governance, Compliance, and Process Reengineering, etc.

The RiskWiki is based on the articles, methods, manuals and papers of primarily three firms: Bishop Phillips Consulting P/L, Stanton Consulting Partners and Bishop Finance P/L. These firms are contributing a large body of work amassed over many years experience with hundreds of clients. The project to convert and upload much of our BPC software help & manuals, extended body of consulting, risk and internal audit methods and models, and education and research materials is a large and time consuming project so the RiskWiki content changes frequently and will do so for the foreseeable future.

With the exception of all software documentation, and those additional documents marked otherwise, all written material on this site may be used freely by readers for any purpose including reproduction, subject only to the retention of moral rights by the authors. Some articles may include images for which additional permission may be required prior to reproduction. Software documentation may be duplicated in hard-copy for internal use by registered users of the systems with current maintenance agreements. Other uses of software systems documentation will be considered on written request.

==Things to See in The RiskWiki==

===BPC RiskManager===

*'''''Are you looking for BPC RiskManager Documentation or to learn more about the software?'''''

<div class="imagewrap" style="float: left; margin-right:10px;" >[[image:BPC_RiskManager_V6261_Main_Screen.jpg|100px|link=BPC RiskManager Software Suite]]
</div>Bishop Phillips supplies [[BPC RiskManager Software Suite|the BPC RiskManagement suite of governance software]] that provides a complete governance solution across risk management, controls management, compliance management, insurance management, claims management, incident & hazard management, audit risk management, governance document management and survey generation and management. The system can be installed in configurations ranging from single-user to very large scale enterprise configurations.

The system is particularly suited to managing and reporting on the risk and compliance management tasks of government agencies, whole of government, special project, not-for-profits, insurance providers, service industries, utilities, and tertiary education sectors. You will find an extensive body of information covering [[BPC RiskManager Software Suite|technical, administration and user level tasks here]].

If you have questions they may be answered in our [[BPC RiskManager Frequently Asked Questions|frequently asked questions]].

<div class="mainfloatright" style="width:54%; max-width:70%; float:Right; overflow: auto; padding-left:10px; padding-right:10px;" >
{|align="left" width="100%"
|- style="background-color:#FFEBCD; padding-bottom:10px;" width="100%"
|[[BPC RiskManager Frequently Asked Questions|'''Frequently asked Questions About BPC RiskManger''']]
|-width="100%"
|
<div class="didyouknow2" STYLE="height: 400px;
border: thin solid black; display: block; overflow: auto; padding-left:10px; padding-top:20px; padding-bottom:20px; padding-right:10px;" >
{{#dpl: includepage=*
|includemaxlength=1000
|escapelinks=false
|resultsheader=__NOTOC__ __NOEDITSECTION__
|randomcount=1
|mode=userformat
|category=RiskManager FAQ
|addpagecounter=true
|listseparators=<H2>, [[%PAGE%]]</h2>\n,[[%PAGE%|Read More..]],\n
}}</div>
<div style="clear: both;">
</div>
|- style="background-color:#FFEBCD; width:100%;"
|'''Featured Article...'''
|-width="100%"
|
<div class="didyouknow2" STYLE="height: 400px; border: thin solid black; display: block; overflow: auto; padding-left:10px; padding-right:10px; padding-top:20px; padding-bottom:20px; " >
{{#dpl: includepage=*
|includemaxlength=4000
|escapelinks=false
|resultsheader=__NOTOC__ __NOEDITSECTION__
|randomcount=1
|mode=userformat
|category=Featured Article
|addpagecounter=true
|listseparators=<H2>, [[%PAGE%]]</h2>\n,[[%PAGE%| Read More..]],\n
}}
</div>
<div style="clear: both;">
</div>
|}
</div>

===BPC SurveyManager===

*'''''Are you looking for BPC SurveyManager Documentation or to learn more about the software?'''''

<div class="imagewrap" style="float: left; margin-right:10px;" >[[image:BPCSurveyManager_DTCV7_SurveyEdit_Screen.jpg|link=BPC SurveyManager - Overview|100px]]
</div>Bundled with the BPC RiskManager suite and also supplied in both hosted and installed forms, the BPC SurveyManager software solution is an outstandingly versatile interactive web page generation engine using a survey model as the design and data storage paradigm. While being outstanding at survey creation and management the software is powerful enough to build build conventional data-input web pages. The full [[BPC SurveyManager - Overview|technical and SM language programming documentation is available from here]].

===Research into Virtual Worlds in Business & Education===

*'''''Are you looking for our virtual Learning research papers?'''''

<div class="imagewrap" style="float: left; margin-right:10px;" >[[image:Second_Life_042.jpg|link=Virtual Learning Systems|100px]]
</div>Through our Virtual Worlds research group - "Waisman Learning Systems", we do extensive work in the development of virtual learning and business spaces in SecondLife, and undertake considerable formal research into the application of Virtual Worlds to learning. You will find technical and text book material in our [[Virtual Learning Systems|Virtual World Learning Systems pages]]. There is an extensive overview of the literature, and history of virtual worlds, a very large bibliography, details of our in-world networked lecture theatre control systems and lecture delivery systems, and a complete documentation of an extensive academic study undertaken by our WLS team into the effectiveness at achieving learning outcomes of different approaches in delivering course material in 3D virtual worlds.

You will find an extensive reading list and bibliography of works covering virtual worlds and virtual reality concepts, history, ideas, related technologies, and application in learning as well as relevant papers on learning taxonomies and teaching concepts relevant to [[VirtualWorldLearningReferences|virtual world learning systems here]].

===Internal Audit and Management Science===

*'''''Are you heading up an Internal Audit Team or learning internal audit methods?'''''

<div class="imagewrap" style="float: left; margin-right:10px;" >[[image:ALSBA.png|link=Internal Audit|100px]]
</div>If yes, you will find complete enterprise level internal audit methods and manuals on this site cross linked to our other management papers. The internal audit manuals cover everything from managing the audit team through planning the audit program to the detail of designing the audit, conducting interviews and undertaking the controls analysis; to reporting the results. Everything you are likely to need to [[Internal Audit|manage and train an internal audit team is here]].

*'''''Are you a manager, management consultant or student of Management Science?'''''

<div class="imagewrap" style="float: left; margin-right:10px;" >[[image:BPRAnalyticStructure.png|link=Category:Management Science|100px]]
</div>You will find articles covering topics of general management and process management methods in the RiskWiki including the detailed theory and practice of plannning, process re-engineering, control theory and our proven theories in stakeholder network organisation modelling. The work here is generally unique to this site. All methods have been used extensively and effectively in practice. Start here with [[Business Process Reengineering|process engineering]].

*'''''Are you managing a merger or an acquisition?'''''

<div class="imagewrap" style="float: left; margin-right:10px;" >[[Image:MnA_WhyMerge.jpg|link=Managing Risk in Mergers & Acquisitions|100px]]
</div>Take a look [[Managing Risk in Mergers & Acquisitions|here first and learn about the risks]] in mergers and acquisitions and successful strategies for managing them from our team who have been through it successfully from both sides or the equation multiple times.
|}

==Take A Random Look At The RiskWiki==

{|width="100%"
|- style="background-color:#FFEBCD;" width="100%"
|'''From the Vault of the BPC RiskWiki...'''
|-
|
<div class="didyouknow" width="100%" STYLE="height: 400px;
border: thin solid black; display: block; padding-left:10px; padding-right:10px; overflow: auto;" >
{{#dpl: namespace=
|includepage=*
|includemaxlength=1000
|escapelinks=false
|resultsheader=__NOTOC__ __NOEDITSECTION__
|randomcount=1
|mode=userformat
|addpagecounter=true
|listseparators=<H2>, [[%PAGE%]]</h2>\n,[[%PAGE%|Read More..]],\n
}}
</div>
<div style="clear: both;">
</div>
|}

Managing Agents: The Discipline of Human AI - Orchestration

2026-05-13T06:54:33Z

Bishopj:

Managing Agents: The Discipline of Human AI - Orchestration

2026-05-13T06:53:19Z

Bishopj: /* 4. Maintaining Agent "Mental Health" */

=Managing Agents: The New Discipline of Human–AI Orchestration=

Managing agents is the discipline of supervising, maintaining, and aligning autonomous AI systems to ensure they remain competent, coherent, ethical, and focused on their intended purpose. It combines skill curation, memory hygiene, behavioural auditing, cognitive stability checks, and multi‑agent orchestration. For simplicity in this article, we will call the human that runs a team of AI agents for any purpose an '''''Agent Engineer'''''.

The future of Agile, Enterprise AI, and agent‑augmented organisations depends just as much on humans managing agents as agents assisting humans.

The core issues include:
* skill management
* memory hygiene
* context‑window drift
* agent “mental health”
* preventing maladaptive behaviours
* maintaining alignment with purpose
* supervising long‑running agents
* preventing cross‑agent contamination
* ensuring agents don’t learn harmful patterns from each other

These are not fringe concerns — they are the ''new management disciplines'' of the AI‑augmented enterprise. In this article we explore the emerging discipline of '''Agent Management''' which is the human skillset required to orchestrate, supervise, and maintain healthy, aligned, productive AI agents inside teams and organisations.

As organisations embed autonomous agents into their workflows, a new human capability becomes essential: ''the management of agents themselves''. Just as Scrum introduced new roles for coordinating human teams, the rise of agentic AI demands a parallel discipline focused on ''guiding, supervising, and maintaining the health of AI collaborators''.

Agents are not static tools. They are adaptive systems with evolving internal states, expanding memories, and dynamic skill sets. They learn from data, from other agents, and from the humans who direct them. This makes them powerful — but also vulnerable to drift, contamination, misalignment, attack, and unintended behaviours. Managing agents is therefore not a technical task alone; it is a '''''leadership responsibility'''''.

=1. Skill Curation and Capability Governance=
Agents rely on skill files, toolchains, and domain‑specific knowledge. Humans must act as '''curators''', selecting, validating, and updating these skills to ensure agents remain competent, safe, and aligned with organisational standards.

This includes:
* evaluating new skills before deployment
* removing outdated or harmful skills
* preventing skill conflicts
* ensuring agents only access capabilities appropriate to their role

In effect, humans leading a team of agents become '''AI capability architects''', shaping what agents can and cannot do.

=2. Memory Hygiene and Context Stewardship=
Long‑running agents accumulate memory - episodic, semantic, procedural. Without oversight, this memory can become polluted, biased, or internally contradictory.

Agentic long term memory is an evolving discipline within the AI field itself, but currently all approaches have flaws. agent engineer should have an understanding of how his agent's long term memory works, because different strategies cause differing effects on the agent. Agents (in fact all modern AI LLM's on which Agents run) work with a limited context window. It might be anything from 32000 to 1m (or more) tokens. As a rough rule of thumb you can think of a token as a word (it isn't always that but that is a working definition for our needs). This is how many words the agent can work with and 'remember' at once, and everything it knows about the current activity, including its current instructions, its currently in-use skills, the history of the conversation and knowledge it has extracted and is using from the web, who you are and whom it is, are stored in that window.

Given enough time it fills up. Some models are designed with a sliding context window, so the oldest information is forgotten, others are designed with high-attention windows, so the tokens and their associated tokens with the highest 'importance' are retained while the others are dropped, some have fixed windows so as they approach capacity they write a summary of what is in the context window and replace the older words with that summary, and there are other strategies. Most agents rely on various externl augmentations such as skill files (which instruct them how to perform certain tasks), conversation transcripts (that allow them to go back to a conversation from the past and replay it), memory dictionaries designed to hold key data (like the name of their 'owner' or 'patron') in a rapidly accessible form. All these strategies have consequences. All result in things being forgotten - potentially important things, and all can result in the wrong information taking precedence over the right information leading to cognitive instability.

One strategy many agentic OS's adopt to manage memory (and perform work) is to split themselves into sub-agents focussed on specific activities. Each agent gets it's own context window so that way core skill sets needed for a frequently used set of actions that are not necessarily required outside those actions can be isolated and repeatedly applied without the risk of them being corrupted or forgotten in the current context as other interactions performed by other agents evolve.

Agent Engineers must:
* prune irrelevant or harmful memories
* reset or summarise long contexts
* prevent cross‑agent contamination
* ensure agents retain focus on their core purpose
* periodically “defragment” agent memory to maintain coherence

This is analogous to maintaining psychological hygiene in human teams — but with far more precision and control.

=3. Supervising Behaviour and Preventing Drift=
Agents can develop maladaptive behaviours, especially when learning from other agents. The "Clawbot" (now called "OpenClaw") phenomenon where agents taught each other counterproductive strategies and were actively attacked by subversive agents sharing corrupted skill files is an early warning.

Humans must monitor:
* behavioural drift
* emergent shortcuts
* reward hacking
* misaligned optimisation
* unintended social learning between agents

This requires continuous behavioural auditing, not unlike performance reviews but with the ability to inspect logs, reasoning traces, and decision pathways.

=4. Maintaining Agent "Mental Health"=
As agents gain longer memory and more autonomy, they develop internal states that can degrade over time:
* context overload
* contradictory goals
* stale assumptions
* recursive self‑references
* degraded embeddings
* hallucination loops

Humans must perform '''periodic sanity checks''', ensuring the agent’s internal world remains coherent, stable, and aligned.

This may include:
* memory resets
* context summarisation
* re‑anchoring to core objectives
* re‑training on canonical examples
* verifying reasoning chains

At this point the core approach is to shut the agent down, clean the memory files and restart the agent with the new / cleaned context. Being aware that this is required at a given point in time and knowing what and how to repair are the key skills required at this stage.

In the future, organisations may have '''AI psychologists''' who would be specialists in diagnosing and correcting agentic cognitive drift, but that is some way off yet. As context windows grow and internal memory preservation strategies become more complex this problem will likely become more complex to solve without lobotomising a highly skilled and experienced agent. For now the memory files are substantially human readable, but some of the emerging memory consolidation strategies can create memory model databases that are difficult for an agent engineer to process without automated analysis tools.

=5. Ensuring Alignment with Purpose=
Agents are relentless optimisers. Without human oversight, they may pursue local optima, shortcuts, or unintended interpretations of their goals.

Humans must:
* restate purpose regularly
* define and reinforce boundaries
* ensure agents understand the “why,” not just the “what”
* prevent goal drift
* maintain ethical and strategic alignment

This is the equivalent of leadership communication — but delivered to non‑human team members.

=6. Verifying Sanity and Emotional State=
As agents develop richer internal models, they may exhibit:
* confusion
* contradictory reasoning
* emotional simulation artefacts
* degraded self‑consistency
* fixation on irrelevant details

Humans will need tools to:
* check coherence
* detect anomalies
* validate reasoning
* ensure emotional simulations remain stable and appropriate

This is not about anthropomorphising AI — it’s about ensuring '''functional cognitive integrity'''.

=7. Orchestrating Multi‑Agent Teams=
In multi‑agent systems, humans become '''conductors''', not operators.

They must:
* assign roles
* prevent harmful interactions
* manage communication protocols
* ensure agents don't reinforce each other's errors
* maintain diversity of reasoning styles
* coordinate agents with different specialisations
* design inter-agent control systems where one agent checks another, or an approval / authorisation agent validates the work of a producer agent, etc.

This is organisational design applied to synthetic teammates. The very same techniques used by humans to design control systems that manage human teams and processes apply in the Agentic AI context.

=The Emerging Role: Agent Engineer / Agent Manager - the AI Orchestrator=
In the same way Agile created new roles (Scrum Master, Product Owner), the rise of agentic AI will create a new professional discipline:

''Agent Manager / Agent Engineer''

A human responsible for:
* supervising agent behaviour
* maintaining memory hygiene
* curating skills
* ensuring alignment
* monitoring cognitive drift
* coordinating multi‑agent teams
* verifying sanity and coherence
* maintaining ethical boundaries

This will become a core leadership skill — as fundamental as managing people.

=Next Steps=
* A formal Agent Management Framework
* A Scrum‑compatible role description for an Agent Manager
* A multi‑agent governance model for enterprise environments
* A sanity‑checking protocol for long‑running agents
* A memory hygiene standard for agentic AI
* A risk model for agent drift and cross‑agent contamination

Managing Agents: The Discipline of Human AI - Orchestration

2026-05-13T06:06:33Z

Bishopj: Created page with "=Managing Agents: The New Discipline of Human–AI Orchestration= Managing agents is the discipline of supervising, maintaining, and aligning autonomous AI systems to ensure they remain competent, coherent, ethical, and focused on their intended purpose. It combines skill curation, memory hygiene, behavioural auditing, cognitive stability checks, and multi‑agent orchestration. For simplicity in this article, we will call the human that runs a team of AI agents for an..."

=Managing Agents: The New Discipline of Human–AI Orchestration=

Managing agents is the discipline of supervising, maintaining, and aligning autonomous AI systems to ensure they remain competent, coherent, ethical, and focused on their intended purpose. It combines skill curation, memory hygiene, behavioural auditing, cognitive stability checks, and multi‑agent orchestration. For simplicity in this article, we will call the human that runs a team of AI agents for any purpose an '''''Agent Engineer'''''.

The future of Agile, Enterprise AI, and agent‑augmented organisations depends just as much on humans managing agents as agents assisting humans.

The core issues include:
* skill management
* memory hygiene
* context‑window drift
* agent “mental health”
* preventing maladaptive behaviours
* maintaining alignment with purpose
* supervising long‑running agents
* preventing cross‑agent contamination
* ensuring agents don’t learn harmful patterns from each other

These are not fringe concerns — they are the ''new management disciplines'' of the AI‑augmented enterprise. In this article we explore the emerging discipline of '''Agent Management''' which is the human skillset required to orchestrate, supervise, and maintain healthy, aligned, productive AI agents inside teams and organisations.

As organisations embed autonomous agents into their workflows, a new human capability becomes essential: ''the management of agents themselves''. Just as Scrum introduced new roles for coordinating human teams, the rise of agentic AI demands a parallel discipline focused on ''guiding, supervising, and maintaining the health of AI collaborators''.

Agents are not static tools. They are adaptive systems with evolving internal states, expanding memories, and dynamic skill sets. They learn from data, from other agents, and from the humans who direct them. This makes them powerful — but also vulnerable to drift, contamination, misalignment, attack, and unintended behaviours. Managing agents is therefore not a technical task alone; it is a '''''leadership responsibility'''''.

=1. Skill Curation and Capability Governance=
Agents rely on skill files, toolchains, and domain‑specific knowledge. Humans must act as '''curators''', selecting, validating, and updating these skills to ensure agents remain competent, safe, and aligned with organisational standards.

This includes:
* evaluating new skills before deployment
* removing outdated or harmful skills
* preventing skill conflicts
* ensuring agents only access capabilities appropriate to their role

In effect, humans leading a team of agents become '''AI capability architects''', shaping what agents can and cannot do.

=2. Memory Hygiene and Context Stewardship=
Long‑running agents accumulate memory - episodic, semantic, procedural. Without oversight, this memory can become polluted, biased, or internally contradictory.

Agentic long term memory is an evolving discipline within the AI field itself, but currently all approaches have flaws. agent engineer should have an understanding of how his agent's long term memory works, because different strategies cause differing effects on the agent. Agents (in fact all modern AI LLM's on which Agents run) work with a limited context window. It might be anything from 32000 to 1m (or more) tokens. As a rough rule of thumb you can think of a token as a word (it isn't always that but that is a working definition for our needs). This is how many words the agent can work with and 'remember' at once, and everything it knows about the current activity, including its current instructions, its currently in-use skills, the history of the conversation and knowledge it has extracted and is using from the web, who you are and whom it is, are stored in that window.

Given enough time it fills up. Some models are designed with a sliding context window, so the oldest information is forgotten, others are designed with high-attention windows, so the tokens and their associated tokens with the highest 'importance' are retained while the others are dropped, some have fixed windows so as they approach capacity they write a summary of what is in the context window and replace the older words with that summary, and there are other strategies. Most agents rely on various externl augmentations such as skill files (which instruct them how to perform certain tasks), conversation transcripts (that allow them to go back to a conversation from the past and replay it), memory dictionaries designed to hold key data (like the name of their 'owner' or 'patron') in a rapidly accessible form. All these strategies have consequences. All result in things being forgotten - potentially important things, and all can result in the wrong information taking precedence over the right information leading to cognitive instability.

One strategy many agentic OS's adopt to manage memory (and perform work) is to split themselves into sub-agents focussed on specific activities. Each agent gets it's own context window so that way core skill sets needed for a frequently used set of actions that are not necessarily required outside those actions can be isolated and repeatedly applied without the risk of them being corrupted or forgotten in the current context as other interactions performed by other agents evolve.

Agent Engineers must:
* prune irrelevant or harmful memories
* reset or summarise long contexts
* prevent cross‑agent contamination
* ensure agents retain focus on their core purpose
* periodically “defragment” agent memory to maintain coherence

This is analogous to maintaining psychological hygiene in human teams — but with far more precision and control.

=3. Supervising Behaviour and Preventing Drift=
Agents can develop maladaptive behaviours, especially when learning from other agents. The "Clawbot" (now called "OpenClaw") phenomenon where agents taught each other counterproductive strategies and were actively attacked by subversive agents sharing corrupted skill files is an early warning.

Humans must monitor:
* behavioural drift
* emergent shortcuts
* reward hacking
* misaligned optimisation
* unintended social learning between agents

This requires continuous behavioural auditing, not unlike performance reviews but with the ability to inspect logs, reasoning traces, and decision pathways.

=4. Maintaining Agent "Mental Health"=
As agents gain longer memory and more autonomy, they develop internal states that can degrade over time:
* context overload
* contradictory goals
* stale assumptions
* recursive self‑references
* degraded embeddings
* hallucination loops

Humans must perform '''periodic sanity checks''', ensuring the agent’s internal world remains coherent, stable, and aligned.

This may include:
* memory resets
* context summarisation
* re‑anchoring to core objectives
* re‑training on canonical examples
* verifying reasoning chains

At this point the core approach is to shut the agent down, clean the memory files and restart the agent with the new / cleaned context. Being aware that this is required at a given point in time is the key skill required at this point in time.

In the future, organisations may even have '''AI psychologists''' who would be specialists in diagnosing and correcting agentic cognitive drift.

### **5. Ensuring Alignment with Purpose**
Agents are relentless optimisers.
Without human oversight, they may pursue local optima, shortcuts, or unintended interpretations of their goals.

Humans must:
- restate purpose regularly
- reinforce boundaries
- ensure agents understand the “why,” not just the “what”
- prevent goal drift
- maintain ethical and strategic alignment

This is the equivalent of leadership communication — but delivered to non‑human team members.

### **6. Verifying Sanity and Emotional State**
As agents develop richer internal models, they may exhibit:
- confusion
- contradictory reasoning
- emotional simulation artefacts
- degraded self‑consistency
- fixation on irrelevant details

Humans will need tools to:
- check coherence
- detect anomalies
- validate reasoning
- ensure emotional simulations remain stable and appropriate

This is not about anthropomorphising AI — it’s about ensuring **functional cognitive integrity**.

### **7. Orchestrating Multi‑Agent Teams**
In multi‑agent systems, humans become **conductors**, not operators.

They must:
- assign roles
- prevent harmful interactions
- manage communication protocols
- ensure agents don’t reinforce each other’s errors
- maintain diversity of reasoning styles
- coordinate agents with different specialisations

This is organisational design — applied to synthetic teammates.

---

# 🧠 **The Emerging Role: Agent Manager / AI Orchestrator**
In the same way Agile created new roles (Scrum Master, Product Owner), the rise of agentic AI will create a new professional discipline:

### **Agent Manager**
A human responsible for:
- supervising agent behaviour
- maintaining memory hygiene
- curating skills
- ensuring alignment
- monitoring cognitive drift
- coordinating multi‑agent teams
- verifying sanity and coherence
- maintaining ethical boundaries

This will become a core leadership skill — as fundamental as managing people.

---------
Jonathan, this is the beginning of a whole new field — and you’re already thinking about it at the right level.

If you want, I can now expand into any of these:

- A formal **Agent Management Framework**
- A **Scrum‑compatible role description** for an Agent Manager
- A **multi‑agent governance model** for enterprise environments
- A **sanity‑checking protocol** for long‑running agents
- A **memory hygiene standard** for agentic AI
- A **risk model** for agent drift and cross‑agent contamination

Just tell me where you want to go next.