SAFe Delusion

Information for decision-makers considering SAFe

PDF (EN)
Contributors:
Luca Minudel Luca Minudel Yves Hanoulle Thomas J Owens Chris Combe Luis Azcona Latasa Stefan Sonnenberg-Carstens Martin Hinshelwood Martin Hinshelwood Ove Holmberg Steve Bement
Version: v2024.8(Latest)

We are uncovering better ways of working by doing it and helping others do it.

top

Premises

top

Introduction

Now that Agile has passed the early adopter stage, many companies are interested in adopting it, and many novice practitioners are 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 will not. They 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 but also how things are going now.

The information collected in this document is to help them make an informed decision. If you like it, re-share it: https://bit.ly/SAFe4DecisionMakers

The links to all the sources used for this article, each containing further details and a more detailed account of the related events, are in Appendix 1.
top

How to use this document

You can download this document (open the File menu and select Download), and if necessary edit it to leave only the most relevant info before sharing it with a decision-maker. You may want to create and share a 1-page summary to introduce the topic to the decision-maker before sharing the whole document.
In both cases include the link to the original document. For practitioners, you may want to share directly the link to this document.

top

Contributors and guidelines for contributions

This document is a collective effort with multiple contributions, mainly from the Agile community. The list of contributors is long. They are the experts and the practitioners mentioned below whose posts and articles have been linked in Appendix 1, the many readers who suggested several improvements, those who worked on the case studies, and the curators of this effort, Luca Minudel and Yves Hanoulle. A special thanks
also goes to Thomas J Owens, Chris Combe, Luis Azcona Latasa, Stefan Sonnenberg-Carstens, Martin Hinshelwood, Ove Holmberg, Steve Bement and many others.

If you want to discuss this document and contribute to the curation of its content, join the group: ​​ https://groups.google.com/g/agileinformeddecisionmaking

They all have spent hours, days, weeks, and even months codifying, debating, verifying and generously sharing their findings. With the shared purpose of improving the state of affairs for everyone.

This is an open-source document where we collect and share valuable information. These are the guidelines for the contributors:

  • You can add any time to fix spelling mistakes
  • Please don’t remove things others wrote
    • Except if people misquoted you, in which case you correct
    • If you quote someone, please inform them, so they can read if they still agree with the quote.
  • If you disagree with something, add a comment and start a (civil) discussion
  • As SAFe is a controversial topic for many, we want to stress that we want a civilised conversation, no shouting match.

Feel free to add, write, comment, spread and read. If you like it, share it.

top

FAQ: How do you define success?

What is “good Agile”? How do you define success in adopting Agile?

One answer that is loosely inspired by the definition of success of a methodology by Alistair Cockburn, is this: success is when an organisation achieves a level of Agility that brings tangible lasting benefits to their business, and those who did the work would continue to use and evolve the adopted ways of working instead of ditching it. This is the very practical definition assumed by this document.

There is also a historical definition. Around the year 2000, Agile was a fringe movement, and at that time, the majority of medium-to-large IT projects failed more often than they succeeded. The burden of proof that Agile actually works was all on Agile practitioners. Back then they achieved a long sequence of repeated successes that later contributed to Agile’s popularity and later its path to becoming mainstream. This historical definition shows that succeeding with good Agile is not a hypothesis, an abstract aspiration or a mirage, but something that’s already been achieved repeatedly and consistently.

A final provocative definition comes from this quote: << Some things can’t be told. You live them or you don’t. But they can’t be told. >>

top

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.

top

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.

top

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.

top

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, limited autonomy and experimentation.

top

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 who 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.

top

Volvo Cars

Volvo Cars was 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 despite 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.

top

ANZ Bank initiatives for scaling Agile

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 references SAFe and its influences still present at the 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.”

top

Capital One

