Warning! SAFe Is an Undercover Waterfall Agent

A highly prescriptive framework raises concerns about whether it’s genuinely agile or another traditional methodology.

Delivering value as fast as possible is vital to surviving in today’s highly competitive market. Companies have no chance but to adapt themselves to a rapidly changing world. Becoming agile isn’t optional anymore but a necessity for those who want to remain alive. Yet, being agile is more challenging than you can imagine. How companies embrace change will ultimately shape their fate.

Any agile framework will fail when treated as a process. To be agile, you have to adapt more than just how you deliver solutions.

Agile is not a process to increase output speed, it’s a mindset to help teams solve the end-users real problems while generating value for the business.

The biggest obstacle to becoming agile is top management's unwillingness to surrender the command and control behavior. Executives want predictability; they fear uncertainty because the unknown scares them. Yet, they have to show the world they are agile. How can they be agile without embracing empiricism? SAFe comes as the answer for companies afraid of profound structural changes. But is SAFe really agile?

Allow me to elaborate on why I perceive SAFe as an undercover waterfall agent.

Note: this article is based on my experience and observations. You may disagree with my opinion. That’s why I invite you to share your perspective with me.

What is SAFe?

SAFe is one of the most used frameworks to scale with agile. Giant corporations like Barclays, Cisco, and Lego, among others, work with SAFe. It’s indeed a robust framework that aims to help organizations scale successfully with agile. But how SAFe does it is by adding prescriptive and complex processes. Let’s have a look at the official definition.

SAFe for Lean Enterprises is the world’s leading framework for business agility. SAFe integrates the power of Lean, Agile, and DevOps into a comprehensive operating system that helps enterprises thrive in the digital age by delivering innovative products and services faster, more predictably, and with higher quality. - SAFe for Lean Enterprises

Although SAFe may have good intentions, I’ve experienced that adding more processes to gain control is counterproductive. We may have an illusion that everything is anticipated, but software development doesn’t work like that.

Dean Leffingwell, Creator of SAFe, insists Agile isn’t optional anymore. I agree with him. But what I disagree with him is how companies can be agile.

"In the Age of Digital, every business is a software business. Agility isn’t an option, or a thing just for technical teams, it is a business imperative."— Dean Leffingwell, Creator of SAFe

Don’t Let SAFe Fool Yourself

If you have worked with software development for some years, you have probably heard about the Rational Unified Process, RUP. It’s a profoundly prescriptive methodology. But what does that have to do with SAFe? Well, do you know who was intensely involved with RUP? Dean Leffingwell, the same person who created SAFe. That’s why I doubt SAFe has its foundation in Agile.

Have you ever tried to understand how SAFe works? Try looking at the following picture for a minute.

I don’t know about you, but I get dizzy, frightened, and lost when I look at this image. It’s complex to understand and hard to follow. Yet, they have the impertinence of calling it agile. For me, SAFe is, at best, a heavy process. Let’s understand more why SAFe isn’t agile at all, in my opinion.

The first value of the Agile Manifesto is Individuals and interactions over processes and tools. SAFe breaks this value by focusing on processes over individuals and interactions. It segments the communication between teams by creating silos. It’s similar to an assembly line; every part takes care of its responsibility.

SAFe is a process for its own sake. It gives teams the illusion they are in control of their work while killing their autonomy.

Another critical aspect of SAFe is how it falsely combines with other agile frameworks. What SAFe calls ScrumXP has nothing to do with Scrum. SAFe has its own Scrum version, which has a different objective than real Scrum.

With SAFe, ScrumXP becomes a process for feature factories. Agile Teams work exclusively to produce the output previously defined by the Product Manager. This implementation breaks the core of Scrum: empiricism.

Empiricism asserts that knowledge comes from experience and making decisions based on what is observed— The Scrum Guide

When teams are focused on output, they become a feature factory. The only thing that matters is to keep generating output. This approach is not Scrum and will lead to watered-down results.

It’s frustrating to be part of a team focused solely on delivery. I’ve been in such a situation multiple times. The team is responsible for building what will change the end-users lives, yet the team is powerless to decide what makes sense to build. With SAFe, Agile Teams focus on building the thing right, while the Product Manager decides what the right thing to build is.

