Loading...

SAFe: a collection of comments from leading experts

Image from BrownSafe.com Antique Vault Doors

This below is a collection of comments about SAFe from 9 leading experts in Leadership, Management, Tech & Agile and 10 co-authors of the Manifesto of Agile Software Development. This collection is periodically updated as new info become available. Feels free to copy and distribute this post as you please.

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 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 distanciated 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 SAFe downsides that grow at every new SAFe version and outweigh even all the pros that the most enthusiastic supporters see.

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) 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 90’s and Coach. He is the author of three agile centric books, a prolific blogger, and pod-caster.

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 (that 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 look at every agile context and think 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. These 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:

blog.wingman-sw.com/is-safe-safe

While I suggest reading the original post (as well as for all the other links in this article) these are 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.>>

Brian Marick and Jon Kern, July 2019

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.

Jon Kern is an aerospace engineer-turned programmer, software architect, and team leader/coach with a focus on methodology and business value. He is also a co-author of the Agile Manifesto.

Brian asked for a comment about SAFe candidly says here “I don’t know enough about SAFe to have an opinion.”

Jon asked for the same comments says here that he want to witness a company doing SAFe before commenting.

The comments on SAFe collected here are indeed from people that speak out of their knowledge and experience and are not afraid to admit when they don’t know enough about a subject to comment on it.

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.
Meanwhile, 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).


Continue reading Part 2 >>
(4 leading experts, 5 Manifesto co-authors)



Turbocharge your scaling initiative.


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