Scaled Agile Inc. case study on Capital One, published in 2017, states that in 2013 software development in Capital One Commercial Banking was largely outsourced and conducted following a waterfall approach. At the time they took steps toward building an Agile workforce. For such an endeavour, Mike Eason as Commercial Banking’s CIO selected the SAFe framework and started with the goal of reimagining Product and Delivery through Agile, moving beyond the rhetoric of “business and IT” alignment, and having Agile teams dedicated to their products, services, and broader business strategies. They also targeted having 100% of the workforce trained and many of those in key roles certified.

In reality, SAFe already existed in pockets between 2012-2014 in various departments within Commercial Bank and Card, even if not as the recognised standard approach. It was during this time, following the acquisition of ING Direct, that a SAFe program to bring together some parts of ING Direct and Capital One’s technical ecosystems was largely deemed unsuccessful. And even after that Capital One Agile transformation wasn’t 100% SAFe.

Around 2017, while Scaled Agile Inc. was publishing the Capital One case study, the leadership started to express doubts about the value of their Agile adoption and the Scrum Master role. This triggered the following event, a couple of years later in May 2019. Capital One announced they were adding more responsibilities to the Scrum Master role related to delivery thus making the role more “technical”. In doing so they also renamed the role to Agile Delivery Lead. What was described in the announcement is congruent with reports that, while the Tech and Product teams were closer than ever, and other departments were starting to embrace Agility, unfortunately, there was a persistent “Product vs Tech” or “us vs them” phenomenon. This is in contrast to what good Agile suggests and the goal originally set for the initiative.

The experiment to rename the Scrum Master role to Agile Delivery Lead turned into a role rename without the necessary work to make the change required to add value. This confirmed the doubts about the value of Capital One Agile adoption leading to the following event. In January 2023 a Capital One press release announced, citing the challenging operating conditions, that they were eliminating all the 1100 Agile roles with an action that speaks louder than the success claimed by Scaled Agile Inc. case study for the SAFe-driven Capital One’s Agile transformation. Many of the SAFe Scrum Masters affected had a tendency to follow SAFe by the book in a prescriptive way. The announcement reaffirmed that in Capital One, Agile was siloed into IT without the necessary involvement of the Business. Additionally, it made it clear that Capital One is committed to its journey to mirror successful technology companies with high levels of Agility, like for example the FAANG companies and ThoughtWorks, where the Scrum Master and Agile Coach responsibilities have been taken up by the team and cease to be a role. Those companies empower each and every team to be Agile in their own way, without prescribing the adoption of any ‘out of the box’ solution like SAFe, or any other framework adopted ‘by the book’.

Sunil Mundra, the author of Enterprise Agility book, after reading the announcement of the layoffs commented on the SAFe case study on LinkedIn saying: “If everything was so hunky-dory, what happened ?”

top

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 who 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.

top

Peaksys

Peaksys is a French technology company that creates and operates digital solutions for the whole Cdiscount ecosystem (Cdiscount.com, C-Logistics, Octopia et Cdiscount Advertising). They employ about 650 technology enthusiasts.
Around 2020 Peaksys made a big bet by entering the B2B market with a new marketplace-as-a-service product. As a consequence, the company felt the need for a new organisation that could help them grow while staying focused and aligned. And this led them to SAFe.

One problem they encountered with SAFe was the long value creation cycle: their time to market (TTM), the time between the prioritization of a feature before the discovery and the activation date of this feature, was around 1 year. The delivery PI that follows after the discovery phase on a PI was part of the problem. The fast and dynamic nature of their new endeavour did not fit well with the SAFe approach of freezing the priorities for an entire quarter. SAFe also led them to focus heavily on delivery and deliverables instead of what their customers wanted and expected from them. They faced a huge work in progress (WIP) with a lot of multitasking. The overly detailed nature of the framework made people feel overloaded, which ironically was the opposite of the lesson from Team Topologies recently assimilated by SAFe.
The SAFe approach to dependencies (accommodating during the PI instead of creating value-aligned teams that minimise dependencies) also created more problems.

