Many organisations are lured to SAFe by the song of the Sirens

I am disappointed by the lack of knowledge and evidence behind an official scrum.org post. Most recent posts were extremely valuable, this feels like an article that could have been written by the Donald Trump of agile.
I would happy to have a discussion with you on what SAFe is about so you can write an informed critic.

@arnaudlhte:disqus you sound upset, and if you are invested in SAFe, you may feel attacked by this post, and I am sorry for that. This article is an "opinion piece" and represents my opinion.

As a DevOps and Agile consultant, I have encountered SAFe on many occasions, both during implementation, and years after. I have read the material around SAFe as well as Deans book. I tell you this so that you can understand that I am making this post with first had experience both in how SAFe is implemented, how it is taught, how it is marketed, and the aftermath of rigid authoritative practices that it leaves in its wake. There is no agility there.

As I referenced in my article the head of the US Airforce, arguably one of the most rigid organisations in the world describes SAFe as "rigid, prescriptive framework" and points out that "SAFe isn't used by any successful software commercial organisation (Facebook, Google, Netflix, [Microsoft])." That in itself is damming of SAFe but is after all also only an opinion.

I grant that over the years SAFe has relaxed some of its rigidity in favour of choice. While that is laudable, it is a little like putting lipstick on a pig, and it can't change the roots and growth of SAFe as a large scale prescriptive and rigid bureaucratic practices with a different lexicon.

I can perfectly relate to the fact that there are pathologic SAFe implementations just like there are a lot of Cargo Scrum implementation. Thinking about SAFe as a prescriptive framework means that this people have not understood the essence and the ideas behind SAFe which rely heavily on Lean Thinking, the Agile Manifesto and System Thinking. As a matter of fact I had people from Amazon in my SAFe trainings and in my SPCT cohort there was an Internal SPCT candidate from Microsoft. As for Google and Facebook I doubt they use scrum either and based on their structure and history they probably do not need SAFe either. Is it really a criteria that something needs to be used by Facebook or Google to make it useful ? Sounds like the Packagings in the shop that say "Seen on TV" as a quality attribute.
As a matter of fact there are a lot of company that are getting better results than before by using SAFe principles as their guiding principles. You can find those on the scaled agile framework Website under case studies.
Maybe you want to share some of your thoughts as to what aspects of SAFe make you think it is rigid and prescriptive with some stories from the field. One of the principles in SAFe is that you want to base discussions and improvements on facts so let's share some observations.
If you prefer we can have a direct conversion via Zoom or the like and then publish the results of that conversation as a joint post.

Thanks, Martin. I like a good rant, because it's always helpful to self-reflect.

From your post, I got that you are warning to use SAFe in general, because it does not seem to help companies in your opinion.

And I have questions here. Maybe too many questions to answer here. I'd be glad though if you can reply to one or two things that stand out for you.

Since my attempts to make myself heard have now been marked as spam several times, I'll try to split the message into smaller chunks.

Full Disclosure

I have used SAFe successfully (I think - I never got the chance to do a side-by-side comparison).
I have worked a lot with SAFe over the last eight years and I am still turning to it for questions that go beyond the scope of the Scrum Guide.
SAFe has helped me, because it provides a fairly coherent body of practices and terminology on a great number of topics.

Using SAFe, I was able to explain how to rethink things like budgeting, planning, working with roadmaps, to decentalise decision-making and a lot more. It has helped with decentralised organisation development as well, because people could turn to SAFe as a north star and start changing ways of working in their area in the spirit of the Agile Manifesto themselves. This might have been a lot harder for them without SAFe curating the practices or with just the Scrum and Nexus Guides in their hands.

I have used SAFe to also meet the people "a half-step ahead", as Lyssa Adkins puts it in "Coaching Agile Teams" (2010). Explaining agile economics with SAFe's principles has been a lot easier for me than when I tried to show less prescriptive (and descriptive for that matter) material.

That being said, there is almost always a way to simplify things. And SAFe's 400-page manual is probably no exception. So, I am eagerly willing to learn. Ok, on to the questions.

