My Blog

On SAFe, Scrum and fake agile

Saturday, February 1, 2025 4:00 PM

"Welcome changing requirements, even late in development."
"Continuous attention to technical excellence and good design enhances agility."
"Simplicity--the art of maximizing the amount of work not done--is essential."
"The best architectures, requirements, and designs emerge from self-organizing teams."

If it isn't obvious at any point, I tend to focus on technology topics. This is owed to the fact that they are the skills I've spent my entire life cultivating and that I have staked my livelihood on knowing inside and out. That doesn't mean then that I'm ignorant of or dismissive towards the soft essentials like business or process, however. I'm always broadening my interests on topics outside of technology.

Over the last several years, that openness has given me a chance to substantially deepen my understanding of the agile landscape. Specifically, thanks to some first-hand experience with a process called SAFe, which stands for "Scaled Agile Framework".

At this point I've seen enough that I think I'm finally comfortable putting some pen to paper to share takeaways and meta analysis on topics that are naturally connected to the discussion.

And yes, this is a long post, because I still believe in long form content.

It's okay if this isn't sexy

For many of you reading, this might not only be your first time hearing about SAFe, but also your first time hearing that things like SAFe even exist!

If for whatever reason you find yourself here and all of this sounds so bizarre that it has to be made up, I would not fault you for moving on to the next destination of your internet adventure.

😌 If you can go your whole career without encountering SAFe, you'll have done yourself a minor kindness.

If you're still curious, the truth is a lot of this post is also applicable to Scrum. Feel free to interpret it that way if it's helpful.

I've done my best to source some tasteful and relevant quotes from various respected and/or self-evidently successful industry professionals and sprinkle them throughout this post.

Enjoy!

What is SAFe?

From their website around the time of this blog post, it's "The world’s most trusted system for business agility".

If you read through their site some more, you'll see things like "SAFe is your system to manage digital disruption" and "The foundation for business agility that's constantly evolving.".

Don't forget though that they also make money selling courses, training, certifications and consulting. You'll also learn about their "...single, easy-to-manage subscription, [which] enables the whole organization to realize the benefits of SAFe at scale".

🤔 I suspect the "A" in "SAFe" is there - despite the entire process framework being antithetical to agile - because SAFe marketing bootstraps itself on agile as an industry trend.

Atlassian, a common SAFe bedfellow has a writeup on it, and I'm sure you can find many more. Please though, go to their own website and review it yourself to get a better understanding.

If I had to summarize how SAFe is pitched - without editorializing too much - SAFe defines itself as a batteries-included, oven-ready, just-add-water process framework for "doing a business". With the most typical form of "business" being software development.

The specific objectives of the framework seem to be aimed at trying to offer large organizations levers to manage productivity and get predictability of output. It seems to attempt this by starting from Scrum as a lens through which to interpret agile. But in doing so, also rejects that software development is knowledge work and is heavily centered around seeing it as production line assembly.

"SAFe tries to control risk through predictability. We have years and years of experience learning that predictability is not possible for complex problems like software development. The rest of the world, both scientific and industrial, has accepted this and moved forward with complex control mechanisms. Only in software is the old dream of safety in predictability still alive and, apparently, salable."

If you put it to the industry and begin snooping around about SAFe, you might be surprised to discover the emergence of some pushback against using it. This pushback is not only from people who have had to work under it, but also from signatories of the agile manifesto itself!

That's a pretty damning indictment, enough for some to even make it an open and shut argument.

Is there some good?

"SAFe will be successful in the market. People will benefit. They just won't benefit nearly as much as they might if they set out to do things in a fashion that truly supports Agile Values and Principles."

Having experienced it first-hand and given the similarity of my experiences with testimonials from others, I will not try to hide that I am ultimately critical of SAFe.

Setting my criticisms to one side though, I believe in the teaching power of any situation and if nothing else, SAFe has inadvertently helped me do a deep exploration of what I value when working with teams.

At the end of the day, that's worth something!

Now, if you're the "prefer to do my own research" type, I would caution that it's inadvisable and totally unnecessary to adopt SAFe - even temporarily - simply to learn about process. It might speed up your learning, but we do it all the time without realizing it every day we work.
Even if you wanted to, most companies don't have enough runway or money in the bank to survive a year on SAFe anyway.

