Facing Criticism: Is SAFe® the “Fast Food” of Agile?

January 21, 2015

Scaled Agile Framework (SAFe®), safe-the-fast-food-of-agile-336x336 Facing Criticism: Is SAFe® the "Fast Food" of Agile? SAFe the standardized framework for the adoption of Lean and Agile practices in large enterprises, has had to face criticism from various sources, most importantly from famed experts such as Neil Killick (Agile and Lean thinker and trainer), Ken Schwaber (one of the founding fathers of Scrum and Agile), and Ron Jeffries (one of the founders of XP).

The main argument they all have in common can be summed up as follows: SAFe® isn’t really pure Agile.

Most of those criticizing SAFe® are willing to admit it could bring major improvements to large organizations, improvements resembling those that can be achieved by applying “pure Agile” methods in smaller teams. Still, they think SAFe® lacks dedication to the basic values of Agile that are supposed to bring about the necessary change. SAFe® is generally regarded as a too cautious way of implementing Agile in large enterprises.

SAFe®: the fast food of software development methodologies?

In his often cited article titled unSAFe® at any speed, Ken Schwaber argues that SAFe® is practically “suffocating” teams with a rigid methodology that was meant to help scaling the Agile way of developing software. He thinks that SAFe® goes directly against one of the basic principles of Agile: Individual and Interactions over Processes and Tools, and that scaling should involve the very same principles, letting the people that do the work figure out a way to apply the framework in large organizations – in other words, SAFe® just isn’t necessary. Ken Schwaber, in accordance with the other critics of SAFe®, say that the Scaled Agile Framework lacks the flexibility that is practically the essence of Agile.

In his really detailed and insightful article titled SAFe® – Good But Not Good Enough, Ron Jeffries argues that SAFe® is neither really Agile, nor really safe – it’s the “fast food” of the Agile world. Similarly to Ken Schwaber, he thinks that true agility starts from bottom up, within smaller teams, and if all teams practiced true Agile, there wouldn’t be a need for a structured change in the first place. His bottom line is that SAFe® is good and most organizations can and will take advantage of it, but it’s not as good as implementing pure, “true” Agile instead.

SAFe® in practice

While all that critcism seems to make perfect sense in theory, it’s important to take note of the realities: with their complex decision-making mechanisms, dozens or even hundreds of teams, and stakeholders demanding transparency, large enterprises often need a structured approach to implement such a significant change. As shown by the examples above, some highly regarded experts argue this limits the achievable level of agility by large organizations.

In fact, as a response to Ken Schwaber’s criticism, even Dean Leffingwell, SAFe® advocate admits that implementing strict Scrum + XP with no standardized approach whatsoever has brought about problems in large organizations, and as a consequence, they were forced to take a new approach by adding extensions, and documenting them in what is today known as SAFe®. That said, he also adds that people form the backbone of their framework, and that SAFe® is practically a “people and organizational system”.

To put all that in plain English, it seems to be clear to even supporters of SAFe® that it may not be as effective as implementing pure Agile, but at least it allows large enterprises to safely take advantage of a framework that’s extremely difficult to implement correctly, even in small teams. Admittedly, it does initially limit the agility achievable by the 100% implementation of Scrum or another Agile methodology, but at least it’s structured and safe enough for any organization to get started – ideally, on the long and curvy road to true agility.

In other words, SAFe® should not be considered an end goal, limiting the use of Agile; on the contrary, it should be treated as the beginning, allowing large organizations to achieve some of the benefits of Agile while starting them off on the right foot to the end goal of true agility.

Both critics and supporters of SAFe® agree that employing the Scaled Agile Framework yields widespread benefits: SAFe® allows them to tap into the advantages offered by Agile. Granted, SAFe® may be a less effective implementation of Agile, but it is a safe starting point for large organizations to implement, and enjoy some of the benefits of, Agile. As the first proven implementation of SAFe®, codeBeamer supports the deployment of SAFe® across large organizations. It is essential for prioritizing requirements across departments, helps quality assurance and compliance with standards, ensures traceability of all artifacts, and enables Agile planning / scheduling while maintaining an established discipline of requirements. Overall, codeBeamer can help ensure your transition to SAFe® is successful, regardless of the size of your organization.

SAFe® and Scaled Agile Framework are registered trademarks of Scaled Agile Inc.

facebook Facing Criticism: Is SAFe® the "Fast Food" of Agile? SAFe twitter Facing Criticism: Is SAFe® the "Fast Food" of Agile? SAFe google Facing Criticism: Is SAFe® the "Fast Food" of Agile? SAFe linkedin Facing Criticism: Is SAFe® the "Fast Food" of Agile? SAFe



Related E-Book

SAFe® Template Brochure

First Name

Last Name

Email Address


Phone Number


Kristof Horvath

Written by

Kristof holds a BA in Commerce and Marketing and is especially passionate about inbound and content marketing. On the Intland blog, he is covering topics related to application lifecycle management and agile methods.

Kristof Horvath has written 103 posts for Intland Software.

3 Comments. Leave new

Greg Bennett
28 January 2015 14:58

I find it fascinating when people who claim to be ‘experts’ on something get all fussed about someone else’s interpretation of how that something should be done. I can’t help but think, in this case anyway, about people who like Jazz music.

I particularly like the quote ‘Jazz presumes that it would be nice if the four of us, simpatico dudes that we are, while playing this complicated song together, might somehow be free and autonomous as well. Tragically, this never quite works out.’

This isn’t to say that Jazz or Agile is a bad thing. Quite the opposite. Both have yielded breakthroughs in their respective domains, and moved the art form forward dramatically.

It seems SAFe is intended to help when you are moving from ‘four simpatico dudes’ into a much larger orchestra. In larger organizations, you have people in motion who may not even be ‘musicians’, but they are just as dedicated to end product as anyone involved. SAFe helps these people understand what their role is. If they better understand what it is that they need to do, and can see how and when it is packaged and passed along to the next autonomous player, I fail to see how this could be viewed as a bad thing. Maybe not necessary in every case, but surely beneficial to some.

These days, you can find as many articles on how to do Agile as you can how NOT to do Agile. Many organizations are recruiting all manner of people to teach them how to be Agile. They lay out some of the basics, but it seems that after that engagement, people are still left with numerous ‘yes, but what about this?’ or even ‘what about me?’. Maybe for Agile to be truly successful it actually needs to find a balance between philosophy and dogma.

So yes, there certainly is a place for free and autonomous creativity, but sometimes a little orchestration is necessary. I believe that is what SAFe is trying to offer.


Thanks for your comment, fully agreed – in fact, the main message the article is trying to convey is somewhat similar to what you’re saying. Some orchestration simply seems necessary if you’re trying to implement Agile on a larger scale, and that’s just what SAFe is trying to do. It may not be perfect 100% pure Agile, but it helps larger enterprises set out on the road to achieve that goal.


Leave a Reply

Your email address will not be published. Required fields are marked *