Using the Stacey Uncertainty Matrix in SAFe

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 the need for Agility and 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.

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 of the 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 classic approaches to product development is that they were built for complicated endeavors, 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 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 teams, component teams, and shared architects/UX MIGHT make sense and is 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.

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.