That said, for organizations that subject themselves to SAFe, there are things that could merit enduring. Particularly some of the retrospective rituals and agile first-principles that SAFe doesn't manage to mangle.

I also have noticed that SAFe has some inadvertent capacity to assert strong backpressure against stakeholders from flip-flopping around on requirements and objectives. Although this is mainly owed to the fact that the process seems to grind productivity to a crawl in any organization that implements it.

"I don’t rate ANZ as an agile organisation. In fact, I would say that they’re quite sluggish in terms of some of the things that they’re doing."

Still, it's functionally a silver lining as it ends up giving teams the peace to commit and avoid erratic context switches.

Another good quality is rejecting - at least on paper - the idea of 100% capacity. Though I would call out that this is rarely how SAFe is practiced thanks to its strong stake on estimates which I'll be talking about shortly.

"But when we push too much, we experience burnout, high turnover, and a lack of creative problem solving because we’re constantly rushing to meet deadlines."

Finally, if all things we know as "agile" are a subset of SAFe, the logic should follow then that agile is always in play while practicing SAFe. Kind of like an escape hatch, or a "break glass in case of emergency".
At any time with SAFe, you should be able to point out when something doesn't align with agile, at which point it would be incumbent on SAFe to find alignment.

Concepts

The challenge with SAFe is in how it tries to expand on Scrum and all the ways Scrum is known to forbid good software engineering. Where SAFe emboldens top-down micromanagement, Scrum is the mechanism within that throws technical practice off balance, creating a downward productivity spiral.

Putting them together?

Well, let's just say if someone asked me to come up with a drawn out and painful collapse for a modern software product (particularly SaaS), I doubt I could do much better than SAFe.

But where's the fun in leaving things at that?? Let's talk about some topics that I think define SAFe or that show up often in critiques.

"ARTs"

A novel concept in SAFe is the notion of imposing synchronization of development and delivery. This is applied not just to the teams within a product, but more notably across multiple products.

SAFe calls this the "Agile Release Train" or "ART" for short.

If you have different product groups in your business, they're expected to do a typically "2-day event for the entire ART that takes place every 8-12 weeks" called "PI Planning".

"Imagine yourself thrust into the midst of a PI planning session. Around you, somewhere between 60–80 persons have gathered, sitting at team tables adorned with flipcharts, kanbans, and walls embellished with a mosaic of Post-it notes. The program board takes centre stage, showcasing the features each team commits to deliver in the upcoming sprints, with red yarn intricately weaving the dependencies between stories and teams."

My take on ARTs is that they give in to naive instincts and impede the development of a distributed architecture mindset. They encapsulate a compulsion for cosmetic symmetry if only because it feels right, but never establishes a clear need.

Think about it... Is it really necessary to slow some groups and strain others when they are working on different things?

"We've come across organizations struggling with SAFe's over-standardized, phase-gated processes. Those processes create friction in the organizational structure and its operating model. It can also promote silos in the organization, preventing platforms from becoming real business capabilities enablers. The top-down control generates waste in the value stream and discourages engineering talent creativity, while limiting autonomy and experimentation in the teams."

If one team is working on a mobile app that has to go through store reviews, but another is working on a server API, able to deploy multiple times per day...Does it make sense to stall out the API group from all their other objectives and rob them of their potential just because the other team is delayed?

Obviously not! This is the antithesis of agile in so many ways by explicitly designing your process to impede releasing.

ARTs offer insights into why what SAFe prescribes could appeal to large organizations. Particularly ones that have made the mistake of aligning their digital transformation or platform strategy along IT or operations.

The way groups interact shouldn't be codified in when and how they manage priorities. They simply need a better contract between them, and that can be improved believe it or not with better technology practices and autonomy. Not by edict, but by practice.

"A core premise of agile is that the people doing the work are the people who can best figure out how to do it. The job of management is to do anything to help them do so, not suffocate them with SAFe."

Saddling teams with the synchronization and politics of artificial boundaries like "ARTs" serves no useful purpose except to maybe avoid upsetting a dusty org chart.

