Is SAFe REALLY Safe?

The Scaled Agile Framework, or SAFe as it is more widely known is very popular in larger, more traditional, organisations. It is also widely disliked by long-term agile practitioners and agile experts, including some of those that defined what Agile means in the context of software. So what is the Scaled Agile Framework, and why is it popular with traditional orgs, and disliked by agile experts? SAFe describes lots of practices and roles like scaled agile product owner, scaled agile deployment pipelines and release trains and it is a big seller of SAFe agile training and accreditation programmes.

In this episode, Dave Farley, long-time agile practitioner and author of best-selling books “Continuous Delivery”, “Modern Software Engineering” and “CD Deployment Pipelines” explores what SAFe is, asks if it can achieve what it sets out to achieve - is it safe?

-

⭐ PATREON:

Join the Continuous Delivery community and access extra perks & content!

-

-

👕 T-SHIRTS:

A fan of the T-shirts I wear in my videos? Grab your own, at reduced prices EXCLUSIVE TO CONTINUOUS DELIVERY FOLLOWERS! Get money off the already reasonably priced t-shirts!

🚨 DON'T FORGET TO USE THIS DISCOUNT CODE: ContinuousDelivery

-

BOOKS:

and NOW as an AUDIOBOOK available on iTunes, Amazon and Audible.

📖 "Continuous Delivery Pipelines" by Dave Farley

NOTE: If you click on one of the Amazon Affiliate links and buy the book, Continuous Delivery Ltd. will get a small fee for the recommendation with NO increase in cost to you.

-

🖇 LINKS:

-

CHANNEL SPONSORS:

[sfulibarri]

I've personally worked in two separate orgs that were brutalized by SAFe consultants, resulting in mass layoffs or turnover. My experience was so horrible that I've since made it clear to every new manager or PM I have that the moment the company brings on a SAFe consultant or begins trying to implement anything that looks like a 'release train' is the same moment my next job search begins. SAFe is literally the meme of spending more time moving jira tickets around than writing code or building products except explicitly codified in processes that span the whole IT org with a handful of dev managers and product owners empowered to enforce the processes at all costs. Its no mistake that every one of those people who were given that authority went on to become SAFe consultants themselves.

[hallabrokokko]

I wouldn’t touch SAFe with a ten-foot pole. Shitty Agile For Enterprises is an acronym that makes a lot of sense.

[TimJW]

SAFe is for a few of things:
(1) Sell certification
(2) Keep project managers in jobs
(3) Give senior management warm fuzzies that they have "implemented agile"

When you look at the SAFe diagram, dev and engineering teams are somewhat diminished with the ART etc taking priority and the customer is an afterthought.

[Rbx]

The waterfall is not dead. Every day it rises from the ashes, but now in the form of agile-waterfall, whenever someone says "we need to improve our estimates".

Dave, thank you so much for sharing this. Your book is awesome!

[nowanilfideme]

Agile is an adjective, not a verb or a noun, but yes I agree with you. :D

[Mrdust]

From a systems perspective, SAFe® is successful as a framework to be sold because it keeps the social system of the middle management in place, as described by the Larman's law. The system would usually try to keep itself alive by reacting to any change in its environment accordingly.

SAFe® seems to be the safest way for this system to preserve itself why addressing stakeholders' demand for agility.

[AlexA-rcyk]

SAFe does have some advantages for larger enterprises. I work for a company that has about 40 agile teams, about half on the backend, and the rest on device software. Previously the teams would all individually move faster... but wouldn't be organized, so enterprise level features (multiple device teams + multiple backend teams) could take a LONG time to "get to market".

SAFe let us get the backend teams to work on the features that were important this quarter (program increment) so the backend development would complete more quickly.


Here's an imperfect analogy-- your company sells cars, and your sales team just won a big contract to make one of the models of cars go faster.

Pre-SAFe: The engine team runs with this immediately. At the end, they ask the wheel, brake, and suspension teams how they're going. The other teams go... what? We have our own priorities, maybe we can get to that next quarter. After a year, everyone gets their act together, the feature is tested, and then the cycle repeats to deal with the multi-subsystem bugs.

Post SAFe: In PI planning, upper management tells us that the "speed" feature is a priority. Prior to the PI, the architects realized that the engine, wheel, brake, and suspension would need updates. During PI planning (ideally beforehand) they estimate their portion, and that capability is part of their backlog for the PI. The feature (including engine, brakes, wheel, and suspension) is tested end to end. There a less bugs found, and the one found are easier, because we're fresh off implementation-- we don't have to review the parts from scratch.

So... SAFe means that individual teams don't get to work on as many of their priorities, it means that big features that our customers are demanding are available to customers sooner.

[Immudzen]

One thing that SAFe has been good at is giving me cover to introduce more agile methods to our process. We are definitely not fully there because that is just too much stuff to change quickly but our processes keep getting better over time and our results continue to improve.

[nwalsh]

I was a solution architect in a SAFe project at a large company. It was the first time they did something like this and they shoehorned SAFe, Agile, SCRUM and DevOps into this massive project and expected wonders like less headcount since the developers would do Ops-stuff (wrong) and full control and cost predictability like in a waterfall project. And the rest of the organisation was not like this at all... so when we needed changes in the communications infrastructure for a feature, we had to wait for two weeks while that team worked their waterfall process.
Barring all the other things that happened, I got turned of SAFe rather profoundly when I started to read about how it was supposed to work and how it didn't. Artefacts there needed to be produced but never went anywhere and a disconnect with the developers not supposed to talk to me and me to them unless it is cleared with a manager. Overall, at least they way it was implemented we had more managers on the projects than people actually doing anything. Four developers, one architect, three Business Analysts, three Program Owners, two business liasons, three project managers and scrom masters and two lead managers. Totally mad. So when I see SAFe these days, I try to steer clear.

