My issues with SAFe

Scaling Scrum, part 16

Willem-Jan Ageling
Serious Scrum
5 min readJun 5, 2019

--

This is part 15 of the series:

The Scaled Agile Framework (SAFe) is one of the ways to scale Scrum. SAFe is offered to organisations with buzzwords like Agile, Scrum, Lean, DevOps, CI/CD. When it has all that, then it must be great! But is it really?

When I deep-dive into how SAFe translates Agile and Scrum, I don’t see it like that. I have issues with this framework. I aim to explain why I have these issues by looking at the Manifesto for Agile Software Development.

SAFe has many roles

Here are three principles from the Agile Manifesto:

“Business people and developers must work together daily throughout the project.” — Agile Manifesto principle

And

“The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.” — Agile Manifesto principle

And

“The best architectures, requirements, and designs emerge from self-organizing teams.” — Agile Manifesto principle

Now look at the picture below:

This picture shows 12 different roles: Epic Owners, Enterprise Architect, Solution Architect/Engineer, Solution Management, Solution Train Engineer, Product Management, System Architect/Engineer, Business Owners, Release Train Engineer, Development Team, Product Owner, Scrum Master.

Also the picture shows 4 layers: Portfolio, Large Solution, Program, Team.

How can you get these people to work together on a daily basis? How do you achieve face-to-face communication? How do you achieve self-organisation with all these roles?

SAFe has many processes and tools

This is one of the values of the Agile Manifesto:

“Individuals and interactions over processes and tools” — Agile Manifesto

SAFe has these processes: Scrum on team level, Agile Release Trains, Solution Trains, Built-In Quality, Solution Backlog, Non-functional requirement backlog, Solution Intent repository, Economic Framework Guidelines, Portfolio Backlog, Strategic Themes, Portfolio Canvas, Lean Budgets practices, Value Streams.

These processes are meant to lead to interaction. However I believe that the complexity leads to the opposite: a mixture of unclarity of ownership and many processes results into many ineffective meetings in search of alignment.

Where’s the customer feedback with SAFe?

The customer IS on the SAFe picture above. The customer is also in the Essential SAFe picture below. There (s)he barely has a spot though:

The customer appears to be put on the picture to counter criticism that SAFe isn’t customer-focused. SAFe often describes how to bring value to the customer. It also does describe how to create value with constant feedback from the customer. But SAFe also says that you could choose to do this with a customer proxy.

By allowing a customer proxy SAFe opens the door to implement the framework without customer involvement.

Empiricism is under pressure with SAFe

The Agile Release Train sounds really fast. But is consists of multiple Sprints. And the last Sprint is an “Innovation and Planning” Sprint. Which includes integration and acceptance testing. This means that you’d only really inspect and adapt your increment after multiple Sprints. Look at what the Agile Manifesto says:

“Working software is the primary measure of progress.” — Agile Manifesto

With SAFe you typically receive feedback on working software after the Release Train ends, which takes somewhere between 6 and 10 weeks. This is really late for today’s standards. Sure, SAFe allows you to implement software earlier. But the incentives are to only do this at the end of the Release Train.

Also: the feedback loop closes at the end of the Release Train, impeding empiricism. Why? Well the Sprints within Scrum are there to deliver a “Done” useable, and potentially releasable product Increment. This increment is then inspected during the Sprint Review and lessons learned plus additional requests from the stakeholders impact the Product Backlog and the next Sprint. Working in Release Trains of 6 to 10 weeks provides the incentive to organisations to ignore this part and only change course at the end of the train.

With SAFe you run the risk of wasting many weeks of work for multiple teams because of the long feedback loops.

Then there’s the issue of all the roles and events. How do you maintain transparency with all of those?

SAFe <> Agile

I am inclined to say that SAFe isn’t serving Agile. If you wish to profit from an Agile approach I’d argue that you would opt for simpler solutions without all the different layers, roles, procedures and artifacts.

Every added role, procedure or artifact of SAFe negatively impacts transparency. And this negatively impacts opportunities to inspect and adapt.

SAFe is typically adopted by organisations that wish to “go Agile”, but also wish to keep the apparent predictability of roadmaps with exact project end dates.

In other words: organisations that wish to cling to old school project management of delivering a certain scope of functionality within a certain time-frame, but don’t wish to call it that think SAFe is the way to go. I am not alone on this:

“Someone once defended SAFe to me by calling it agile with training wheels. It seemed to make sense at the time but then I tested this logical conclusion: If SAFe is a valid road to true agile then success with SAFe must be moving beyond it.

I’ve looked at SAFe talks, conference synopsis, book highlights and found exactly none of those.” — Leon Krancher

You could argue that SAFe is as much a victim of bandwagonism as Scrum or Agile are. However I think this is not the case. I think that SAFe is consciously created to serve the organisations that find true Scrum too extreme. Or don’t really understand why Scrum exists.

SAFe isn’t how I see Agile. I favour LeSS or Scrum@Scale as frameworks to scale Scrum. But you could also consider not to scale at all.

If SAFe works for you and you get great results with it: I am truly happy for you! I believe that SAFe can function as a way to deliver valuable software. I however don’t see it as a framework that does Scrum and the Agile Manifesto true justice.

Additional reading

For an introduction to SAFe see:

For an assessment of SAFe see:

Thanks for reading. Feel free to bang that clap button. You can give up to 50 👏’s. Give it a try if you enjoy this article!

My twitter profile is https://twitter.com/WJAgeling

Do you want to write for Serious Scrum or seriously discuss Scrum?

--

--

Willem-Jan Ageling
Serious Scrum

https://ageling.substack.com Writer, editor, founder of Serious Scrum. I love writing about maximizing value.