Category Archives: Scaled Agile

Two of the questions I’m frequently asked these days “Do we need the Scaled Agile Framework (SAFe)?” as well as “CAN we (safely) implement SAFe?”. I recently published a self-assessment based on the questions I typically help organizations answer when they’re looking at this. Continue reading →

Last week I gave a deep dive workshop in the Agile Games New England conference about the NEED for engagement and participation when implementing agile at scale using an approach like SAFe as well as how I use online games like Kahoot and Socrative and various points throughout the implementation to increase engagement and participation especially when working with big groups beyond the team. Here’s my slide deck from the talk:

Earlier this evening I delivered a talk at Agile Boston named “The Art of SAFe ART/Value Stream Design” where I tried to explain the different layers of SAFe and how they apply in a variety of real-world situations. We discussed Telco and Financial Services systems of systems as well as some examples brought up by the audience. I had lots of fun although my Wacom tablet didn’t play along nicely. Need to figure out what that was about.

PS If you’re interested to learn about SAFe, ART, Value Streams, my next Leading SAFe 4.0 workshop is in the Boston area on March 9-10th. If you move REALLY fast you can take advantage of early bird pricing. In any case as readers of my blog you can get a 10% discount. Just use YYBLOG on checkout.

SAFe (The Scaled Agile Framework) uses Story Points throughout the various levels as its estimation currency. This is covered in the “Story” article on the SAFe site. This is a pretty standard practice in organizations scaling agile these days. If you dive a bit deeper into how this is done in SAFe you will see that actually the story points used in SAFe are quite similar to “Ideal Developer Day” as this helps the teams align to a common baseline and support a rational economic ROI discussion at the level of Features/Capabilities that require effort from more than one team or haven’t even been mapped to a specific team yet.

An alternative to using Story Points at the team level that is interesting to look at especially as Kanban is becoming a first-class citizen of the SAFe world is to use NoEstimates.

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