Watch Out, Waterfall Ahead! The Truth About SAFe.

I don’t understand this phenomenon. A waterfall methodology that pretends to be an Agile framework. Yet, people still “buy” it.

Paweł Huryn
Agile Insider

--

Every time I see this diagram, something dies inside me:

Source: https://www.scaledagileframework.com/; © Scaled Agile, Inc.

Let’s not be deceived. Calling a wolf a sheep doesn’t make him a sheep. SAFe is just a marketing name for the full-scale waterfall, which has nothing to do with Agile or Scrum.

Marty Cagan, author of “Inspired,” said:

“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 individual components of SAFe in detail.

SAFe building blocks

SAFe is based on a few simple assumptions. It goes like this:

Waterfalling the requirements

The Product Manager collects the requirements and waterfalls them to the Product Owners, who work with the teams (“dichotomy of accountability”).

“As the internal representative of the customer, product management leverages market research and Continuous Exploration to continually understand customer and market needs. Design thinking tools, ranging from personas, empathy maps, journey maps, and story maps are used to communicate these to the ARTs” —https://www.scaledagileframework.com/product-management/; © Scaled Agile, Inc.

Source: https://www.scaledagileframework.com/product-owner/

Backlog management

Product Owner (SAFe’s term for a team’s backlog manager) and the team are focused on the solution and, in practice, are disconnected from the users. Product Owner spends long hours writing detailed specifications.

“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” —https://www.scaledagileframework.com/product-owner/; © Scaled Agile, Inc.

If you are used to working in Scrum, you may be surprised. Each team has its own team’s backlog.

Source: https://www.scaledagileframework.com/team-backlog/

Untrustworthy developers

According to SAFe, Developers 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.

“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 also assures a level of quality, focusing primarily on fitness for use” —https://www.scaledagileframework.com/product-owner/; © Scaled Agile, Inc.

Source: https://www.scaledagileframework.com/built-in-quality/

The output is king in SAFe

In SAFe, there is no time to think about the outcomes. The highest priority is keeping people busy. This way, everyone can be better “utilized.”

“Product management supports the flow of work through the program Kanban and into the program backlog, responsible for ensuring enough features are ready in the backlog at all times” — https://www.scaledagileframework.com/product-management/; © Scaled Agile, Inc.

In the land of SAFe, the output is king. Plans with “deliverables” extend up to 3 years.

“The solution roadmap provides a longer-term — often multiyear — view, showing the key milestones and deliverables needed to achieve the solution vision over time. While most solutions require a 1–3 year view, some larger solutions may extend this timeframe to many years” — https://www.scaledagileframework.com/roadmap/; © Scaled Agile, Inc.

Source: https://www.scaledagileframework.com/roadmap/

Following the plan

The main goal of “inspection and adaptation” in each Sprint is ensuring everyone follows the plan. It gives managers a false sense of control.

Don’t be tricked. A small buffer (aka “uncommitted objectives”) is no different from waterfall buffers. Every waterfall company did the same in the past. “Add 30% to the estimation, and we are safe” — do you know this phrase?

“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” — https://www.scaledagileframework.com/PI-objectives/; © Scaled Agile, Inc.

Source: https://www.scaledagileframework.com/pi-objectives/

From my experience, this has never worked. We don’t even know if the “committed objectives” are the correct ones. As Marty Cagan states in “Inspired,” most ideas in product management are wrong; others require at least a few iterations to produce the expected value.

Abandoning Scrum

There is neither Scrum Team nor Scrum in SAFe. SAFe (undercover waterfall agent) implements its feature-factory version of the framework while confusing projects with products. That level of ignorance (I don’t want to call it a lie) is staggering:

“ScrumXP is a lightweight process to deliver value for cross-functional, self-organized teams within SAFe. It combines the power of Scrum project management practices with Extreme Programming (XP) practices” — https://www.scaledagileframework.com/scrumxp/; © Scaled Agile, Inc.

Have you ever seen an Agile train? If it ever existed, it must have derailed trying to change direction. Once PI Plan is defined, the release train must ruthlessly follow the planned route.

Source: https://www.scaledagileframework.com/scrumxp/

Conclusions

Have you ever seen a self-managing team that decided to work in SAFe? You don’t have to answer this question.

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 substantial, but now they can call themselves “Agile.”

It’s not a 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.

Liked this story?

There is a lot more unique product content I publish only on Substack. Check my product newsletter, with actionable tips and advice for PMs: 👇

--

--

Paweł Huryn
Agile Insider

Join 50,000+ and get 1 actionable tip for PMs every Saturday: www.productcompass.pm