Watch Out, Waterfall Ahead! The Truth About SAFe.
I don’t understand this. A waterfall methodology masquerading as an Agile framework. Not applicable to modern product management. And yet, companies still take it seriously.
Hey, Paweł here. Welcome to the free edition of The Product Compass.
Every week, I share actionable insights and resources for PMs.
If you are not a subscriber, here are a few posts you might have missed:
Product Model First Principles:
Product Management vs. Product Marketing vs. Product Growth 101
Consider upgrading your account, if you haven’t already, for the full experience:
Why did I write this post?
I first shared my critical thoughts on SAFe on July 15, 2022.
In 2023, Scaled Agile blocked my Medium article due to "copyright claims” and sent me an official letter – unexpected, especially considering they mashed together elements under the Attribution Share-Alike license.
After a rollercoaster of emotions, I won the argument, and my article was restored. But later, I removed 90% of my Medium posts to focus on Substack.
In this issue, I'd like to revisit the topic and provide a few fresh insights on the new SAFe 6.0, as some of you are struggling with it. For others, this might be a warning when looking for a job.
Above all, it’s a list of things to avoid when managing products.
Watch Out, Waterfall Ahead! The Truth About SAFe.
I don’t understand this phenomenon. A waterfall methodology masquerading as an Agile framework. And yet, companies still take it seriously.
Every time I see this diagram, something dies inside me:
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F276f6770-8177-443a-817c-cd7a1857dd76_1041x707.png)
Let's not be fooled. SAFe (Scaled Agile Framework) is a marketing name for the full-scale waterfall and controlling people with a heavy process. Phrases like “Design Thinking,” “Lean UX,” or “Scrum” are just smoke and mirrors.
I agree with Marty Cagan, who wrote in 2018:
“Over the past few years, a number of companies have asked me about this notion of processes that focus on “Agile at Scale,” the most heavily marketed (judging in part by the amount of spam I receive) such process is SAFe (…)
Normally I only write about processes and techniques that I can vouch for first-hand. The problem here is that I don’t personally know of a single leading tech product company that is using SAFe (…)
A couple years ago I wrote about the root causes of product failure in product companies and I identified ten key attributes of Waterfall and project-mindset. I went through and compared this list with SAFe, and literally all ten problems exist in SAFe. Indeed, I would argue that all ten problems are inherent in that process.”
Let's look at the components of the new SAFe 6.0 to see if anything has changed.
In short, it goes like this:
Waterfalling the requirements
In product, we understand that empowered teams are given meaningful problems to solve and are held accountable for the outcomes. I discussed that in Product Team Principles and Objectives and Key Results (OKRs) 101.
But in SAFe, every quarter, teams gather for two days of "PI planning." Thay start with:
“Inputs to PI planning include:
Business context (see ‘content readiness’ below)
Roadmap and vision Highest priority
Features of the ART Backlog”
– PI Planning, © Scaled Agile, Inc.
By the end of the PI Planning, the team commits to specific features:
“The team’s PI objectives often relate directly to intended features. Many are the same. However, the mapping is not always straightforward since some features require the collaboration of multiple teams”
– PI Objectives, © Scaled Agile, Inc.
It’s clear that SAFe promotes working in 3-month waterfall projects with predefined outputs. It’s just a feature factory.
The PM vs. PO dichotomy
As explained in Product Owner vs. Product Manager, Product Owner is not a job title.
When you split the roles:
Product Manager talks to the business and customers.
Product Owner (“backlog administrator”) works with developers, collecting and documenting “the requirements” and inspecting their work.
I consider this one of the worst anti-patterns in product management.
On the SAFe website, we can find a vague claim that the Product Owner can contribute to the Product Management function:
“As a member of the extended Product Management function, the PO (…)”
– Product Owner, © Scaled Agile, Inc.
But in practice, SAFe Product Owners focus on delivery. They spend long hours writing detailed specifications and do not even have to talk to the users:
“Customers may be internal or external to the enterprise and may have direct or indirect relationships with the PO.”
– Product Owner, © Scaled Agile, Inc.
A team of doers
As explained in Product Trio: Beyond the Obvious, Product Discovery is not a task for a single person.
For Product Discovery to work, we need a cross-functional collaboration, typically a Product Manager, a Product Designer, and at least one Engineer (“The Product Trio”).
In particular, the best ideas often come from Engineers:
“(…) if you’re just using your engineers to code, you’re only getting about half their value”
– The Most Important Thing, Marty Cagan
Unfortunately, in SAFe, Engineers are largely disconnected from discovery. Product Managers perform a waterfall discovery to fill the ART backlog with work before the next quarter.
“For some solutions, the Product Management function may be carried out by a single Product Manager. For others, a team of Product Managers may be required (…)
Product Management (…) Conduct primary and secondary research (…) Understand end-user needs (…)
What’s worse, they communicate with the team through the PO proxy:
“Product Management synchronizes frequently with the Product Owners of those team”
– Product Management, © Scaled Agile, Inc.
“(…) PO is the team’s primary customer advocate and primary link to business (…)”
– Product Owner, © Scaled Agile, Inc.
Engineers and Designers are not even considered “key collaborators”:
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fc451c898-c790-45a9-8a13-b752e8a2a0dd_600x583.png)
Untrustworthy engineers
As discussed in The Product Leadership Playbook, nobody enjoys being micromanaged. Autonomy and trust enable creativity and provide deep, intrinsic motivation.
In No Rules Rules, Reed Hastings and Erin Meyer highlight the most critical aspect of Netflix's culture - leading with context, not control.
But according to SAFe, Engineers can’t be trusted as professionals. The Product Owner reviews and approves their work and ensures that what they have provided is not sloppy work:
“Accept Stories – The PO works with the team to agree on accepted story completion. This includes validating that the story meets acceptance criteria, that it has the appropriate, persistent acceptance tests, and that it otherwise complies with its Definition of Done (DoD). In so doing, the PO assures that quality is built in.”
– Product Owner, © Scaled Agile, Inc.
Following the plan
SAFe claims to split the quarter into iterations. But in practice, the main goal of “inspection and adaptation” in each Sprint is to ensure everyone follows the plan and that committed features are delivered. This gives managers a false sense of control.
Don’t be deceived. A small buffer (aka “uncommitted objectives”) is no different from waterfall buffers. “Add 30% to the estimation, and we are safe” — sounds familiar?
“Committing to, and delivering, a series of short-term objectives helps to build trust (…) Things don’t always go as planned, and it’s simply prudent to build some small amount of buffer into the system”
– PI Objectives, © Scaled Agile, Inc.
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F58f9c7ac-099d-4627-b045-702a2cb2813f_585x325.png)
From my experience, this has never worked. We don’t even know if the “committed features” are the correct ones:
„The first truth is that at least half of your ideas are just not going to work”
– Marty Cagan, Inspired
Waterfall discovery before the PI begins doesn’t change that, as most features require several iterations before they work as we hope.
Derailed train
As a PSPO III, I want to emphasize that there is no Agile, Scrum Team, or Scrum in SAFe. Yes, SAFe uses some of those terms, but it implements its feature-factory caricature of Scrum with what they call an “Agile Release Train.”
Have you ever seen an agile train? If it ever existed, it must have derailed trying to change direction. Once the PI Plan is defined, the release train must follow the planned route.
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2Fe306d5fa-ac91-4ccf-86ed-f2ed188b3d5a_714x464.png)
Conclusions
At the end of the day, managers are delighted. They have paid a lot of money to consultants, the transformation was lightning-fast, and everything looks different on the surface. They don’t have to change anything that matters, but now they can call themselves “Agile.”
It’s no coincidence that SAFe was created by the same person who made the Rational Unified Process (RUP). In my opinion, no buzzword (Agile, Scrum, Lean, Enterprise, etc.) can cover its true nature.
I understand that talking about SAFe can be frustrating. This discussion should have been resolved many years ago. No successful, innovative product organization (Meta, Google, Airbnb, Dropbox, Uber, Apple, etc.) uses that methodology.
Unfortunately, many of my readers struggle with it.
If you find yourself in this situation, know that you are not alone. This might help:
And if you are a decision-maker, I recommend you read The SAFe Delusion: Information for decision-makers considering the SAFe framework
Announcement: SVPG & The Product Compass
Our graphics have become the official part of SVPG training materials 😊
![](https://substackcdn.com/image/fetch/w_1456,c_limit,f_auto,q_auto:good,fl_progressive:steep/https%3A%2F%2Fsubstack-post-media.s3.amazonaws.com%2Fpublic%2Fimages%2F4b7fd7dc-5907-4053-9df2-f0e5fc23cbce_1170x878.jpeg)
You can read more about the Product Operating Model and download our graphics here: Product Model First Principles: Product Team and Product Strategy In Depth
Thanks for reading The Product Compass
I appreciate it! It’s amazing to learn and grow together.
Your comments, reactions, and private messages motivate me to continue working.
Next issue (the title might differ): Leveraging AI in the PM’s work.
Have a fantastic weekend and a productive week ahead,
Paweł
SAFe remains the safest way of failing agility.
You may get the label, but not the results.
You will have control of the process, not the outcomes.
Everything is predictable, but driving value.
Don't let the undercover waterfall agent fool you.
A heavy process isn't an alternative to agility.
300% agree and have been fighting this buzz in my org for the last year+. Curious to what you would point leaders to on how to accurately scale an agile product organization?