When is SAFe appropriate to use?

Erwin van der Koogh bio photo By Erwin van der Koogh Comment

Ever since SAFe hit the Internet as a ‘best practice’ of scaling agile in large enterprises I have opposed it. Well, let’s be honest here: I detested it.. I didn’t hate any of the processes or practices (although I am not hugely in favor of all of those either), but to the implicit message that software development can be fixed by top-down imposing of a standardized process. But you don’t learn anything from just hating something, so recently I forced myself to ponder the question: “When would it be appropriate to use SAFe?”

The answer quite surprised me.

The Choice

Many organizations on their Agile journey get to a Y-junction. It is the point after a few isolated teams have made quite some progress with Agile practices and the decision has been made to ‘Roll Out Agile’ across the IT department.
But after a while the trouble starts and the honeymoon period is over quickly. Agile practices are running into the organization’s waterfall governance model, the first ‘Agile’ project has a budget overrun and many stakeholders are feeling they are losing control.

This is often called WaterScrumFall. We still initiate projects, with big upfront estimates for both benefits and costs. Development is then done agily with Sprints/Kanban boards/Daily stand ups. Sometimes even part of business analysis and testing are integrated into the sprints, but the overall picture still has only 1 or 2 big releases during the project.

Not only is this phase very counter productive, it is also a very painful phase. Teams & especially Project Managers are squeezed between the Just In Time nature of Agile and the Big Upfront Estimates from waterfall governance; Project & Line Managers often don’t see a place for themselves in the new order; team members are still bounced around projects and more and more projects are late & over budget because estimates were given on high level requirements instead of details designs.

It is at this point that an organization has to choose to:

Become Agile

The first option is to push through and become really agile. This means realizing Agile is a) a culture & mindset shift and b) it involves the entire organization, not just IT.

That means aligning your development teams much more closely to your business partners and giving both a lot more autonomy over not just how they work, but also over what they work on.
I wrote an entire article about it here.

Go back to Waterfall

An organization can only be at the crossroad for so long. If you don’t want to let go of projects, traditional IT governance and (fake) certainty, your only options was to go back to waterfall. It usually has some of the appearances of Agile when looking for outside, but for all intents and purposes it is back to a waterfall.
You are back to big upfront estimates based on more and more detailed designs with very little added business agility.

Before SAFe this was your only other option besides become truly Agile.

Adopt SAFe

SAFe actually is a third option. It doesn’t really require you to change your culture or mindsets and it has minimal impact on the rest of the organization. It does however solve two extremely important problems: Projects & Teams.

There are no real projects in SAFe. Investment decisions are made on what they call Investment Themes. Which means less focus on budgets and more focus on actually delivering value and value streams.
And as far as I can tell their Agile Release Trains (one or more development teams) are fairly stable. So no more roll-call at the daily stand-up to see if all team members are still on the project.

And as an added bonus you get a some focus on architecture for free.

Now don’t get me wrong, I still think SAFe is a sub-optimal solution. It is the right answer to the wrong question. Your organization probably does not need all that process, it is still has a lot of overhead and because it was adopted as-is it will hinder organizational learning. And while it probably will improve your business agility, I don’t see it being enough to survive & thrive in the 21st century.
And as long as you realize SAFe isn’t actually a Scaled Agile Framework, but a Scaled Software Delivery Life-cycle, it is actually pretty OK.

So to summarize I think: “SAFe is great for companies trying to delay their inevitable demise.”.
Hopefully long enough to change their mind about becoming truly Agile.