Uncertainty & the Scaled Agile Framework (SAFe™)


What is the connection between Uncertainty and the Scaled Agile Framework?

Uncertainty is one of the core reasons we need to be agile. Different modes of Business/Requirements/Technology uncertainties impact our economic costs in product development – especially the potential impact of risk. The first principle of SAFe™ is “Take an economic view”. I frequently use my “uncertainty filter glasses” to take an alternative economic view. I find it helps Scaled Agile/SAFe™ practitioners/leaders understand both the need for Agility as well as examine various work system design considerations. In this article, I introduce the Stacey Matrix which is one of my favorite models for understanding the uncertainty landscape as well as the implications of uncertainty on various specific SAFe™ design decisions.

Making it Concrete – The Stacey Uncertainty Matrix and its relation to the Scaled Agile Framework


As I wrote about at some length in Risk-Aware Product Development (a.k.a Agile) explaining the concept of Requirement/Business/Technology uncertainty is one of the first things I do with most audiences I meet for the first time. In a Leading SAFe/SPC class this typically takes place in the first module when we go over the need for SAFe. This is not a core part of the materials but I take the time to explain it anyhow and then find myself referring back to it throughout the workshop.

The first layer of realization is that our problem with the classic approaches to product development is that they were built for complicated endeavors but not complex ones.

Then we layer on more interesting realizations like the fact that for some endeavors like those approaching the “Anarchy”/”Chaos” domains probably the best approach would be a “Skunkworks” style cross-functional co-located fully empowered small team. As you grow a bit farther from Anarchy you can scale agility using an approach like the Scaled Agile Framework. At these levels of uncertainty/risk the trade-off of distributed teams, distributed PI Planning, system team, component teams, and shared architects/UX MIGHT make sense and are worth considering.

As you approach the simpler domain sometimes even the alignment rationale for “whole train” PI Planning can be reconsidered. Is that SAFe™ heresy? maybe. But I find that telling people “Whole ART PI Planning” is mandatory is less effective than showing them WHEN it has a better economic impact. (BTW as you grow in complexity/uncertainty you also need better people that are more engaged – which the Whole ART PI Planning helps with as well)

In general, this thinking helps leaders at these workshops grasp the various economic levers that go into tailoring a SAFe™ implementation. I find this disarms some of the resistance you get when people feel something is “a must”. Using this approach they typically go out with a stronger conviction to avoid some compromises and a better feeling about the compromises that do make sense.

To take another example of how I use the uncertainty matrix during SAFe™ training/implementation discussions – SAFe™ talks about a hierarchy between ART Product Management and the Product Owners working with the teams. A typical and sensible question people have is “Who should wear the Product Owner hat?”. Using the uncertainty matrix, we realize that in some cases the Product Owner should be a Product Manager (probably the top two quadrants of the matrix) and in some other cases, he can also be a more technical leader (Especially on the far right side of the matrix). As the typical organization, I work with is struggling to fill those Product Owner roles, this realization helps them deploy their people more effectively in a way that minimizes the risk of ineffective feedback loops due to the wrong individuals being in the tight Product Owner loop.


In summary

Understanding uncertainty and its attributes and implications is in my view and experience a critical step of buying into the need for agile as well as gaining the ability to design an effective agile approach for your context. Presenting the Stacey Matrix and trying to map it to your reality is one technique I used to help people gain this understanding. Using it as a decision filter/design criteria for further SAFe™ tailoring questions complements this initial presentation/exposure and grounds it. If you are teaching Leading SAFe™/SPC classes, explaining the need for agile to leaders/executives, or working with an organization to implement a scaled agile approach, I believe you will see improved results if you add this technique to your toolbox. I know I have.

Subscribe for Email Updates:



Story Slicing
Agile Risk Management
IT Operations
System Team
Built-In Quality
Nexus and SAFe
Risk-aware Product Development
Agile Release Planning
PI Planning
Continuous Integration
Agile in the Enterprise
Lean Software Development
Kanban Kickstart Example
Engineering Practices
Artificial Intelligence
What Is Kanban
The Agile Coach
Introduction to Test Driven Development
Implementation of Lean and Agile
Jira Plans
Rapid RTC
Entrepreneurial Operating System®
Systems Thinking
Kanban Basics
An Appreciative Retrospective
Agile Marketing
Agile Release Management
Sprint Planning
Lean Agile Leadership
Scrum and XP
Implementing SAFe
Development Value Streams
Iterative Incremental Development
Portfolio for Jira
Agile Mindset
PI Objectives
Manage Budget Creation
Agile Israel
Product Ownership
Professional Scrum with Kanban
Agile Community
Lean and Agile Principles and Practices
Coaching Agile Teams
Jira Cloud
ALM Tools
Continuous Deployment
Agile for Embedded Systems
Advanced Roadmaps
Agile Exercises
Agile Israel Events
Agile Project Management
Lean Startup
Lean Agile Organization
Risk Management in Kanban
Scrum Primer
Agile and DevOps Journey
Process Improvement
RTE Role
Continuous Delivery
Program Increment
Nexus vs SAFe
Agile Assembly Architecture
Software Development
Scrum Values
speed at scale
Effective Agile Retrospectives
Introduction to ATDD
A Kanban System for Software Engineering
Kanban Game
Software Development Estimation
Legacy Enterprise
Hybrid Work
Agile Basics
Sprint Retrospectives
Principles of Lean-Agile Leadership
Limiting Work in Progress
Agile Program
SAFe Release Planning
Release Train Engineer
Reading List
Continuous Planning
Releases Using Lean
Enterprise DevOps
Lean Agile Basics
Agile Delivery
Operational Value Stream
Applying Agile Methodology
Lean Risk Management
AI Artificial Intelligence
Legacy Code
Scrum Guide
SAFe DevOps
Agile Testing Practices
Managing Risk on Agile Projects
Managing Projects
Achieve Business Agility
Lean Budgeting
Value Streams
speed @ scale
Lean and Agile Techniques
Product Management
Agile Games
Agile India
ART Success
Pomodoro Technique
Agile Techniques
Professional Scrum Product Owner
ScrumMaster Tales
Continuous Improvement
Scrum With Kanban
Nexus Integration Team
Daily Scrum
System Archetypes
Business Agility
Scrum Master
Large Scale Scrum
Elastic Leadership
Agile Product Development
Scrum Master Role
Sprint Iteration
Professional Scrum Master
Acceptance Test-Driven Development
Agile Contracts Best Practices
Lean-Agile Budgeting
Certified SAFe
Agile Product Ownership
Scaled Agile Framework
Test Driven Development
Agile Outsourcing
The Kanban Method
Kanban 101
lean agile change management
Agile Development
Agile Project
Kaizen Workshop
Perfection Game
Lean Agile Management
Accelerate Value Delivery At Scale
Agile Games and Exercises
Nexus and Kanban
Lean Agile
Lean-Agile Software Development
Risk Management on Agile Projects
Quality Assurance
System Integration Environments
Change Management
Games and Exercises
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart