Does SAFe yields better long term results than traditional Agile

Question

While SAFe is picking up a lot of attention and as I understand seems to yields better long term results (velocity and overall product quality) than traditional Agile, I'm curious about its possible downside. Any thoughts on this would be appreciated.

Answer 1

First, I must say that my experience does not match the statement nor am I aware of any study that shows that. When SAFe or "pure" Agile are adopted well, they both have great throughput and quality.

When looking at the differences, I'd first look at what makes them hard to adopt well. With SAFe, there are many positions to be filled and it feels a lot like the old positions in waterfall, but they aren't. From a change management point of view, it is tempting to say that managers or team leads become release train engineers, etc. This is where a lot of SAFe adoptions fall apart because people do their old job, not their new one and they carry many of the old dysfunctions that the company was adopting SAFe to fix along with them.

With a more "pure" agile approach, the problem is the opposite (and paradoxically very much the same). Simplifying the organization and decentralizing decision-making is terrifying, and so many organizations simply don't. They put in some meetings and take a few terms from Scrum or Kanban and call it a day. Anyone in change management will tell you that a half-done change is a disaster.

You asked about a downside and I would point to this: what change is your organization actually willing to make? Both are a real commitment and neither should be half-done or you are likely to end up in a worse place than you started.

One other thing to consider: what are you optimizing for? SAFe was always designed for incredibly large projects. I don't mean 5 teams, I mean dozens or more. Scrum is optimized for rapid problem solving and adaptability (at a scaling level, LeSS and Scrum@Scale both keep this focus). Kanban is optimized for flow of work through a workflow. If you need to solve problems and adapt to a rapidly changing environment, SAFe might "work" but in the same way that you can hammer in a nail with a wrench if you need to. Similarly, I wouldn't try to manage massive projects with just a pure Scrum approach.

Answer 2

I don't see that SAFe and traditional agile are really comparable in an apple-to-apple sense.

Traditional agile is terrific and when in doubt doubling down on the agile framework is a great idea. But at a fundamental level when you need to have 10 agile teams working in the same direction on what's essentially the same initiative you need a way to coordinate that activity.

Full-blown SAFe is daunting for sure. But looking at just the program/essentials portion of SAFe as a way of solving agile at scale might be better.

Answer 3

I am an evidence-based manager, meaning my practice is based on an ongoing review of the scientific literature, so I can confirm Daniel's statement: There is no objective evidence that SAFe is better (or worse) than other methods of implementing Agile management.

I recommend being careful with terms, just so you get the best advice! Agile is a philosophy or approach to work management, not a method, so there's no such thing as "traditional Agile." SAFe is just one of dozens of approaches to scaling Agile methods to many teams, with SAFe based on the method called "Scrum." Daniel mentions a couple of others, and I created my own, Full Stack Scrum. As he and Eric said, whether you need one of those depends on how many teams you are trying to coordinate. Basic Scrum actually scales quite well across multiple teams if you simply translate the terms upward. That is, treat:

• A representative of each team (often the Scrum Master) like a team member, in this case on a program-level guidance team
• Features ("epics") like user stories
• Release periods (usually four months or less) like sprints
• A program-level facilitator like a Scrum Master
• A weekly "scrum of scrums" with all the SMs like the Daily Scrum

Or, have everyone participate in a single Joint Demonstration Ceremony and you don't even need the scrum of scrums!