SAFe: a collection of comments from leading experts

Image from BrownSafe.com Antique Vault Doors

Some of those who helped shape SAFe and other major SAFe experts, some of those whose techniques have been integrated into SAFe, some of those that worked with many organisations that adopted SAFe, and some of the leading experts in Leadership, Management, Tech & Agile including 10 co-authors of the Manifesto of Agile Software Development, all advise against adopting SAFe.

This collection with their comments is periodically updated as new info becomes available. Feels free to copy and distribute this post as you please.

Brian Marick, 2019-2022

Brian Marick is a programmer and software testing consultant. He is also a co-author of the Agile Manifesto and former chair of the Agile Alliance.

After Brian’s initial comment from 2019 here “I don’t know enough about SAFe to have an opinion.” he later add two comments in 2021 and 2022 on:
– SAFe problematic prescriptive nature with *the* set of rules to follow, fret about and enforce (here)
– SAFe overly-codified processes actively working against the collective creation of tacit knowledge (here).

Jeff Gothelf, May 2021

Jeff Gothelf with Josh Seiden is the co-creator and co-author of Lean UX, as well as of other award-winning books. Sharing his thoughts on SAFe based on first-hand and secondary evidence with several clients.
Commenting on how SAFe and Lean UX works together he says that “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 mix together. Neither he does have any good answers for them, since moving off the framework is heresy in most cases.

He concludes that “In short, SAFe is not agile.”

Read his full account here: SAFe is not agile.

ThoughtWorks, April 2021

ThoughtWorks, a global technology company that’s unanimously considered an authority in Lean and Agile. Since 2015 ThoughtWorks explicitly discourages the use of SAFe, and suggests Lean alternatives because actual SAFe adoptions are prone to over-standardisation, resulting in practices that hinder Agile adoption. In April 2021 after observing several more clients adopting SAFe ThoughtWorks adds a long list of observations, here are a few: SAFe create friction in the organizational structure and its operating model, promotes silos, hinder tech from creating business capabilities, generates waste in the value stream and discourages creativity, limits autonomy and experimentation.

The full report is here:

ThoughtWorks update their comments and recommendations whenever they feel that something new has happened. So their comments and assessments can be considered actual even after the publishing date.

Dave Farley, Jan 2021

Dave Farley is a pioneer of Continous 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 as their corporate agile strategy, he noted that SAFe Release Trains practice is anti-Continuous Integration where Continous Integration is a fundamental technical practice of Agile and a foundation of Continous Delivery.
Dave Farley, in a very big organisation adopting SAFe, while working in a team with several hundred members, deviated from SAFe to apply Continuous Delivery principles. Based on internal company metrics, the team outperformed every other team in the org doing SAFe.

He concludes by saying he thinks that SAFe is misguided and that he doesn’t see any evidence that SAFe helps on that journey.

Source: https://www.davefarley.net/?p=337

Al Shalloway, 2018-2020

Al Shalloway is a well-respected industry thought leader in Lean, Kanban, SAFe, Scrum and agile design. He is the author of several successful books, and the developer of the new FLEX framework.

He knows SAFe from the inside-out: he has been one of the first three SAFe Principal Contributors for six years, the first SAFe program consultant trainer outside Scaled Agile Inc, SPCT (SAFe Program Consultant Trainer), and with his company he has been a SAFe gold partner.

He is one of the latest lean-agile thought leaders to “ditch” SAFe (amicably break off the relationship with Scaled Agile Inc, no longer providing SAFe training). Other prominent SAFe figures did the same, see for example Alex Yakyma, SAFe first Associate Methodologist, that also distanced himself from SAFe and Scaled Agile inc.
SAFe fans are surrendering to the request by Scaled Agile inc to implement SAFe in a prescriptive way “by the book” and to the SAFe downsides that grow with every new SAFe version that outweigh even all the pros pitched by the most enthusiastic supporters.

After 6 years he decided to leave SAFe because in his own words:

  • SAFe has grown considerably more complex than it needs to be
  • Many small- to mid-scale orgs (technology <1000 ppl) are looking to Essential SAFe even though is not a good solution for them
  • Many orgs are looking to take “SAFe out of the box” which has never been our approach
  • SAFe training is not tailored to the size of the organization that will use it

