Facing Criticism: Is SAFe® the “Fast Food” of Agile?
Scaled Agile Framework (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.