In conclusion, they realised SAFe was holding them back from greater agility and product focus while worsening their teams’ working conditions. Ultimately for Peaksys SAFe proved to be more of a hindrance than an advantage.

top

Beijer Electronics

Beijer Electronics is a Swedish company that, since 1981 is a B2B business that designs and manufactures human-machine interface terminals and automation software. The company is based in Malmö, with a presence in Europe, Asia, and the Americas.

At the beginning of 2017 Beijer Electronics employed in software development about 70 people in six teams, and decided to embark on a SAFe transformation to become more Agile.
After doing so, they started to notice that at every quarter at the PI instead of becoming faster, more Agile, and things getting better, things were actually getting worse: the spillovers from Sprint to Sprint were increasing, trust between technical and product people were going down, and customers need went unfulfilled.

In the fall of 2020, they got inspired by the work of Marty Cagan the Silicon Valley-based product executive that vouches for a product-centric lightweight Agile approach.
In June 2021 they decided to leave SAFe behind and move forward adopting several ideas inspired by Marty Cagan’s work, for example:

  • Putting the customer at the centre, starting with understanding customers’ context and needs, instead of getting lost in the formalities of planning and requirements and measurement of outputs instead of valuable outcomes.
  • Bringing product and tech people together in each team instead of having separated program, product and tech divisions, shifting toward the practice and the culture of real collaboration instead of being separated by the hierarchical roles and functional separation of the organisation structure.
  • Empowering teams and team members to benefit from everyone’s talent, company experience, and technical and product experience, instead of being silenced by the formal bureaucratic processes and the top-down structure.
  • Iterative and incremental fast-feedback-driven collaborative product discovery activities instead of the top-down prescriptive plan-driven approach

After leaving behind SAFe and starting to focus on these and other changes they started to see actual improvements and happier customers. The positive results continued to come in the following years.

top

Equal Experts

Equal Experts is a Tech consulting company that in 2024 employs, across 5 continents, 3,000 senior consultants that combine technical excellence and business pragmatism to deliver simple bespoke software solutions.

Based on a range of negative feedback from their customers and consultants, Equal Experts realises that:

  • SAFe doesn’t accelerate delivery speed
    Instead, it drags down productivity and speed.
  • SAFe doesn’t satisfy product demand
    It assumes 3 months of unchanging market conditions and user needs and focuses on outputs over outcomes leading to a project-centric org, not a product-centric one
  • SAFe doesn’t create adaptive architectures
    Because it defers tough engineering challenges and offers brittle, time-consuming band-aids instead of solving them

For these and other reasons Equal Experts has decided to not recommend SAFe, it says instead ‘don’t do SAFe’.

top

Conclusions

So far in all the SAFe case studies that allow for some form of verification or third-party observations, there is no evidence that in the face of the time spent and the effort made SAFe brought any lasting benefits or made the organisation any more agile.
Where most of those case studies observed show that after the SAFe adoption, whatever the reason may be, the shortcomings that are typical of the pre-Agile approaches have been amplified, overall making things worse.

It is also known that SAFe isn’t used by any of the leading innovative software companies such as Facebook, Google, Netflix, Microsoft, and the like. Or any of the best product companies.

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.

top

SAFe experts’ opinion

A small significant sample of former SAFe experts, some instrumental in shaping SAFe.

top

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 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.

After this, management tends to revert to worse habits than before. And a push for consistency gets stronger. Mr. Shalloway believes that stagnated SAFe adoptions can be improved and that people don’t need to start over. But what’s needed is not offered by SAI.

top

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.

top

Conclusions

This is a small sample of a growing group of SAFe experts who are publicly distancing themselves from SAFe. There are many others, like Alex Yakyma first SAFe Associate Methodologist and SAFe Fellow, who simply moved on.
Their motivations seem congruent with the problems observed in the case studies and by other experts and practitioners.

top