He recently added (June 2019) that he stopped being an SPCT after he was told that to renew his certification he had to do a few “by the book” SAFe adoptions. And we know that implementing agile “by the book” it is not agile at all. More recently he also added (Sept 2020) that he thinks it’s more appropriate to call SAFe an improved waterfall than it is to call it a poor Agile. Creating ARTs merely accommodates dependencies and is a poor value creation structure. 3-month PIs is not Agile but is better than annual.

Bob Galen, April 2019

Bob Galen is an Agile Methodologist, Practitioner since the late ’90s and Coach. He is the author of three agile-centric books, a prolific blogger, and a podcaster.

He became SAFe SPC certified several years ago. He tried to understand, support, and apply it, but then he struggled with it for a long time to the point that he just can’t be associated with it any longer.

In his article SAFe no longer – my final farewell (which contains more links on the subject and very interesting comments) he mentions these reasons:

  • It’s too big, far from the principles of simplicity at the heart of agility.
  • It’s sold to leaders to control their organizations – a costly silver bullet.
  • It creates far too many roles, layers, flows, etc.
  • It’s too focused on certifications and training – a cash cow.
  • It’s created a community of SPC’s and other consultants who think being agile is about…SAFe. Who looks at every agile context and thinks SAFe is the solution.
  • It’s created lazy organizations who think that the framework does the heavy lifting of transformation for them.

Several agile professionals that got SAFe certified are becoming disillusioned and are moving away from SAFe for similar reasons.

Steve Denning, 2015-2019

Steve Denning is a recognised expert and author in leadership, management, and innovation. Below are some excerpts about SAFe from one of his articles on Forbes: How To Make The Whole Organization Agile

“Equally, some of the current efforts to ‘scale Agile,’ such as the Scaled Agile Framework or SAFe, are counterproductive.”

“SAFe destroys the very essence of Agile.”

“Like the failed management fads of the 20th Century, it degrades and undermines everything in Agile that is authentic and useful.”

More recently he added about SAFe: “it gives the management a mandate to call themselves agile and keep doing what they have always done” and “My question would be: why would anyone with a genuine Agile mindset be using SAFe in the first place?” reaching to the conclusion that: “SAFe is the epitome of ‘fake Agile’.”

Ron Jeffries, 2014-2019

Ron Jeffries is a co-author and one of the 17 original signatories of the Agile Manifesto, and one of the creators of Extreme Programming. He published one of the most informed and well-presented critiques to SAFe here:

– Issues with SAFe: http://ronjeffries.com/xprog/articles/issues-with-safe/

– all Ron’s posts on SAFe: https://ronjeffries.com/categories/safe/

Ron Jeffries has the habit of updating his posts when things changes or new information become available. For this reason, his post can be considered actual even after the publishing date.

Andy Hunt, July 2019

Andy Huns is a programmer, publisher at The Pragmatic Programmers, and author of best-seller books on software development. He is also a co-author of the Agile Manifesto and founder of the Agile Alliance.

Asked for a comment about SAFe Andy here concludes that “SAFe is not an agile approach.” He also tells “I have friends who have made great careers thanks to SAFe — going in afterwards and cleaning up disastrous, failed adoptions.”

James Grenning, July 2019

James Grenning is the inventor of the Planning Poker agile practice used all around the world. He is a software development expert, both technical and managerial. He is the author of articles and a book on applying Agile to embedded software development. He is also a co-author of the Agile Manifesto.

He says here his knowledge about SAFe is limited, and so he forms his opinion based on the message of SAFe and how it is being adopted. Indeed, he says he has many SAFe friends out there.

In this post he takes a very pragmatic and non-judgmental view on SAFe with an interest in the engineering side:


While I suggest reading the original post (as well as for all the other links in this article) these are a few excerpts that resonate with me:

<<Maybe improvement really has to start with the individual, and the team. One of the things I’ve really come to appreciate about extreme programming is how its practices lead to continuous improvement. >>

<<Looking at Essential SAFe, XP is mentioned. A lot of good things are mentioned. Though it concerns me that the SAFe Road map appears to get teams involved so late.>>