Reliance on estimates

"Most organizations don't do a great job of [estimating], partly because this is a very difficult thing to do well. How do you work out how valuable an idea will be if you haven't even tried it yet?"

This one is going to be juicy, and perhaps to some, even blasphemous. I'll try to bring in as much outside perspective to this topic so as not to invite any pain upon myself.

Please though, as you read this section, use it as an opportunity to explore your own biases surrounding estimates. Try to see the damage estimates can cause and whether a fixed date of delivery matters, or is even truly beneficial.

It's a bit of a struggle trying to come up with reliable sources from SAFe itself on the term "estimates". There's no shortage of results even for a search as simple as "scaled agile estimates". Although, most of the official content around estimates is behind their paywall.

(I do find this conspicuous and I wonder if that is because they are aware of growing industry awareness pushing back against estimates. Feel free to come to your own conclusion there.)

That said, it takes time and probably even direct exposure to build a clear understanding of how intrinsic estimates are to SAFe.
In the absence of this, I'll be using some SAFe cult speak in the next paragraph.

I only know this terminology because I've had to live with it. To anyone who hasn't been indoctrinated, you'd be forgiven for feeling like this borders on gibberish...

There is a ceremony towards the end of the large planning session that each ART must go through called WSJF. The rites are tricky to dig up, but WSJF is very algorithmic and acts as the means by which all work in the next program increment (aka "PI") is sorted as a suggestion for prioritization.
The formula has all kinds of wacky inputs, distilled into arbitrary values used as proxies for importance and is then combined with estimates to come up with an order for work to be done.

As the ceremony drags on, the WSJF process decays with leadership putting their thumbs on the scales for the work they actually wanted to see done in lieu of trusting the formula. This isn't explicitly forbidden, but it does leave you wondering what all the process is there for just to end with the HIPPO effect...

"One can see why such an approach will be popular with traditional managers because it saves them the trouble of making any change. The boss can go on being the boss."

Remember that the primary input for WSJF is the agony teams go through to unreliably guess how long work will take them! That's time they could have spent learning or building prototypes to refine their understanding of a problem.

If SAFe truly offered certainty, it would be able to make estimates the clean burning fuel it wants them to be. But it can't because there is no circumstance in which estimates become empirical.

By their very definition, estimates resist using them in the pursuit of certainty and no amount of pseudoscience or spreadsheet voodoo can offset this.

Organizations that toil under the presumption that estimates are necessary don't focus enough on capabilities, and backslide towards becoming a feature factory.

To any company struggling with SAFe, I would be curious to learn "how much carryover do you typically end up with?", "how often is your IP sprint used as a guard band?" and by extension "how often do you brag about your IP sprint when interviewing people??"

I might share some more about estimates in a future post if you really want to see how far the rabbit hole goes. 🐇

Features aren't agile

I suppose there could be a few ways of interpreting the heading, but I'd like to invite you to consider that the agile manifesto doesn't once mention the word "feature". It makes sense though given that agile is less of a process and more of a philosophy. It was never intended to spawn specific rituals and ceremonies, it was intended to inspire empathy and autonomy.

I’m concerned SAFe will again, like Scrum, focus on planning and management. Without the team and technical skills people will feel the pressure to deliver low quality code.

So when thinking about features, we really have to understand what they encapsulate.

In SAFe, features are designed to be delivered within a single program increment.