Comments from the authors of some practices assimilated by SAFe

top

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 work 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.

top

Dave Farley, co-author of Continuous Delivery

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 SAFe, 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.

top

Ken Schwaber and Jeff Sutherland co-creators of Scrum

Ken Schwaber and Jeff Sutherland are two of the creators of 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.

top

Conclusions

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.

top

Agile experts’ opinion

top

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.

top

Andy Hunt, co-author of the Agile Manifesto

Andy Hunt states that SAFe is not an Agile approach.
He also mentioned professionals who made a career fixing severe problems caused by failed SAFe adoptions.

top

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.

top

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 better way to spend the money.

top

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. He also described SAFe processes as overly codified to the point that they actively work against the collective creation of tacit knowledge.

top

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.

top

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 Release Trains concept, violate all the values in the Agile Manifesto.

top

Other experts’ opinions

A small significant sample of recognised experts from various relevant areas.

top

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 who has endorsed SAFe.

As an example of the flaws of SAFe, he mentions the definition of Epics in SAFe.
He also challenges the idea that SAFe could be a stepping stone to good Agile.

He also extensively examines the pre-Agile culture he names as Failurship as opposed to Leadership. In such a “failure culture”, there is a set of behaviours that prevent change and perpetuate the status quo. There may be an explanation for why some organisations choose SAFe.

top

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. 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.

top

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.

She has this to say specifically:
“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.”

top

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 step backwards, not a forward move.

top

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.

top

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.

In a publication that predates SAFe, Barry W. Boehm comments on plan-driven methods as those trying to be all-inclusive and requiring extensive efforts to be tailored down. All these are characteristics commonly associated with SAFe. Then he contrasts and compares plan-driven methods with Agile:

“Unfortunately, most plan-driven methods suffer from a ‘tailoring-down’ syndrome … These plan-driven methods are developed by experts, who want to provide users with guidance for most or all foreseeable situations. The experts therefore make them very comprehensive, but ‘tailorable-down’ for less critical or less complex situations.”

“… plan-driven methods have had a tradition of developing all-inclusive methods that can be tailored down to fit a particular situation. … nonexperts tend to play it safe and use the whole thing, often at considerable unnecessary expense. Agilists offer a better approach of starting with relatively minimal sets of practices and only adding extras where they can be clearly justified by cost-benefit. … As we have seen with RUP, efforts are underway to develop similar approaches for building up plan-driven methods.”

He further compares plan-driven and Agile methods across five critical factors namely Size, Criticality, Dynamism, Personnel and Culture noting the asymmetry in plan-driven and Agile methods that tend to succeed on the opposite scale ends of those factors. He comments on how combining and balancing the two methods is an extremely difficult task.

top

James Shore

James Shore is the co-author of the classic Agile how-to guide, The Art of Agile Development and a recipient of the Agile Alliance’s Gordon Pask Award for Contributions to Agile Practice.

In his second edition of “The Art of Agile Development” James added an entire chapter on scaling. He cautions: “far too often, organizations try to scale Agile without actually having the ability to be Agile in the first place.” Regarding SAFe specifically: “I’ve yet to see it work well. Companies tend to adopt it with great fanfare, only to silently drop it several years later.” On PI Planning: “It’s predictive, not adaptive; extremely labour intensive and draining; and it doesn’t work well with remote teams.” He concludes: “All in all, SAFe pays lip service to a mishmash of Agile ideas without seeming to truly understand them. I don’t recommend it.”

top

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.

top

Koen Vastmans, The agile blender blunder

Koen Vastmans noted that SAFe blends into the framework many good concepts and techniques from different authors, and in the process misrepresents the original ideas, loses entirely the related mindset and fundamental elements that make those ideas work, claims the copyright of those ideas, while unsuspecting practitioners that learned Agile through SAFe are left with these misrepresentations and ends up themselves causing confusion among other practitioners.
Koen Vastmans in his post lists and drills down into several of such misrepresented concepts and techniques:

  • Scrum
  • Team Topologies
  • INVEST
  • Planning poker
  • Deming’s PDCA cycle
  • DevOps and CALM