<<If SAFe is where you learn to do agile so you can figure out how to be agile, maybe it will help. I guess time will tell.>>

Chris Matts, 2019

Chris Matts is an experienced Agile practitioner specialised in delivering trading and risk management systems in investment banks. He contributed to BDD with Daniel Terhorst-North (AKA Dan 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.

Chris continues analysing and critiquing the SAFe definition and use of Epics.

These are the posts on SAFe by Chris:

The picture that emerges on SAFe practices, after I put together the comments from Chris and the comments of other leading experts on other SAFe practices, suggests to me that: SAFe practices accommodate the status quo of approaches from the 70′-80′ persisting it.

This is my summary:

  • Epics are redefined by SAFe in a hierarchy of epics and user stories that try to accommodate and institutionalise, as accepted normality, component teams that cannot create autonomously an end-to-end slice of functionality, and accommodates the top-down separation between those that plan the work and those that do the work. The definition of Epic as understood by Agile practitioners is substantially different, it encourages conversations among anyone involved in the work to do at every level, and it encourages cross-functional teams able to deliver autonomously a slice of a functionality, it also encourages frequent releases to keep in sync everyone involved with a piece of work to be done.
  • PI planning focus, just like in 70′ and 80′ practices, is mainly on identifying and scheduling the work and in accommodating existing dependencies. The Agile approach instead is to have teams and team members to pool the work and organise it and organise themselves to minimise dependencies while working on removing incidental dependencies and relaxing the remaining ones.
  • Agile Release Train accommodates the need for multiple teams to release together and encourages synchronisation, standardisation and conformity because expects all teams to adopt the same approach and the same development and release cycle that in turn increases the effort needed for coordination. It is well known that scaled systems rely heavily on asynchronicity. And the Agile approach is to encourage adaptations to each team own circumstances and to work toward enabling each team ability to release independently.

U.S. Air Force CSO Nicolas M. Chaillan, December 2019

Nicolas M. Chaillan is the Chief Software Officer at the U.S. Air Force and the Co-Lead for the DoD Enterprise DevSecOps Initiative.

During the event ‘DoD Enterprise DevSecOps Initiative Ask Me Anything’ Nicolas M. Chaillan comments on questions about his Memorandum for Record on Nov 26th 2019, sent to all PEOs and PMs regarding the use of DevSecOps and Agile.

The memorandum is “highly discouraging from using rigid, prescriptive frameworks such as the Scaled Agile Framework (SAFe).

Here follow a few excerpts from the comments about SAFe in this slide:

Slide 12 of the unclassified slide deck v1.0: DoD Enterprise DevSecOps Initiative Ask Me Anything Event
  • Bloated overhead functions (Waterfall-like)
  • SAFe isn’t used by any successful software commercial organization (Facebook, Google, Netflix, etc.)
  • Fundamentally, the main “goal” of Software development is NOT to be « SAFE », it is to INNOVATE and CREATE. You do not create by not taking risks… it is quite the opposite
  • until we can truly implement basic Scrum/Kanban, there is nothing to « SCALE »
  • You cannot scale if you don’t have the “basics” right.
  • « Continuous Learning: Fail Fast but don’t Fail twice for the same reason! »

The slides & as well as the video of the event are available here: https://software.af.mil/dsop/documents/

Since the publication of this report from USAF, Scaled Agile Inc offered to work for USAF to address the comments above. After that, a couple of publications seemed to imply that the comments have been addressed and SAFe was ready to be adopted by USAF.
Because of that Nicolas M. Chaillan clarified: “my memo on SAFe still stands regarding my take on SAFe with DevSecOps. Until the issues mentioned in the memo are fully addressed with a released update of SAFe, SAFe is still not recommended to be used in conjunction with DevSecOps.” (link).

And on March 2021 Nicolas M. Chaillan clarified again that the situation still stands (link): “SAFe is still anti DevSecOps. Not allowed in my teams.”

Continue reading Part 2 >>
(6 more Manifesto co-authors, 3 more leading experts)

Turbocharge your scaling initiative.

See how we can help.
You, your team, your organisation.