The SAFe Delusion
Information for decision-makers considering the SAFe framework
Curated review of facts, evidence, and opinions from relevant sources without vested interests, to help decision-makers make informed choices and get better results
Download this SAFe Guide as a PDF
This is a living document that is updated daily. The PDF contains the most up-to-date information and links to all of the quotes and information represented here.
A message to SAFe Coaches & Scaled Agile Inc.
Many SAFe coaches and trainers are friends, respected co-workers, and competent Agile professionals. The content of this document is not intended as a reflection of their talent, professionalism and expertise, but as a reflection of the SAFe framework.
Scaled Agile Inc. is invited to engage with the Agile community and is encouraged to act on the parts of the feedback that are constructive and useful.
Now that Agile passed the early adopter stage, there are many companies interested in adopting it, and many practitioners interested in learning it. Yet those companies and practitioners without extensive Agile experience have a hard time evaluating what will bring them value and what not. The information collected in this document is to help them make an informed decision.
Many of the larger companies and novice practitioners look at the marketing from SAFe, and they don’t know if they can trust it or not. In this document members of the Agile community are collecting available information including on these marketing stories. Some practitioners have been there and know the difference between marketing and real stories, others know not only how things started yet also how things are going now.
SAFe Website Screenshot
Case Studies
It is not uncommon in IT for a marketing department to offer special discounts or other benefits to customers, in exchange for permission to publish a successful case study, regardless of any actual success.
The case studies below have been selected because they have been scrutinised: verified with multiple sources or coming from sources that are less likely to have a vested interest.
U.S. Air Force
In Dec 2019, Nicolas M. Chaillan then Chief Software Officer at the U.S. Air Force, issued a memorandum as part of the DoD Enterprise DevSecOps Initiative.
The memorandum concluded by strongly discouraging the use of rigid, prescriptive frameworks such as the Scaled Agile Framework (SAFe).
In a highly publicised move, Scaled Agile Inc offered free consulting to address the concerns from the memorandum. Later the USAF CSO confirmed the conclusions from the memorandum were still standing, and SAFe was still strongly discouraged and will not be used in any form in their DevSecOps Initiative.
ThoughtWorks
ThoughtWorks is a global technology company that has pioneered Lean and Agile. After observing, between 2015 and 2021, several clients that had adopted SAFe, ThoughtWorks advised against adopting SAFe.
These are some of the things they observed from the clients that had adopted SAFe: SAFe created friction in the organisational structure and its operating model, promoted silos, hindered tech from creating business capabilities, generated waste in the value stream and discouraged creativity, it limited autonomy and experimentation.
BlueDolphin
BlueDolphin consultant Wolfram Müller together with a hub of other consultants including Steve Tendon has worked in recent years helping several organisations to deal with issues after they adopted SAFe.
They recently analysed the performance of teams from a company department of 200 software developers that have been working with Essential SAFe for 1.5 years. The result highlights the same problems typical of the traditional pre-Agile approaches.
There are no signs that Essential SAFe helped them increase their agility and improve.
FitBit
Fitbit is one of the success stories promoted by Scaled Agile Inc.
Fitbit Inc. is an American company founded in 2007 with its headquarters in San Francisco. It now has about 15 offices around the world. In 2019 Fitbit was reported to have sold more than 100 million devices and have 28 million users. Between 2015 and 2016 FitBit adopted SAFe.
Damian Brown, Sr. Director of Program Management Office, describes the success of SAFe citing criteria, such as processes and teams’ Velocity, that are irrelevant for Agile teams and show a lack of paradigm shift or an Agile mindset. He continues commenting on the company's growth and the commercial success of the new products released. But the financial data, reports from financial analysts and other publicly available data contradict that.
A person working at FitBit confirmed the lack of autonomy of the teams. And added that later FitBit had abandoned SAFe, and the person that had persuaded the company to try it had left the company as well. The FitBit case study is still listed on the SAFe website as a success story. This story seems far from being a success.
Volvo Cars
Volvo Cars were founded in 1927. It is headquartered in Gothenburg, Sweden. It has around 40,000 employees and produces around 700,000 cars per year.
In software development, it employs about 10,000 people with about 150 million lines of code per car. Nowadays, cars are steadily becoming “computers on wheels”.
Between 2017 and the end of 2019, Volvo Cars went through 2 years and a half Agile transformation phase to scale Agile with SAFe.
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.
Two academic case studies by the Chalmers University Of Technology also confirm the lack of focus on the Agile mindset and the lack of alignment with Lean and Agile principles, a hierarchical approach with an org chart made deeper by additional levels. One of the papers also notes the inflexibility of SAFe and its disadvantages.
Three years later, Volvo Cars is still using SAFe in several parts of the organisation.
In September 2022, an internal source confirmed that a whole department in Volvo dropped SAFe after it became obvious to them it wasn't adding value. Since then , the teams have been functioning in a fairly Agile way in spite of the SAFe limitations: the PI planning was becoming mostly for show , and the real organisation of the work and the collaboration was happening much more fluidly; the program board was adding very little value in the face of the significant effort spent for it.
This change involved 11 teams and just over 100 people ,including Product Owners, Software Developers, UX designers, graphic designers, subject matter experts, etc.
They wanted to honour how the teams want to continuously plan and not just how they want to work, empowering teams to apply pressure upwards through the organisation in order to continuously improve.
ANZ Bank
ANZ, Australia and New Zealand Banking Group Limited is an Australian multinational banking and financial services company headquartered in Melbourne, Victoria.
In 2016 SAFe was rolled out in one part of ANZ, says Sam Kline.
In an event sponsored by Scaled Agile Inc. and one of their premium implementation partners, the rollout has been listed among some of Australia’s most successful SAFe implementations.
A second and bigger initiative started in 2017. In 2017, CEO Shayne Elliott wanted to reshape the bank’s staid culture to give ANZ customers more and faster by introducing Agile. Shayne Elliott was taking inspiration from what technology companies from Amazon to Microsoft did and looking at what some banks such as ING and ABN Amro had been doing although with mixed results. He focused on processes implementing an approach for scaling Agile across its Australian division and focused on tools: through an enterprise agreement with Atlassian for the use of Jira and Confluence.
In a 2018 article by Michael Gibson, Senior Analytics Delivery Lead in ANZ, there is a reference to SAFe suggesting that there was still some influence from SAFe ideas at that time. In another 2018 article Jean Dieudonne, Product Owner and Business Owners Tribe at ANZ, mentions a copy-paste approach of elements of the Spotify model and a reference to McKinsey’s articles containing several misrepresentations of Agile.
To summarise, both initiatives aimed at scaling Agile instead of achieving Agility at scale. The first initiative relied on a proven recipe, and the second initiative relied on copying and tailoring solutions from other organisations instead of growing and evolving their own approach based on the specific needs, context, and circumstances of ANZ.
All things that nowadays Agile experts strongly advise against.
Despite promises that the 2017 initiative would lead to “agile” teams delivering a digital transformation to generate growth and underpin the bank’s residential mortgage business, five years later, the bank’s technology systems still lag behind its biggest competitors. This may be inferred from the bank’s home loan approval systems becoming one of the slowest in Australia, and for that ANZ lost a substantial share of the $2 trillion mortgage market, its share price is down 17 per cent since Elliott became CEO seven years ago.
Martin North, the founder of DFA Analytics, says “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.”
So far all the SAFe case studies that allow for some form of verification or third-party observations all show that SAFe does not make the organisation more agile, it worsened the shortcomings that are typical of the pre-Agile approaches, and overall makes things worse.
It is also known that SAFe isn’t used by any leading software commercial organisations such as Facebook, Google, Netflix, Microsoft, and the like.
This overall picture is congruent with the growing number of anecdotal evidence emerging from Sr leaders and employees sharing stories about their previous companies where SAFe was adopted.
SAFe experts’ opinion
A small significant sample of former SAFe experts, some instrumental in shaping SAFe.
Al Shalloway former SAFe Principal Contributor, and Trainer (SPCT)
Al Shalloway has been one of the three initial SAFe Principal Contributors for six years, the first SAFe program consultant trainer (SPCT) outside Scaled Agile Inc, and his company was a SAFe Gold partner.
In 2018 he broke off his relationship with Scaled Agile Inc and SAFe, citing among the reasons that SAFe has grown considerably more complex than it needed to be, and that he was told had to prove he had done a few “by the book” SAFe adoptions to renew his SPCT certification.
Mr. Shalloway’s view is that SAFe brings some very useful concepts to Agile – Flow/Lean (although not well implemented, but at least mentioned), big room planning to start a large scale (over 300 people) adoption of Agile, DevOps, an overall value stream view, large room planning when it’s useful, and more. However, while it is a good first step for very large organisations that can’t deliver in 3 months, it is not a good approach for any company with less than 500 developers. And it usually stagnates after 3 -6 months, often leaving companies worse off than when they started.
SAFe starts well by getting people into Agile Release Trains, identifying dependencies, and keeping work below capacity for 1 to 2 program increments.. But this is just a first step, and without further decomposition of ARTs and a simpler product management system based on minimum business increments, it reverts back into a push model where the waste that results comes back.
Bob Galen, former SAFe Program Consultant (SPC)
Bob Galen became SAFe SPC certified around 2013. He tried to understand, support, and apply it, but then he struggled with it for a long time to the point that he just couldn’t be associated with it any longer.
In his farewell to SAFe he mentioned several reasons, here are a few: It’s too big; It creates far too many roles, layers, flows, etc; It’s too focused on certifications and training; It created lazy organisations who think the framework does the heavy lifting for them; It created a community of SPC’s and other consultants who look at every problem and thinks SAFe is the solution.
This is a small sample of a growing group of SAFe experts that are distancing themselves from SAFe with motivations that are congruent with the problems observed in the case studies and by other experts and practitioners.
Comments from the authors of some practices
assimilated by SAFe
These are the source authors of some of the practices that SAFe proports to include.
Jeff Gothelf, co-creator of Lean UX
Jeff Gothelf is the co-creator and co-author of Lean UX. He has direct experience with SAFe and indirect experience with several clients. Commenting on how SAFe and Lean UX works together he says “all the principles we’ve built into Lean UX don’t seem to exist in SAFe.”
Based on what his clients are being taught by their SAFe trainers/consultants they are unable to see how SAFe and Lean UX can mix together. Neither does he have any good answers for them, since deviating from the framework is considered heresy in most cases.
Dave Farley
Dave Farley is a pioneer of Continuous Delivery, an expert in DevOps, and co-author of the first and most relevant book on Continuous Delivery.
After working with several clients that have adopted it, he noted that SAFe Release Trains practice is anti-Continuous Integration where Continuous Integration is a fundamental technical practice of Agile that Continuous Delivery is built on.
That means that Release Trains in SAFe are anti-Continuous Delivery.
Ken Schwaber and Jeff Sutherland co-creators of Scrum
Ken Schwaber and Jeff Sutherland are two of the creators of the Scrum, and co-authors of The Scrum Guide. They are also part of the group of authors of the Agile Manifesto.
They both criticise SAFe, as detailed later in the document. Jeff Sutherland in particular says that SAFe is inconsistent with the Scrum guide and codifies dysfunctions that can cripple teams for years. Ken Schwaber says that there is a fundamental philosophical schism between Scrum and SAFe because Scrum controls risk through empiricism while SAFe tries to control risk through predictability.
This is a small sample of authors of original practices that have been integrated into SAFe, who say the integration of their practices is fundamentally flawed.
A larger number of experts share similar comments about other practices that have been integrated into SAFe.
Agile experts’ opinion
These are some of the most respected voices in the agile space and have years of experience working with organisations of any scale.
Ron Jeffries, co-author of the Agile Manifesto
Ron Jeffries published on his personal website a very constructive, detailed long list of criticisms about SAFe.
His criticisms have fallen on deaf ears, and instead, the latest versions of SAFe have even worsened the problems.
Andy Hunt, co-author of the Agile Manifesto
Andy Hunt states that SAFe is not an Agile approach. He also mentioned professionals that made a career fixing severe problems caused by failed SAFe adoptions.
Martin Fowler, co-author of the Agile Manifesto
Martin Fowler is also Chief Scientist in ThoughtWorks, so you can imagine that the view of ThoughtWorks on SAFe, also documented here, is congruent with his view. During a panel at the GOTO conference, he made very clear his dislike for SAFe.
Alistair Cockburn, co-author of the Agile Manifesto
Alistair Cockburn suggested that the money and time spent on installing SAFe could produce much better results when spent instead on improving collaboration and delivery that in turn would move the company's attitude and behaviour some distance.
He added at that point that he stopped defending SAFe because he thinks there is a betterway to spend the money.
Brian Marick, co-author of the Agile Manifesto
Brian Marick described SAFe nature as problematic and prescriptive due to *the* set of rules to follow, with a fret to enforce them. And he also described SAFe processes as overly-codified to the point that they actively work against the collective creation of tacit knowledge.
Ken Schwaber and Jeff Sutherland, co-authors of the Agile Manifesto
Ken Schwaber and Jeff Sutherland are part of the group of authors of the Agile Manifesto and two of the creators of Scrum.
As mentioned before they both criticise SAFe.
Ken Schwaber equates SAFe to RUP, an abandoned heavyweight methodology. He comments further saying that a core premise of Agile is that the people doing the work are the people who can best figure out how to do it. And that the job of management is to do anything to help them do so, not suffocate them with SAFe.
Jeff Sutherland says that he finds scaling frameworks like SAFe overly prescriptive and limited in their efficacy.
Mike Beedle, was co-author of the Agile Manifesto
Mike Beedle was an American theoretical physicist turned software engineer. and he was the author of the first book and earliest papers about Scrum. He was also a co-author and a signatory of the Agile Manifesto.
He debated that SAFe is not Agile, and he added that there are many other better alternatives. He articulated how SAFe in particular and the Agile Train Releases concept, violate all the values in the Agile Manifesto.
Other experts’ opinions
These are some of the most respected voices in the agile space and have years of experience working with organisations of any scale.
Chris Matts
Chris Matts is an experienced Agile practitioner specialising in delivering trading and risk management systems in investment banks. He contributed to BDD with Daniel Terhorst-North, he developed Feature Injection practice and with Olav Maassen he introduced the concept of Real Options in Agile.
Chris highlights that the creators of SAFe have not engaged with the wider Agile community in the usual debate that challenges the new practices in a process that validates and improves them, and ultimately gives (or not) credibility. Chris adds that he is not aware of a single leader in the Agile Community that has endorsed SAFe.
As an example of the flaws of SAFe he mentions the definition of Epics in SAFe. And he also challenges the idea that SAFe could be a stepping stone to good Agile.
Marty Cagan
Marty Cagan is a Silicon Valley-based product executive with more than 20 years of experience with industry leaders including eBay, AOL, Netscape Communications and Hewlett-Packard.
Based on all Marty Cagan has read and heard, he says he would not want to work in a company using SAFe. He can’t either imagine any of the strong tech product companies he knows choosing to move to SAFe, and if for some reason they did, he’d be pretty certain their top talent would leave.
He believes that with SAFe the core benefits of Agile and Lean are lost. And he found in SAFe all ten key attributes of Waterfall and project mindset that are the most common root causes of product failure in product companies.
Mary Poppendieck
Mary Poppendieck, with her husband Tom Poppendieck, is the co-author of the book Lean Software Development, a seminal book for the Agile community. She agrees with the overall conclusion of the U.S. Air Force memorandum which is to strongly discourage the use of rigid, prescriptive frameworks such as SAFe.
"Every large agile framework that I know of is an excuse to avoid the difficult and challenging work of sorting out the organization’s system architecture so that small agile teams can work independently. You do not create smart, innovative teams by adding more process, you create them by breaking dependencies.”
Dave Snowden
David John Snowden is a researcher in the field of knowledge management, and the creator of the Cynefin framework applied in software development and management science.
Overall he expressed a very negative view of SAFe.
Among other comments, he explained that SAFe employs ordered world approaches to solve complex problems, and because of that it’s a-priori wrong. As a result, he adds, SAFe is a massive backwards not a forwards move.
Steve Denning
Steve Denning is a recognised expert and author in leadership, management, and innovation.
In some of his articles, he describes the efforts to scale Agile with SAFe as counterproductive. He further criticises SAFe stating that it destroys the very essence of Agile, and it degrades and undermines everything in Agile that is authentic and useful.
He added that SAFe gives to organisations a mandate to call themselves Agile while keep doing what they have always done, reaching the conclusion that SAFe is the epitome of fake Agile.
Barry W. Boehm
Barry W. Boehm was a prominent American software engineer and author of the COCOMO costing model and the Spiral Model software process.
He commented on the approach embraced by SAFe: “Tailoring-down all-inclusive methods lead to unnecessary expenses in time and resources”, and he adds that it’s the opposite of the Agile approach.
Sample of practitioners' opinions
A list of opinions from practitioners that details the problems they identified in SAFe. These opinions may reflect the possible reactions of the employees in an organisation adopting SAFe.
Paweł Huryn, Watch Out, Waterfall Ahead! The Truth About SAFe
Paweł Huryn comments in his post on various aspects of SAFe, where he notes that:
- SAFe adopts a Waterfall approach to requirements
- SAFe processes and roles show a lack of trust and autonomy of development teams
- SAFe focus is on plans and output more than on outcomes and feedback
- SAFe version of Scrum deviates from the real Scrum making it worse.
He concludes by suggesting that with SAFe an organisation doesn't feel the need to change anything substantial, but with it, they feel they can call themselves “Agile.”
Kevin Bendeler, I Don’t Like SAFe
Kevin Bendeler after working several years with SAFe comments on 7 flaws he noticed in the framework’s adoption:
- In SAFe extensive front-loaded planning encourages ineffective larger batch size work
- Technical debt tends to increase in SAFe organisations
- SAFe Program Increment (PI) cycle time is unfit for teams that need to be responsive
- SAFe roles and structure may discourage teams collaboration that’s an Agile value
- SAFe approaches to estimation is more predictive than empirical as in Agile
- SAFe focus more on output and volume than the value created and delivered
- SAFe doesn’t have enough focus on the feedback loop and related learnings.
He concludes by saying he thinks that trying to scale Agile up by applying heavyweight, top-down methodologies is antithetical and counterproductive.
Sam Haynes, SAFe: A Waterfall Pig with Agile Lipstick
Sam Haynes, based on his observations of SAFe implementations thinks that:
- SAFe’s ask for excessive time to developers for estimations and metrics is demotivating
- SAFe requirement of starting by getting everyone SAFe trained and certified is suspicious
- SAFe “branded agile” risk to discredit genuine Agile
- PI Planning tries to manage dependencies instead of having a loosely coupled architecture
- PI Planning cadence doesn't allow to timely react/adapt to changing customer needs
- PI Planning and Release Trains are inferior to on-demand planning and Continuous Delivery.
He wonders why anyone with a genuine Agile mindset would be using SAFe in the first place.
Luca Minudel, My Opinion on SAFe
Luca Minudel analyses various aspects of the framework and comments on their practical implications noting that:
- The 12-step SAFe Implementation Roadmap is like a 1-size-fits-all Waterfall programme
- SAFe Budgeting and Portfolio management don’t solve the problems of annual budgeting and planning due to the prescriptive, top-down, rigid nature of most SAFe implementations
- SAFe Requirements Model is a pre-Agile deliverable-oriented hierarchical decomposition of the work mirroring the hierarchy of the roles in SAFe, it reinforces a top-down approach
- SAFe Roles add more bureaucracy, disempower the teams, and make collaboration harder
- PI Planning hinders business-tech collaboration, accommodates dependencies instead of removing them, and perpetuates a top-down pre-Agile approach
- Release Trains is a very inefficient pre-Agile practice inferior to all the modern alternatives
- Overly complicated SAFe contradicts the Agile principle of simplicity and emergence
Following his observations, he concludes that SAFe violates all four Agile values.
Yves Hanoulle My Opinion on SAFe
When I first heard of SAFe, I was hearing the same kind of negative things as I heard when I first heard of Scrum. (From people doing XP) or Kanban (from people doing scrum). So I decided to look for a SAFe project to experience it myself. As I did not want to just have an opinion based on theory. After that project my general feeling was: SAFe goes further than the companies implementing it want to go and does not go as far as what the companies really need. I saw that at best it was a gateway drug to agile. Yet in most companies it just gives a new name for an old way of working. A nice example is dependencies, instead of making dependencies transparent to start working on removing them, they at best visualise them so show them as reality. I used to think it was nice they showed many different techniques to a large audience. Now I see that not only they explain them badly and give practitioners a bad start with a new technique, they also try to copyright techniques from agile friends. The sentence “this is not agile”, is not agile in itself, yet calling a cat a dog, does not make it bark.
General SAFe trends
The adoption of SAFe and its market share are still growing.
The less flattering trends below come from anecdotal evidence.
There is a growing number of Agile professionals and certified SAFe professionals that decided not to work again with clients adopting SAFe. They declared it publicly, it
occasionally comes up at meetings among Agile professionals, and some recruiters reported candidates refusing job opportunities because of SAFe.
The number of experienced Agile professionals publicly criticising SAFe is also increasing.
There is a growing number of sr leaders and former employees of organisations that tried to adopt SAFe that are sharing stories of stalled and abandoned adoptions, adoptions that went wrong, and problems caused by SAFe.
The number and frequency of posts on social media and articles in online magazines about failed SAFe adoptions is also increasing.
More organisations are asking for Agile professionals that are framework agnostic, and that have enough experience to work without the need of a guardrail from a scaled framework.
It is not possible to say if these trends are ordinary by-products of the increasing adoptions of SAFe, if they are due to SAFe itself, the quality of its implementations, the characteristic of the organisations choosing that framework, or other factors.
Conclusions
Each one of the top experts' opinions, creator of a practice integrated into SAFe, scrutinised case study, and practitioner opinion, taken alone in isolation is not enough to draw a conclusion.
At the same time all of them together, with their similarities, seem to suggest that the implementations of SAFe tend to:
- lack fundamental elements of good Agile that are vital to achieving agility
- amplify some of the well-known problems and limitations of pre-Agile traditional solutions
- spend a lot of time and effort to learn and adopt
outdated practices, or 2nd best
Download this SAFe Guide as a PDF
The PDF contains the most up-to-date information and links to all of the quotes and information represented here.