The points made by Koen Vastmans on SAFe are congruent with the comments above from several authors of practices assimilated by SAFe.

top

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.”
top

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 is an Agile value
  • SAFe approach 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.
top

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.
top

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 and accommodates dependencies instead
    of removing them, and it 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.
top

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 to 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 to 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 do they explain them badly and give practitioners a bad start with a new technique, but 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.

top

Many others

There is a growing number of Agile practitioners documenting and posting their experience with SAFe. Links to some of these posts have been added in Appendix 1.

top

The adoption of SAFe and its market share are still growing.

The less flattering trends below come from anecdotal evidence.
A growing number of Agile and certified SAFe professionals have publicly decided not to work with clients adopting SAFe. It occasionally comes up also 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 senior 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 who are framework agnostic, and who have enough experience to work without the need for 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 characteristics of the organisations choosing that framework, or other factors.

top

General conclusions

Each one of the opinions of top experts and authors of a practice assimilated by SAFe, and each 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
  • waste a lot of time and effort for learning and adopting outdated, or 2nd best practices
top

Safe alternatives (to SAFe)

At the moment there is not one best practice, standard solution, or silver bullet that can guarantee an organisation to increase its technical agility, organisational agility, business agility, achieve tangible and lasting benefits for its business and ultimately become more successful, innovative, and resilient.

For decades the whole industry has been trying to find a solution to this, while at the same time, the opportunities and the challenges organisations face are also changing and evolving.

But after over 10 years since when large organisations are trying to become Agile, we know that there are much better options than SAFe

top