(It looks like they've renamed "program increment" to "planning interval", feel free to use the two terms interchangeably.)

Features get defined with specific wording and are the bracket that holds any type of work that is to be performed. Need to update a server? Feature. Need to add a new section to a part of the app? Feature. Need to address a security vulnerability? Feature. Need to refactor a part of the code to align with some new conventions? Feature. Need to rework a deployment in response to a cloud vendor deprecation? Feature.

I would be very concerned if that doesn't begin to raise some warning signs for you. Especially if you fully understand how SAFe attempts to front-load predictions as a way to control work that gets done. This is because in development, it's not possible to catalogue every step towards a specific outcome - no matter how much you want it.

Moreover, if SAFe claims to be agile, but sets out a specific, yet arbitrary period within which work is only allowed to complete, what even is the point of estimating features? This one assertion by the process has implications that I don't think people are truly aware of until it's too late.

  • Teams will stretch (under-promise) or contract (over-promise) estimates to whatever arbitrary boundary you force them to align to. Their estimates will always be some form of a defensive white-lie to avoid armchair speculation on their productivity.
  • Processes like Scrum and SAFe prevent quality by enforcing a maximum appetite. Don't take that lightly either. Appetite here isn't just for the seemingly frivolous fancies of your development teams. Appetite here also represents the interests of the business and its ability to take on exciting new initiatives.

The next section is a good example of the damage all of this can do to your business and its ability to compete.

Maximum cap on size of work

With WSJF and its formula, interestingly, the estimates that teams give end up having quite a significant influence. Despite having factors like "business value" and "time criticality" as part of the equation, WSJF is so sensitive to larger work items, that if I presented you with this list:

  • Improve release pipelines
  • Fix 10 non-critical security bugs
  • Make a trivial change to the UI
  • Deliver a modest improvement to the product

The prioritization WSJF would come up with would closely resemble this:

  1. Make a trivial change to the UI
  2. Fix 10 non-critical security bugs
  3. Deliver a modest improvement to the product
  4. Improve release pipelines

This style of prioritization happens at an intersection where estimates and process create a nightmare for your organization. You may only have the ability to tackle two items every program increment, so items #3 and #4? They'll never get chosen because next program increment, you'll be looking at a renewed list in which those two items will predictably sink to the bottom again.

🌌 SAFe and Scrum actually have the power to create a kind of cosmological horizon for your organization.

Any organization that presupposes the necessity of a "backlog" will inevitably come to observe this phenomenon. This isn't just limited to SAFe either. In fact, Scrum might very well be the origin and out of everything I'm covering, I feel like this section is the one most people are likely to agree is most concerning.

With SAFe and Scrum, too much time is spent hoarding a perfect pile of work and nurturing it as it grows and loses meaning or relevance...

Unsurprisingly, SAFe always gives itself a passing grade as naturally a perfect pile of work makes the process appear successful and productive.

SAFe steers you towards work that is indeed smaller and easier to predict, but it may not necessarily be impactful work. It's kind of terrifying to see in real time, but the signs are all there as the product and technical teams grow despondent and tensions rise. 🥀

Refactoring is tacitly forbidden

"Technical debt tends to increase in SAFe organizations because the prioritization of dealing with it is raised to a management level rather than team level."

My work experience is primarily in software development. In this context, I try to maintain that while it's crucial to connect with business need, it cannot release you from the responsibility of sustaining an engineering mindset.

That doesn't mean pitting the two against one another making them fight for turns at the wheel. You ultimately have to be able to run both product and engineering priorities in full consideration, in parallel, at all times.

So you can imagine my disappointment when I discovered that SAFe makes it impossible to address technical debt.

If that strikes you as too pointed of a claim to make, then why not listen to the fine folks over at Volvo:

"In a 2020 interview with the Head of Continuous Improvement & Change at Product Creation, there is evidence of a lack of focus on technical excellence as instead suggested by the Agile principles. The interview also reveals a focus on processes and a hierarchical top-down approach, but no focus on the Agile mindset."

In practical terms, think of it this way:

If an organization adopts SAFe and their software releases are already too complex (pipeline definitions, test automation, manual steps, deployment, infrastructure, whatever!), estimates for any mitigations or refactors are going to seem insurmountable. You'll never be able to fit them anywhere in the schedule alongside all the other priorities.

🎲 I challenge any organization using SAFe today to do a trial. Create a work item to clean/refactor something. Not only could I see it being a challenge to define the work, but does it survive WSJF?

The end result? Debt. Piles of it as refactoring items sink to the bottom during prioritization. Each mistake calcifies in-place the instant it's authored.

With SAFe, you need to have perfect answers up front and get everything right the first time, or else it haunts you forever. This is not only thanks to the way SAFe rejects technical work, but also due to how SAFe reinforces silos and bureaucracy.

If you think you can flow refactoring work through the process, be ready for a rude awakening. You can't streamline the holistic improvement of a codebase if you are forced to go through features quarter-by-quarter to do it. All the while having to demonstrate - without nuance! - a direct correlation between effort and return. That might work when you're doing production line assembly, but in knowledge work, things have complex interactions and developers need to be locally empowered to act as custodians.
It's incredible how quickly it adds up too! Before you know it, people are talking about things that normally take days in terms of months or even years.

"In many organizations, it truly feels like the house is burning. Stuff is always breaking in production. There’s always something going wrong. Customer support is blowing up the feedback Slack channel. Everyone is scared because the next issue, the next fire, is lurking just beneath the surface. In an environment like this, it is impossible to really think about outcomes. You can talk about impact, but you can’t focus on it."

Suffice to say: There 👏 is 🪿 no 👏 such 🪿 thing 👏 as 🪿 refactoring 👏 in 🪿 SAFe!

No true SAFeperson

A predictable but always fun play on "No true Scotsman", also conspicuously seen in the form of "No true Scrumman".

It seems to be a thing with SAFe that there is no way to avoid an incorrect implementation.

What proponents seem to overlook is that if a process is so convoluted that it consistently yields bad results, there are likely false signals at play.

"This article has now been out there for over two years, and has spread quite widely across the industry. Hundreds of people have personally contacted me to tell me how this is unfortunately their reality, and their problems with SAFe were at least as bad as I described."

I've had in depth conversations with people who make arguments in favour of SAFe and demonstrate ways in which they've been able to use it successfully. To that end, even a subset of my own experiences with SAFe were painless...but only when dealing with trivial or incremental work items.

What I've noticed is that if the work isn't novel or enough of a departure from work that's already been done in the past, most of the time your choice of process is almost irrelevant.
Things always progress smoothly when they can be completed intuitively with plenty of time left to observe whatever rites an organization has in place. People are all too inclined to ascribe that false-positive signal to whatever process they happen to prefer, rather than accepting that they are doing trivial work.

When I raise this, the predictable response of "you were holding it wrong" emerges. While this overlooks the fact that if I had my choice I simply wouldn't try to "hold it" at all, I do view this response as somewhat low-effort.

"Scaling" agile

"Continuous learning and improvement, customer centricity, humility, cross-functional collaboration, evidence-based decision making, experimentation, design and course correction — to name a few — are visibly absent from the SAFe conversation. Instead, organizations adopting this way of working focus on rigid team structures, strict rituals and events and an uneven distribution of behavior change requirements depending on how high up one sits in the organization."

Another questionable premise of SAFe is when it tries to carve a niche out for itself on the basis that regular agile isn't good enough for you. It's even part of the name! That "scale" is there to goad people into believing that agile might be good, but it simply isn't good enough for you unadulterated.

This just comes down to clever marketing as it appeals to people who still think the term "enterprise" means anything beyond "we're sustaining a mess".

"Far too often, organizations try to scale Agile without actually having the ability to be Agile in the first place."

The idea that you can't use agile in larger organizations is just not true, but you cannot bring agile to organizations that resist giving teams autonomy. The more silos and hierarchy in an organization, the less it's going to thrive. If every time an organization faces a challenge, its only instinct is to introduce bottlenecks, it won't be able to help but organically drift away from agile.

An enabler of waste

This might be the first thing you hear others point out about SAFe. That it is bad agile for organizations that simply can't escape their legacy command and control heritage.

Looking at SAFes own published visuals, could you really blame people for thinking such?

"The large organization’s complex structure, rules, and policies and the complicated landscape of products having dependencies made it challenging for the team to address the constraints."

SAFe has a knack for inducing waste in how it causes work to be blindly selected based on its phased approach. It's similar to the sequential and recursive waste that happens in government due to the absence of oversight.

People often prize an iterative approach, but taking that to an extreme results in an absence of cohesion.

Comically, I can see parallels between SAFe and the CIAs "Simple Sabotage Field Manual", specifically pages 18 and 19 under the sections "Organizations and Conferences", "Managers and Supervisors", "Office Workers" and "Employees". Here are some choice excerpts:

  • "Insist on doing everything through 'channels.' Never permit short-cuts to be taken in order to expedite decisions."
  • "When possible, refer all matters to committees, for "further study and consideration." Attempt to make the committees as large as possible never less than five."
  • "Do everything possible to delay - the delivery of orders. Even though parts of an order may be ready beforehand, don't deliver it until it is completely ready."
  • "In making work assignments, always, sign out the unimportant jobs first. See that the important jobs are assigned to inefficient workers of poor machines."
  • "Hold conferences when there is more, critical work to be done."
  • "Multiply the procedures and clearances involved in issuing instructions, pay checks, and so on. See that three people have to approve everything where one would do."
  • "Contrive as many interruptions to your work as you can..."

It's shocking how much waste you can discover when you're actively working within a SAFe organization.

Other items

I can't cover every little corner of how SAFe (and indeed, Scrum or other bad agile) negatively impact organizations and of course at some point I'd like to wrap up this post. But I also don't want to deprive you of useful insights, so consider these seeds for future research and discussion:

  • Fake agile processes will bend over backwards to align with whatever product centrism is cargo-culting at the moment. This is typically the rehash du jour of number go up. Being able to draw lines from your process to "get rich quick" should be one of the surest red flags you could get. But because it's packed so densely under business trends and because product people are rarely held to the same standards as technical, it slips by unnoticed.
  • The command and control nature of fake agile processes predictably devolve into programming by remote control.
  • SAFe makes it really hard to release software. I think if you already have something established, SAFe will parasitize it and try to claim it as its own success. But if you are trying to add something new to your architecture, SAFes "do only what we can predict" mindset makes it almost impossible to just get something released so that you can start measuring or testing it.

Interlude: A critique of my critique

I've tried very hard in my own personal experience to go with the flow with SAFe. Most of this blog post is an account of the consequences I've observed in trying to use it.

The most common response I've had to my criticisms to SAFe is the "no true safeperson" section above. That if people could only wield the process better, its true strength could be had. You can see by all the links I've provided in this post though that I'm not the only person who has observed serious issues.

Over-division of responsibilities, too much bureaucracy and gate-keeping are all things that knock teams off balance. At that rate, it wouldn't matter what process we're talking about. Nowadays, the broad consensus is that once a team picks up work, they need to be able to take it start-to-finish without having to cross organizational boundaries. If your team isn't T-empowered (kind of like T-shaping, but for autonomy), no process can help.

Another disingenuous claim in favour of top-down processes like SAFe or Scrum is that developers require accountability. That without a hand constantly on their shoulder, developers can't be trusted to work or will forget that without the business, they don't get paid. That without an overbearing process, there's no way to convince the business that the developers are needed or working on anything of value.

All of this is condescending nonsense and belies a complete breakdown of trust between a leadership and the people it claims to employ. While I have absolutely witnessed teams badly in need of a wakeup call, formalizing your lack of trust and turning that into a religion is at worst cynical and at best maladaptive.

Finally, the most desperate defense I've witnessed of bad agile is one that comes backed with an authoritarian mandate: The business must have predictability!

I've already touched upon predictability in this post, but this polarizing and dogmatic assumption creates a very difficult impasse. If someone isn't willing to let go of the notion that predictability is a mirage, they will try anything except abandon the gratification of fake agile.

I've made it this far without using analogies, but if we can agree that software development is somewhere between "at least as complicated as" and "more complicated than" a game of chess, perhaps we can find some common ground...

♟️ You and I are going to play a game of chess. As part of this game, you are expected to predict exactly how long the game will last.

If your prediction is too short, then no matter the outcome, you still lose.

A subset of you might jump out of your seat: "Exactly! If you don't predict right, then your business fails!"

That sadly reveals the oversimplification and lack of finesse in trying to directly enforce predictability. Indeed, some things are time-critical, but you will never address delivery issues by getting signatures in blood or by carving dates into stone tablets.

Process is not a way to release something before it's ready or take a haphazard, scattershot approach to product design. Success or failure has nothing to do with whether one correctly forecasts the end date of a work item, and it has everything to do with when the work is actually delivered.
Yet bad agile misses the point, ignoring flow of work and obsessing over the end result as if nothing in between matters.

If a prediction is all that's needed for work to succeed, then why not predict that all work will complete one day after it's identified? Who wants to wait even one week, let alone three to six? Just set the deadline to always be tomorrow and get the work done right away!

Easy right? 🙌🤪

Okay smartypants, what can be done?

"Was asked, "What's beyond agile?" That's easy; Agile is beyond Agile. When people tell me how much they hate Agile, I ask them what they're doing instead. They invariably describe an Agile process. It's the label that's toxic (and the fake Agile that dominates the corporate landscape), not the thing itself."

The Spotify model comes to mind, as does Shape Up from 37signals. Both of these try to offer part of the picture without presenting themselves as full-stack the way SAFe does.

I've heard others suggest that companies need to optimize for flow, not for control. So that means getting down into the weeds with your development teams and helping them break down what their real challenges are. Try to start thinking about how to rebuild and nourish your engineering culture.

As part of helping your teams, you should also be enabling them to focus on only the most important work at hand.
Avoid saddling them with additional tasks unrelated to their core competencies. Backlogs and roadmaps are useless in the face of reality.

Don't force software engineers to beg for permission for improvements to the system. Let your developers - the experts - tend to the garden. And if for some reason you feel like what they're working on isn't valuable, then make the conversation about that.

Don't reach for process as a passive-aggressive proxy to explore a lack of trust for your own teams!

"Once minds begin to shut and fixate on a “simple” solution it usually signals that we have reached the point of stagnation. When there is no interest in REAL change, growth, learning, etc. then it is usually time for me to move on to an organization that practices the “art of the possible”."

I have started to abandon the notion of a fixed process as valuable for spooling work to teams. This is because we have given all our power to the notion of process without understanding why we even need it in the first place.

SAFe fails the smell test because it claims that the manager, executive or vice president gains predictability, but then takes them through a Rube Goldberg machine that lands at "make your teams estimate and only attempt what you can predict will resolve within a fixed window".

That means no risk and it means no appetite. Whether you're a small organization trying to make a name for yourself, or a large organization trying to keep up with all those small organizations nipping at your heels.

I'm all for ensuring that work is done in the small batches, but there is no evidence to show that says this is some kind of natural law.

Strict process adherence runs afoul of something that most people try to bully developers with: "Perfect is the enemy of good."

👞 Shoe doesn't fit as well on the other foot, does it now?

Another thing I would suggest trying is separating between new feature development and supporting technical work.

The biggest painpoint I've seen any organization that starts reaching for processes experience is that they impede or even outlaw the ability for engineers to make contributions outside of product feature development.
It's alluring to think that we can be creative with prioritization and shift technology to the margins to focus only on high visibility business functionality. But this always ends in product features dominating too much of the pipeline for developers to support. It creates a scarcity mindset, causes costly staff turnover and eventually reduces access to good skills.

You might also look into going slow to go fast.

🦚 Don't be principled to a fault about things like customer centrism or business focus -- you are always a technology company and if you wish to remain competitive, technology excellence is table stakes. As the agile manifesto says:

"Continuous attention to technical excellence and good design enhances agility."

None of my suggestions are to be taken as silver bullet for what might be impacting your organization. But I do suspect they will be able to offer a way to begin grappling with your issues, rather than continuously bouncing off of them or accumulating countless maladaptions.

I don't suspect that I'll be changing minds with this post, but what I am doing is adding my voice to the growing call for more acute awareness of the broken state of agile in the software industry.

References

As mentioned, I put a lot of quotes and references throughout this post. Most directly reference SAFe, some touch upon topics I believe to be related and a few are sprinkled in for laughs. 🎭

It's been challenging deciding not just whether to include something but also which section a reference applies to as all of them tend to be quite comprehensive looks at SAFe, Scrum and agile unto themselves!

So, what I'm going to do is put a large list here, and it's going to be up to you dear reader to churn through these at your own pace. I'll repeat any I've used above just so that they're nicely gathered into one spot.

There is one reference which I'm going to call out specifically, which is The SAFe Delusion.
This is an entire community dedicated to collecting information about the pitfalls of SAFe. There's an accompanying Google Drive doc which collates various writings on the topic and they offer a google group should you be interested in discussion.

Alright, here's the list!

0.61.1+39