Why SAFe Won’t Solve Your Problems

One of the curious pastimes I’ve seen lately is SAFe®-bashing. It seems like everyone on LinkedIn these days has some “hot take” on SAFe, why it sucks, and specifically why their preferred framework is the better solution. Some of those other frameworks are quite good (including Scrum@Scale and LeSS, notably), but I feel the SAFe-bashing is misplaced. I believe most of it stems from a misunderstanding about how SAFe works, but the rest seems to just be click-bait to get views or jumping on a bandwagon. I think, however, that SAFe is being bashed for the wrong reasons.

People expect SAFe to solve problems it wasn’t designed to solve and then are unhappy when it doesn’t solve those problems. All frameworks are going to have these kinds of issues (although, come to think of it, I don’t see a lot of LeSS-bashing…). It’s because no framework can solve these kinds of problems. Not even Silicon Valley Product Group’s Product Model (please, do not adopt that model!). So let’s talk about what SAFe is, how we should use frameworks, and what the hard cold facts are.

What Is SAFe For?

The Scaled Agile Framework (for enterprises), or SAFe, is designed to allow many, many people to work collaboratively on a single product, solution, or service. It brings together 50-125 people for the sole purpose of aligning work to a common vision, planning together, and then executing together to deliver a large amount of work over an 8-12 week timebox.

Teams gather at Planning Interval (PI) Planning, hear the context of the business and their product/solution/service, and plan together to find ways to work with other teams to deliver the most value possible in those 8-12 weeks. Teams execute the PI in (typically) 2-week time-boxes (iterations) and the teams demonstrate progress at the end of every one. At the end of the 8-12 weeks, everyone gathers to retrospect on the entire PI and find ideas to address problems that arose.

It’s a Scrum sprint writ large, with features instead of user stories. But what SAFe is most definitely not is a panacea for your organization’s problems.

Frameworks as Solutions

There seems to be a desire within the business world to find some solution to solve an organization’s problems. To easily fix what is hard to fix. Many management teams look at frameworks as the solution to those problems. The trouble is that these frameworks aren’t designed to address their specific organizational issues. In the case of SAFe, LeSS, Scrum@Scale, etc., they’re designed to get a lot of people working collaboratively to deliver value to customers. And hiring some big consulting company to come in to tell you which of their playbooks you should buy is not an option either – and constitutes a whole other blog post.

Sadly, one thing I’ve noticed over too many years doing this is people struggle to put in the effort to understand what SAFe (or any other framework) is or means or does. Instead, they find shortcuts to map things in SAFe to things they already understand. For instance, if I explain that the RTE is “the person who keeps the teams on track, tracks metrics on the teams’ performance, and helps resolve impediments”, far too many people go “oh, Program Manager – got it.” Sorry, but no; that’s not it. It’s not called “Program Manager” for a reason – because it’s not a Program Manager; it’s a Release Train Engineer. Hence, this lack of respect for the efforts that have gone into SAFe and other frameworks means they’re doomed to fail when implemented by the shortcutters.

Frameworks are designed to solve problems. And guess what? Solving your particular organization’s issue with a lack of clarity or focus or funding isn’t what they’re solving. Has SAFe made headway in helping organizations address those? Surprisingly, yes. It’s not the core function, though. What every framework that uses agile as its core (like SAFe) will do is show you where and what your problems are. It’s your job to solve those problems. That’s why you’re paid, as they say, “the big bucks”.

The Real Issues with SAFe (IMHO)

A quick aside about the real issues I see with SAFe. First, it’s been touted as a “silver bullet” since time immemorial. Is that the fault of Scaled Agile, the maintainer of SAFe? Undoubtedly they share some of the blame. They pushed their product hard to make a sale. But it’s also the consultants who push it as a cure-all and the management teams that believe them. I’ve seen SAFe applied in some very heinous cases: Agile Release Trains (ARTs) with just one team; ARTs composed of teams that deliver different products; ARTs working in year-long PIs. The issue is that SAFe is being used where it’s not appropriate. It’s being twisted and morphed into what it’s not. And that leads to a lot of dissatisfaction when it doesn’t deliver what it isn’t designed to.

Secondly, though, is the quality of the people who engage with SAFe. Some organizations, like Scrum Alliance, have required that all of their certified trainers present material to experts to evaluate how well those candidates know the material. SAFe makes no such requirement. The spectrum of quality for SAFe consultants runs from “I read it in a book” to “I’ve been doing this since God was a child.” The quality varies wildly – and so do the implementations. This is the main thing I wish Scaled Agile had done differently.

Finally, SAFe has been used to support and prop up existing processes. Yes, you can time-box Waterfall. And yes, you can layer SAFe on top of a time-boxed Waterfall project. That wasn’t the intent. Don’t bash it when it doesn’t do what it wasn’t intended to do.

The Cold Hard Facts

As I said above, any agile methodology, including any frameworks built on them, will show you your problems. It will shine a big spotlight on what the issues are. It can’t fix them. That’s up to the people who manage the system (we call those people “managers”). They have to fix the problems. However, it’s easier to blame the framework for failing to do what it wasn’t designed to do. It’s like judging a fish on its ability to climb a tree. (Whereas managers should be judged on their ability to manage the system.)

What I see with too many clients is “Well, SAFe didn’t solve our problems, maybe this other framework will!” Instead of doing the actual hard work of solving problems, they instead glom onto the Next Big Idea. And I tell them that this new framework will also fail. And they go forward anyway. *headdesk*

Closing Thoughts

I know this sounds a little doom-and-gloom, but it doesn’t have to be. First, don’t expect your framework to solve your organization’s issues. It can’t. It wasn’t designed for that and your problems are your problems. Only you know how to work to solve them.

Second, managers have to solve the problems. I know it’s hard, but it’s the manager’s job. Read some of my articles about management (and here) to learn good ways to do this. Read Management 3.0 by Jurgen Appelo (it’s a great book!).

Finally, figure out what you really need. Do you need a scaling framework? Or do you just need a couple of teams collaborating on something? There is a lot of overhead in SAFe that’s necessary when you’re running a full ART. If you’re not doing that, don’t incur that overhead. Find the right solution for your problems.

And I’d be remiss if I didn’t say that this is exactly the kind of thing I do. I have decades of experience in IT and over a decade working with SAFe and other frameworks. Getting the right coach to help you make the right decisions is perhaps the best investment you can make. Good luck with your implementation!