From my experience, to build successful products, the Scrum Team has to collaborate with the actual end-users. Without that, the team will lack the necessary knowledge to solve problems meaningfully.

SAFe Product Owners Are Product Managers Puppets

SAFe has two product roles, Product Manager and Product Owner, while Scrum has only one. What SAFe calls Product Owner has nothing to do with the Scrum Product Owner. Let’s look at the following table to understand SAFe better.

With SAFe, the Product Owner role focuses on execution while the Product Manager defines what to execute. Looking at the SAFe framework, I got the following.

The Product Owner (PO) is a member of the Agile Team responsible for defining Stories and prioritizing the Team Backlog to streamline the execution of program priorities while maintaining the conceptual and technical integrity of the Features or components for the team.— SAFe Product Owner

Product Owners are responsible for managing the “Team Backlog” while Product Managers call the shots on what to build. I perceive the SAFe Product Owner as a Product Manager puppet. SAFe removed all responsibilities from the Scrum Product Owner and still has the audacity of calling it a Product Owner.

Don’t let SAFe fool yourself. SAFe Product Owner is, at best, a Backlog Manager.

Don’t confuse the Product Owner role between SAFe and Scrum. In Scrum, this role is exciting and full of responsibilities, while in SAFe, it is a mere executor of orders.

From my experience, a key characteristic of effective Scrum Teams is having one person responsible for the product. The role name doesn’t matter; it can be Product Owner or Product Manager; that is irrelevant. But once the structure has multiple roles on the way, e.g., Product Manager and Product Owner, decisions become complex and slow. Confusion is on the way. More people won’t help; on the contrary, it will slow down everything and add unneeded complexity. It’s better to add by subtracting.

I believe it to be a mistake to have both Product Managers and Product Owners working together. When this is the scenario, I’ve only observed frustrated Product Owners and sub-optimal results. I discourage this approach.

A Heavy Process Machine Cannot Be Called a Framework

SAFe stands for Scaled Agile Framework. This definition is senseless because SAFe is highly prescriptive, which goes against a framework definition. When I looked at Cambridge Dictionary, I got the following description for the word framework: “A supporting structure around which something can be built.” SAFe has a process for everything. Therefore, SAFe is a heavy process, not a framework.

To deliver meaningful solutions, teams have to empathize with the real users. Then, they can understand their problems and therefore solve their problems. Well, that’s not how things work with SAFe; the Agile Teams have no contact with the end-users. Still, they are supposed to deliver value. Any similarity with the traditional waterfall?

SAFe is the land of silos. Business people define what is worth pursuing, while Agile Teams produce what is thrown over the fence.

I’ve got another image to highlight how SAFe weakens individuals and interactions.

On a Podcast, Dave Snowden strongly criticized SAFe’s certificate focus; he said:

“… anything anybody wants to buy, Dean puts on the diagram and sells you a certificate in.”

I wonder if SAFe indeed aims to help organizations scale or if it’s all about selling dozens of certificates. I could find thirteen certificates on the SAFe page as of this writing. In my opinion, it’s more complex to learn SAFe than to scale with agile.

I will not prolong my analysis on why SAFe is not agile. I could go on for days. For now, I think you got the point I want to make. SAFe is highly prescriptive and heavy and far from being agile. Don’t let names inside SAFe like Scrum and Product Owner confuse you with fundamental agile frameworks. SAFe is an escape for those afraid of doing what has to be done.

The following image gives you a roadmap to implement SAFe, the undercover waterfall agent. If you still decide to use SAFe, it’s okay. You should keep in mind that you’d be opting for illusional control over a proper agile mindset.

SAFe Is for Those Who Lack the Guts to Embracing Change

In my opinion, organizations that fear significant changes will not embrace true agile frameworks like Scrum. They will opt for a shortcut to become agile. Still, they will never profit from the actual benefits of being agile.

SAFe is an excellent choice for fearful organizations to show the world they do Agile. But also a great opportunity for the competition to embrace real agile and disrupt companies that fail to embrace change.