Using the Stacey Uncertainty Matrix for better SAFe™ understanding/implementation

Abstract

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 implications of uncertainty on various specific SAFe™ design decisions.

Details

stacey1

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. On 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, 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.

Eventbrite - Leading the Scaled Agile Framework 4.0 Workshop - Boston, March 2016

The dangers of blindly following (or ignoring) the Program Increment Timebox

NOTE: Scrum teams have had this issue for more than a decade now. But since SAFe(tm) is all the rage these days let’s use the Program Increment Timebox here and leave it as an exercise for the reader to apply the thinking to the Sprint/Iteration timebox. 

Here’s the context – You are an RTE facilitating a SAFe(tm) Program Increment (PI) Planning (I’m actually using SAFe 4.0 terms here. You know this as Release Planning) . When kicking off the day you remind remind the teams that Features needs to fit into one PI. The Product Manager presents the top priority Features. They can all fit into the PI. You guys did a good job to prepare the Features backlog together with the Product Owners and some representatives of the teams.

scrum sprint leftover

Continue reading The dangers of blindly following (or ignoring) the Program Increment Timebox

Pull-based SAFe Invitations – Now in presentation form

This week I’m in Boulder, CO participating in the SAFe SPCT program as an SPCT candidate. One thing we do here is present a personal showcase. Naturally I chose to talk about combining SAFe and the pull-based change and invitations language. Here it is… Continue reading Pull-based SAFe Invitations – Now in presentation form

Using the Spotify Squad Health Check beyond the Squad

Just in time tribute…

I’m on my way from Boston to Manhattan. Tomorrow I’m facilitating an executive workshop for a client with the goal of kicking off the next level of agility. Before that I’m meeting some of the Spotify Agile Coaches/Company Operations people in the NYC Office. I thought this would be a good opportunity to write about a Spotify Squad-level tool I started using in Executive/Management workshops as well as all-hands QuickStarts/QuickBoosts in the last couple of months.

Continue reading Using the Spotify Squad Health Check beyond the Squad

The time has come to close the curtain on the Agile Theater

This article was originally published on Linkedin Pulse…

The time has come to close the curtain on the Agile Theater

We’ve all seen it. It’s quite an elaborate show with Scrum Masters, Sprint Planning, Daily Standups, Secret handshakes, a lot of artifacts, ceremonies, roles. The recent “broadway”-level productions include bigger pictures, more roles, artifacts. It is like visiting the city set in that classic Universal Studio ride.

Continue reading The time has come to close the curtain on the Agile Theater