[fennecbesixdouze]

The reason they want predictability is because they want to to be in total control. They want to know exactly what will be produced, by exactly when.

Successful companies have long moved past that, they now instead seek out business opportunities, and they then hire a motivated technical team to pursue those opportunities. They give up control of "what" and instead trust and enable the technical teams instead to work out what the best technical thing to pursue is in order to the advance the objectives.

Early on in Agile, the true successes came because management and executives who used to hold iron grips on timeline and scope relaxed scope while holding onto timeline. These days truly successful companies also give up control over timeline as well to the technical teams: they do the business research, and then present to the technical teams the question of whether it would be appropriate to put in more technical effort and delay market releases. They also do the business work of checking whether the market is ready for them, whatever state their technical code is: sometimes the same product will be more successful if you delay it for more favorable business conditions.

[manishm]

I worked for a company recently that is heading towards SAfE, though not fully implementing each practice like release trains. It was something that management loved but lead to poor software:
- it gave middle and senior management a feeling of control and planning via story point tracking and increment breaks, but disconnected teams so much from customers that we had no idea if we were delivering value
- team composition and ways of working were set by middle management, with a facade of delegation to teams (who had only limited freedom to decide how to implement features)
- because of the hierarchy, although we had cross functional teams we had only one ops expert in the whole division (~50 people) and no one was incentivised to take ownership of system maintenance/support
- the central planning/control also led to chaos when a critical system went down, but developers weren't given access or support to either help with the outage or build workarounds (my colleague and i were expressly forbidden from working on other ways of testing - so our entire team couldn't test any code for 5 weeks)

Uggh, i think i'd rather deal with waterfall 🤣

[azog]

One thing to remember about SAFe is that in order to get certified you have to go on a training course given by Scaled Agile Inc. This company must be making money hand over fist by selling training courses to enterprises, which is probably the main reason for inventing SAFe.

[RealDicko]

Lego did an amazing video called "is safe evil" that I highly recommend. It kind of works for them because engineers need to interface and coordinate with a lot of other teams that aren't agile (marketing, animation, etc).

[AmiGanguli]

I just had my first experience with SAFe this past year. It was a complete train-wreck. Basically, they took practices from waterfall, gave them agile-sounding names, and pretended they were agile.

This is obviously just my anecdotal experience, but I did a bit of research after encountering SAFe. I was baffled that any company worked this way in 2022, and I thought that surely it must just be a poor implementation of the methodology. But the more I looked into it, the more I found people with similar experiences. SAFe is clearly snake-oil.

[vanivari]

Projects rarely suffer from something where SAFe has a solution to offer. These agile coaches are usually nice people, but they are often detached from actual software development and any code for over a decade (or are fresh from university) and never implemented code themselves in an agile project. And for some reason they think, that if SCRUM is just organized enough and religiously followed enough, high software quality and high speed is achieved, but SCRUM doesn't care about quality at all. It's often a Cargo Cult.
I can't take SAFe serious anyways since i'm a certified SADMF (scaled agile devops maturity framework). If i just hear "release train", i ask: "isn't a release convoy better?"
Just today my company pushed SAFe and an agile coach into my new (greenfield) project and the talk about release trains started within 10 minutes not because we need it but because a manager likes it. So once again i have to convince people to not slow us down with waterfall milestones, processes, branching concepts etc. It's completely unnecessary for our backend services, which will be fully tested automatically after each commit, canary released and automatically monitored. So basically we ignore SAFe as much as we can, but will be part of another SAFe success story.

[Oliver-rhbv]

My feelings about why SAFe was introduced in my company was that we have been (very) late on delivering on time what was written in a customer conract in the first place. And we do a lot of extra work that I think is just for the sake of numbers and some fancy figures for the management. We are about 150 developers and close to 100 non-developers in "management" roles. That may tell a lot on what happens when SAFe kicks in.

[jonblackburn]

I think your point about implementing ALL of it is totally valid. I've used - and I still am - parts of the SAFe implementation plan in order to enact change in the organisation. Once we reach a tipping point and start looking to develop a vision and strategy however, we look for what works for us. We use some ideas from the framework - empowering employees, generating short-term wins, consolidating gains and producing more change - but we don't tie ourselves to their solution. Why would we, we're not them. Their framework appeals to C level management and has allowed me to drive change across the organisation, but we went with the ground up discovery of what will work here.

[thisoldproperty]

It's amazing how many so called software development improvement practices were created to make non technical management feel comfortable due to their lack of understanding or desire to understand fine grained requirements, while preferring a cloud 50 foot view.

[wizzwump]

Fantastic video Dave. So... to me, at least, Agile has lost it's way. Back in the day, early 1980s, we were moving from waterfall to RAD (now Agile). This was made more formal with the advent of DSDM in 1995. I gave my first DSDM course in March of that year. I ran quite a few RAD projects and we did deliver better software faster. At the very least we built something that was acceptable to meet the business need when it was needed by the business. After having no contact with software development for almost twenty years, (well I am retired!) I am dismayed that people are talking of going back to waterfall as a 'new' generalised approach (That said waterfall is still useful for those projects where the requirements are unfuzzy). As for SAFe... the mind boggles! Keep up the good work Dave!

[yurkshirelad]

I don't know anything as big as safe can be called "agile". We called it the Fragile model. The only people that liked it were senior managers and those who wanted a career as SAFe coaches etc...