To be fair, I’ve been fairly critical of some aspects of the Scaled Agile Framework. And even though I’m a SPC, I still don’t blindly install SAFe in many of my clients. That being said, there are a majority of my clients who are using (or planning on using) SAFe, so I get exposed to it quite often.
While I personally struggle with the agileness of much of SAFe, in the spirit of fairness, I do think there are concepts in the framework that are healthy and useful. So let me share a few of those...
The “Big Picture”
I do think it useful in a large-scale organizational level to have a singular view to what “agile is” for and across the organization. This also includes how work “flows” from customer and leadership ideas down to team implementation and the standardization on some set of terminology.
Well, the SAFe big picture gives you that. I’ve seen organizations who are adopting SAFe, spread copies of it to virtually everyone in the organization. They post it in common areas and the thing becomes quite pervasive in establishing a baseline understand. The “good news” is that this truly gets everyone on the same page with respect to agile and the holistic implementation.
Portfolio-level Clarity
I encounter this all the time in my travels.
- An organization is “going Agile”;
- They cobble together teams;
- They cobble together a backlog per team;
- Usually there is no in-depth thinking around alignment of the backlogs, it simply work;
- Then the starting gun is fired and all teams are Scrumming towards the finish line.
SAFe suggests a much more disciplined view to how an organization conceives and delivers work to their teams. The portfolio Kanban board is a wonderful model for qualifying epics and delivering “ready” epics to each team.
I’m reminded of the “interface” between the portfolio level and the program level in SAFe. At PI planning (see below), the teams are delivered a big picture (vision) for the release train (product increment) and a set of prioritized and high value features.
During planning, the teams break down the features into stories, sort through x-team flow, and commit to a release plan and content value.
There is a thoughtful balance between pre-qualifying (understanding the high-mid level view) of the epics and the reality of the teams’ detailed planning and committing to a body of work. I wish all agile organizations could achieve this balance. Instead, I often rough ideas being “dumped into the laps” of the team.
PSI Planning -> PI Planning or Release Planning
I think one of the most valuable activities supported by SAFe is the notion of collaborative, whole team planning, for each program level release train.
It encompasses a 2-day, fairly rigorously defined agenda where the set of teams associated with a PI / release Train take a set of Epic->Features and decompose them into user stories and a sprint-x-sprint release plan.
One of the key things that happens is that it gets a group of teams all on the same page with respect to goals, dependencies & integration, and consolidated demo’s. It also encourages, “forces” the portfolio level to “feed the team” a thoughtful and prioritized set of Epics->Features that the team decomposes into stories as part of their understanding and PI delivery commitment.
Focus on Lean Leadership
One of the things that SAFe tries very hard to do is emphasize the role of leadership in the agile transformation. You see this emphasis in the training recommendation in rolling out SAFe. You see it in the Big Picture. And you see it in every presentation on SAFe.
I actually think the focus on agile and lean-based leadership has increased since the inception of the SAFe model.
What about it simply being a tool-kit?
Henrik Kniberg and Lars Roost in their SAFe video liken much of the power of SAFe to it being a tool-kit that can be applied in appropriate pieces to agile scaling challenges.
I’m not sure if that’s the way it’s being sold, but I do look at it more so that way. They also allude to it being quite BIG and I agree with that as well. There are very few conditions where I could envision a large, mature agile organization needing all of it. But then again…
Here’s a link to the entire video: https://www.youtube.com/watch?v=TolNkqyvieE
Wrapping up
I like what Henrik and Lars have to say around leveraging SAFe as a tool-kit. They don’t actually say it, but when you adopt SAFe at a Shu-level, I believe you’re making a huge mistake.
That is: you don’t have a real clue about agility at scale, or even the basics, BUT you’re adopting SAFe. Every inch, word, tactic, and idea within it. Whether it applies to your context or not, because you don’t have the wisdom or experience to understand the potential trade-offs.
So there you have it in a nutshell. All of SAFe might not be that SAFe. But there are parts of it that might be very useful if you’re doing agile at scale.
Stay agile my friends,
Bob.
Afterthought...
A recent development from the Scaled Agile folks is the introduction of Essential SAFe. eSAFe is a minimalist view to just "the essential bits" of SAFe. If you think about it, that's sort of what I was trying to get at in this article.
While eSAFe is conceptually larger than the points I made, it starts to address the size and inherent confusion for firms implementing SAFe. It's hard for me to imagine an "agile" scaling framework that is the size of SAFe v4.
So I applaud this direction from the Scaled Agile folks and I hope it continues...