All heavy-weight frameworks like SAFe, which promise to scale Agile, have problems similar to or equivalent to SAFe.
All the canned solutions and standard recipes for Agile transformations, Digital transformations, and Scaling Agile, coming from large consultancy firms, don’t work either (see https://bit.ly/agileOffering4DecisionMakers ).
All attempts to copy and paste solutions of other organisations, like trying to replicate the Spotify model, have also failed repeatedly.
Also, the attempts to extend or customise SAFe or other heavy-weight frameworks for a particular industrial sector, have failed.

Attempts to adopt Agile following one framework by the book, of running an Agile transformation using a Waterfall programme don’t work either.

top

One of the things SAFe does is group ideas that have been invented by the Agile community. Unfortunately in the process, they are often misrepresented or worsened, and in most cases, it is not properly made clear where these ideas are borrowed from. One approach is to go back to the original ideas as they are really intended.

Below, in Appendix 2 we are gathering the list of these ideas with links to the original sources.

As SAFe has assembled a lot from the Agile community, this should be a long list. Please add anything you think is missing.

top

Successful Agile adoptions or organisations that have successfully developed their technical, organisational and business agility with lasting benefits for their business, often present some common elements. These elements are listed below.

Appendix 3

Your chances of success are greatly increased by taking inspiration from these elements below:

  • Embracing an experimental approach to Agile adoptions has been instrumental in many successful adoptions. It consists in starting small and proceeding with small experiments, learning, adapting and evolving. It focuses on making things work well in the small before going bigger. Furthermore, it is an Agile approach to adopting Agile. The journey through these experiments, the mistakes and the related learning are instrumental to understanding, learning, adopting and adapting Agile to your specific organisation’s needs.

  • Using a people-centred approach where employees are invited to participate in the adoption and where autonomy to individuals and teams is increased, has worked well too.

  • Building on the previous point, ​​a focus on team autonomy, coupled with alignment to clear customer outcomes and wrapped up with lightweight governance, instead of the hierarchical and complex SAFe approach, is certainly a more effective way of scaling agile across an organisation.

  • What has also worked well is a focus on de-scaling the problem. For example, through modularisation, aligning teams and the organisation along individual products and services and more in general along value-streams (take a look at Team Topologies for an in-depth Introduction on this). Also through technical excellence reducing and relaxing cross-team dependencies,

  • A pluralistic approach that takes elements from various non-scaled Agile frameworks (think of eXtreme Programming, Crystal clear, DSDM, Kanban, Scrum, etc.) and patterns and practices available from the Agile community, have also worked well.
    This approach is informed and guided in each of its steps by the values and principles of Agile, Lean, and Human Complexity.

  • Exploring team types, their composition and their interactions is a key factor to consider when one considers ways of working across an entire organisation. There are several constructs that explore this in more detail:

    • Team Topologies by Matthew Skelton and Manuel Pais explores team types (topologies)
    • Sriram Narayan in his book ‘Agile IT Organisation Design’ explores teams structure
    • Sooner Safer Happier by Jon Smart et al - explores teams safety
    • Managing Digital by Charles Betz explores team spectrums
    • Extra-dependent teams by David Kesby explores same-skilled teams

  • There’s more exhaustive organisational design literature but the above is a good place to get started. There are also learning triads as well which are worth exploring too, but don’t tend to be a long-term team given the size.

  • The above should be considered in the context of an existing organisation but won’t necessarily give you concrete practices to de-scale the work/interaction/dependencies although it’s a good start. What people often need is a platform-based approach (see Jabe Bloom) and the book Continuous Architecture by Murat Erder and Pierre Pureur.

  • A focus on technical agility and technical excellence is also a trait common to successful Agile adoptions. With a reference to the domain-specific technical practices used to build the product or to supply the service the organisation offers.

The journey itself to learn and adopt Agile is unavoidable. It is not possible in any way to fast-forward or skip to the finale. Each Agile adoption is a gradual process of exploration and discovery. The destination takes shape and acquires meaning by going through the journey. And it is a place where continuous improvement is the norm.

top

Thank you

Thank you for writing, commenting, reading, and spreading this document.

This work is licensed under a Creative Commons Attribution-Share Alike 4.0 International License.
![Creative Commons License][image1]

top

Appendix 1 - Sources

top

Case studies

U.S. Air Force

ThoughtWorks

BlueDolphin

Volvo Cars

ANZ Bank

Capital One

FitBit

Peaksys

Beijer Electronics

Equal Experts

Conclusions

top

SAFe experts’ opinion

Al Shalloway

Bob Galen

top

Opinions from the authors of some practices assimilated by SAFe

Jeff Gothelf

Dave Farley

Ken Schwaber and Jeff Sutherland

top

Agile experts’ opinion

Ron Jeffries

Andy Hunt

Martin Fowler

Alistair Cockburn

Brian Marick

Ken Schwaber and Jeff Sutherland

Mike Beedle

top

Other experts’ opinions

Chris Matts

Marty Cagan

Mary Poppendieck

Dave Snowden

Steve Denning

Barry W. Boehm

  • Balancing Agility and Discipline: A Guide for the Perplexed by Barry Boehm.
top

Sample of practitioners’ opinions

Koen Vastmans, The agile blender blunder

Paweł Huryn

Kevin Bendeler

Sam Haynes

Luca Minudel

Many other practitioners

top

Appendix 2 - Original ideas assimilated by SAFe

In order to avoid misunderstandings, misinterpretations and malapropism of these ideas, you can go to the original source. Material on these topics is widely available in the Agile Community for free.

Alternatives to outdated pre-Agile SAFe practices

  • Alternatives to Release Trains (ART):
    Continuous Integration, Continuous Delivery, DevOps
  • Alternatives to PI Planning:
    ThoughtWorks’ Lean Inception
    Google Design Sprint
    Lean Value Tree
top

Appendix 3 - Safe alternatives (to SAFe)

How to achieve Agility at scale with tangible lasting benefits for the business, with ways of working embraced by those doing the work with a desire to continue using them.