Throwing Money at the Problem

To me, what resonates well in your post is that you point out an antipattern of just throwing money at a complex problem of value creation that you merely understand, expecting good outcomes ("spend a few million dollars and pow").
And from my perspective, SAFe does not advocate this. Instead, in the topic "Identify Value Streams and ARTs" (can't post links to SAFe website, because the comment will be flagged as spam) , SAFe recommends to really look into your value creation system from a customer perspective and to recreate the organisation from those results. This is hard.
I have seen a lot of people skipping that hard part and coming up with disappointing SAFe implementations. But I have also seen teams of teams thrive once they had gone through that process.
So, to me, this rather seems like an "easy to explain, extremely hard to master" situation: It's hard to get the practice right. And it might not be the practice's fault (or the framework's). Do you see it differently? Where is SAFe saying that it's offering an easy path where you don't have to think, act or change?

SAFe, Taylorism and Rigidity

When I read that to you, SAFe resembles Taylorism and imposes the rigidity of best practices, I was feeling confused. To me, the short version of Taylorism is "one brain, many hands". Where do you see that pattern in light of SAFe's principle #9, "Decentralize decision-making" (see SAFe website) and the (indeed rigid) prescription to always "inspect and adapt" (see SAFe website)?
How is SAFe being rigid if you are mandated to always inspect and adapt? How is this different from Scrum's rigid prescription to do retrospectives and to plan actions from their results?

On the Applicability of Frameworks

Your statement "You can't take someone else’s framework that worked in their organisation, like SAFe or Spotify, and install it in your organisation." is something that has bothered me as well. I am asking myself how this is different with the Scrum framework. Should we stop using Scrum, because it is a framework and it has worked "in their organisation"?
Is there evidence that you can't make informed and context-aware use of frameworks that worked elsewhere? I am not aware of any such research. Can you please shed some light on where to draw the line between frameworks that are applicable and frameworks that are not?

SAFe being Prescriptive

I found the Air Force's judgement about SAFe being prescriptive surprising. As I understand SAFe, most parts of it are optional, i.e. non-presctiptive. Only the parts in the SAFe Essential configuration (see SAFe website) are considered mandatory, everything else is considered optional. Ok, it's still a lot more text than with the Scrum and Nexus Guides combined. At the same time, SAFe's scope seems more broad to me.
In that light, do you share the Air Force's conclusion that SAFe is overly prescriptive?

TL;DR

This was a long reply. I think I have a very different view on the downsides of SAFe. I like to think that you can use SAFe in unfortunate ways - ways it was not intended to be used. You can also use SAFe in very fortunate ways. And the same seems to be true with Scrum.
I fail to see most of your criticisms towards SAFe as being inherent to SAFe. But I might be wrong. I have been before. I hope to learn a lot from your reply.

SAFe as sold, and as implemented in every occurrence I have encountered, is a complete solution that is installed in an organisation and sold to the board for millions of dollars. That was its intent upon creation, and its expected implantation based on Deans actions to date.

That you as an individual have decided to use it as a reference of many practices is awesome, and exactly how I use it. Traditional Tayloristic (waterfall) also have their place and value.

I would say that you are the exception and you are using it outwith its intent. Which is good.

To be transparent that was a direct quote from the head of IT at the USAF, which I happen to agree with.

You are mandated to inspect and adapt within the bounds of SAFe. It has many practices that while it now, after many years of rigidity, offers more flexibility, that was NOT its original intent. It has baggage, and is a mess of bureaucracy. I have yet to see any organisation that has implemented SAFe, or hear of one, that has replaced bureaucracy with flexibility.

Wile SAFe has the word Framework in its title it is a methodology.

I'm fine with folks not using Scrum. That's ok, and the Scrum Framework is not agile in itself. It enshrines the minimum one needs to implement one type of Empirical Process Control System. That's It.

The rest is up to you. However I will grant you that many people also use Scrum bureaucratically, however that it not its intent. The opposite of SAFe.

The optional thing is new. SAFe has always been, as implemented by its founder and his disciples, a prescriptive complete methodology for managing the work in your business.

Like I said in my post, I accept that SAFe is moving towards optional, and less bureaucracy, however his foundation, origin, and birth are based on tayloristic prescription that you must do it Dean's way.

While I agree that SAFe can be used in fortunate ways, I believe that its foundation and intent, by default, without an awesome implementer such as yourself, is to impose large scale prescriptive pain and suffering on an organisation.

That is from my experience being in organisations in the US after Dean himself, and many others.

I also know many folks like yourself that are doing good work and not implementing SAFe as intended, but using it as a vehicle for agility.

I neither said that SAFe had no value, or that some companies did not do better under SAFe than what they were doing before. At least under SAFe they are looking at value streams and thinking about how they spend their money.

However they are doing it, as Dean intended, in a prescriptive manor. It is not an organic process that results in something that fits a organisations business like a glove but a jarring big bang change.

"SAFe isn't used by any successful software commercial organisation"

This is still true, and tells us plenty. The Scrum Framework is used by many successful software commercial organisations, but the processes and practices around that core is custom fit, not out-of-the-box like SAFe.

Thank you for the clarification.
I have never had contact to people where their organisations decided to implement SAFe as a complete solution.
Whenever I met people from Scaled Agile, I was able to have constructive conversations with them about the incremental approach we were taking at the company I work for. I never perceived them as people trying to lure me into something that's not fitting company purpose. Quite to the contrary, indeed. Well, experiences differ I guess.

I am struggling with this one as well.

Yes, using (predominantly Scrum and SAFe) agile practices, we have been able to free ourselves from a lot of documentation that no-one ever really needed (e.g. producing project-specific test plans and tons of documentation for toll-gates). We're basing much more work on face to face communication now.

And still, it still *feels* like a lot of overhead (an energy drain very similar to bureaucracy), because there's now a lot of big room meetings with many people. It's hard work to keep the energy up at those events sometimes (although participant feedback is usually positive - people are still learning a lot about their work context).

My analysis is: Yes, we have gotten rid of bureaucracy using SAFe, having replaced comprehensive documentation with direct communication. And we still have to work on reducing dependencies to make coordination meetings smaller or to make most of them go away. That is also driving flexibility, as it is a function of independence.

For me, it also has a lot to do with the Shu Ha Ri concept. Following that, if you meet an organisation in Shu, it might be advisable to make use of some rigidity when introducing new ways of working. Wax on, wax off. Repeat :)

I have tried to introduce Scrum to people who never had worked based on agile values and principles. I was coaching rather than training and drilling. I failed miserably and left everyone confused.
Thus, I now try to be very rigid when I meet people and teams being in Shu presumably. It works better. And it's a lot harder for me as a person - telling others what to do, process-wise.

So to me, rigidity and bureaucracy seems not to be bad in itself. It's just very dependent on context whether it's a good idea or not.

True, the Essential SAFe concept has not been there from the start in 2011. If I remember correctly, it was introduced with SAFe 4.0, about January 2016. Since then, SAFe has this relatively small core and lots of optional practices around it.
Sure, it's a short period compared to Scrum's history. And for me, working with SAFe so much, it feels like it has been there for ages. This is probably why I am percieving it so differently.

Thanks Martin for taking the time to add more context by replying. As I was hoping, I have learned a lot.

To me, it's always important to check back with agile values and principles before I am planning interventions in my organisation development work. Blindly applying methodologies, frameworks or even practices is hit or miss. And still, having a comprehensive body of practices can help a lot to improve the workplace for people and outcomes for customers.

@realsimonb:disqus that is the only adoptions of SAFe that I have seen. I am super happy that you are spreading the incremental organisational evolution story :)

I am writing a post on that now, that I would appreciate your feedback on: https://nkdagility.com/?p=4... (very work in progress.)

You are a rare gem and I appreciate your time in responding to this post :)