One of the main questions I get asked (probably because I have SPC as part of the “alphabet soup” that follows my name) is about SAFe, or the . Most people want to know how prescriptive SAFe is or whether they should use SAFe for their particular situation. The answer usually ends up being something along the Standard Consultant AnswerTM which is – “it depends”. So why might you want to use – or not use – SAFe?
There are a lot of people who would say “you should never use SAFe”. I think these kinds of dogmatic arguments tend to damage the agile community as a whole and I look askance at people who make that kind of claim. Are there times when you should use SAFe? Yes. Are there times to avoid it? Again, yes. This post will address the Scaled Agile Framework in general and use SAFe 4.0 examples specifically. Another post will cover SAFe 4.5 that was released in August 2017.
What Is the Scaled Agile Framework?
SAFe, or the Scaled Agile Framework, is, well, a framework for scaling agile. (If nothing, agilists are pretty descriptive in their naming nomenclature.) It helps establish some rules for how multiple teams working on the same product or product line can collaborate and communicate. And, most importantly, it helps align work the teams are doing to large initiatives at the executive level.
SAFe has been around for around since 2011 and grew out of work that its creator, Dean Leffingwell, did at Rally Software. He was the Chief Methodologist at Rally and was involved in the expansion of the , or RUP. He saw a need for large enterprises that were trying to adopt agile but had trouble with how they were structured (usually as silos based on functional area) and a lack coordination between teams and a lack of visibility for management.
When I first get involved in SAFe I felt it was attempting to fit agile into a waterfall organization. It has evolved significantly since then and now focuses more on overall transformation. With the creation of SAFe 4.0, there is good support for large enterprises looking to link a team’s work to business objectives.
When Should You Use SAFe?
SAFe is perceived as a for agile adoption. When an enterprise looks at adopting agile – for whatever reason – SAFe is a way to align people’s expectations. There are different training courses available for the different levels of the SAFe Big Picture (see right).
The 4.0 Big Picture is intimidating. There are a LOT of icons on it, a lot of levels to it, and a lot of text. When my students see this for the first time, there’s quite a bit of shock. But this was an intent to include everything on a single diagram, which is both good and bad.
SAFe can work really well when you have buy-in from more than just the development or delivery teams. If the executives and managers all agree that agile is the way to go, the Scaled Agile Framework can be a good starting point. And it provides a structure or scaffolding that can help anyone understand how work flows from the top down and how product flows from the bottom up. And the training helps reinforce that.
The main benefit I see is that helps everyone who is involved in a product both see how complicated the product development can be and also how all of this work is aligned and is delivered in small chunks over time. Each team needs to deliver a usable product increment every sprint and every (or team of teams) needs to deliver features (collections of user stories) every Program Increment (PI). It persists some of the same constructs at different scales, which makes it easier to understand.
One final note on this. While I do see that SAFe is promoting the idea of using Kanban for a team process, I am cautious about this. As I’ve posted earlier – and discussed far more in-depth – Kanban can be a recipe for disaster with the wrong kinds of teams. My recommendation for any new group looking to adopt SAFe is to stick with Scrum.
When Should You Avoid SAFe?
SAFe may not be the best choice for you if you are looking at just team implementations. When done badly, SAFe can seriously damage an organization and create strong backlash and entrenchment of old waterfall thinking. So when should you “run away!” from SAFe?
Obviously, for small organizations, SAFe is overkill. There is no reason to adopt many of the structures if only a couple of teams are working in an agile way. If they’re all working on the same product, I would recommend a Scrum of Scrums or attendance at each other’s stand-ups. But creating an Agile Release Train may be a bit much.
The other situation where you may want to “run away” from SAFe would be if the development organization is the only group that’s going to be agile. Without operations, business, or – scarily – quality assurance support, SAFe is probably a bad decision. Of course, without QA, agile in general will be difficult. We need more than just developers engaged in delivering the product. There may be times, due to politics or similar, when the “corporate winds” don’t support this kind of transformation. In those cases, focusing on creating success stories is more important than scaling your transformation. Once those successes happen, a broader transformation is possible.
Finally, if your management team is completely unwilling to let go of a command-and-control mindset, SAFe is probably going to fail. One of the main goals of the class is to give managers an awareness of a “lean-agile mindset”. If they still want to micromanage and use GANTT charts and so forth, it will be a challenge to allow the kind of autonomy SAFe needs to flourish. Command-and-control is anathema to agile, let alone SAFe.
@ Velocity
Most of Velocity Partners’ clients don’t use SAFe – yet. There is certainly potential that our teams would become part of an Agile Release Train (ART) or even be an ART collectively. Today, many of our clients are still working on their initial agile adoptions. They’re trying to figure out whether agile is a good option for them. SAFe is the equivalent of quantum physics for many people. The great thing is that if – or when – our clients decide to adopt SAFe, we are ready and able to adapt readily.
Closing Thoughts
The Scaled Agile Framework can be a daunting challenge for any organization. It has some real benefits to organizations that want a more holistic adoption. And it provides a scaffolding that helps companies get on the same page across the management hierarchy and the functional silos to create functioning teams of teams.
Some people complain about the licensing/certification model that Scaled Agile created. I think it’s not dissimilar to what or does but it sort of franchises out training a lot more than what Scrum Alliance does. While Scrum Alliance allows only a small number of people to train and certify people, Scaled Agile allows anyone to attend their Implementing SAFe class and then teach classes at their own organization. The quality of that training varies wildly. While the content is the same for each class, it’s only part of the training experience. As a result, you can have “SAFe Trainers” who are unqualified to be teaching those classes.
Overall, I like what SAFe is trying to do and think that the implementation is a fair start. There are criticisms, certainly, but as an intermediate step for an enterprise, the Scaled Agile Framework can be a great tool in the toolbox.
Feliz entrenamiento, mis amigos! (Happy coaching, my friends!)