SAFe: Here’s Where the Critics get it Wrong
James Halprin, helping organisations through Lean-Agile Transformation
Before we clear up some misconceptions about the Scaled Agile Framework® (SAFe®), a brief history will help set the scene.
When Agile first came into being in 2001 with the creation of the Agile Manifesto, the focus was primarily around standing up cross functional Agile teams with the goal of trying to ‘satisfy the customer through early and continuous delivery of valuable software.’ The predominant organisational structure of the day was departmental silos and releases could be a year or more apart, so standing up cross functional teams that could deliver value early and often was a challenge worthy of attention.
While standing up a series of largely independent cross functional Agile teams was a significant step forward, new impediments began to emerge.
Due to the size and complexity of many of the solutions being built, the next big challenge for organisations was how to align and coordinate work across multiple dependent Agile teams. Further compounding this challenge was that Agile teams emerged within the existing organisational structures and processes that had been established to govern Waterfall rather than Agile development. So while the Agle teams had changed, the organisations around them were largely unchanged and this ultimately limited the benefits that Agile could bring. For example, if PMOs had been established to help coordinate programs of work across multiple silos, what is their role, if any, when working with cross functional Agile teams?
So not surprisingly the Agile community started turning its attention from Agile teams to the challenges of Agile at scale. This work started around 2007 but it really gained a lot more traction in 2011 when SAFe was introduced. While the predominant scaled Agile frameworks were once SAFe and Large-Scale Scrum (LeSS), today there are many more frameworks competing for attention.
Ever since the emergence of ‘Agile at scale’ it has been a hot topic in the Agle community resulting in passionate debate from all corners. On the one hand we’ve got frameworks like SAFe that advocate for appropriately scaling the principles and practices of Lean and Agile throughout the enterprise while on the other hand we’ve got frameworks like LeSS arguing the opposite.
SAFe is a knowledge base of proven, integrated principles and practices for Lean, Agile, and DevOps that help large organisations tackle the challenge of Agile at scale, and is currently the most popular method for scaling Lean and Agile.
Given that SAFe is the most popular and well know scaling framework, it has often been the focus of critics ire. While I’m all for a healthy debate, unfortunately the majority of critiques I’ve read on SAFe have one common thread — the critiques more often than not mischaracterize the intent of SAFe and demonstrate a lack of understanding of the framework. In some cases, the critics have even openly admitted that they have never worked within a SAFe environment and are only imagining how it would be.
Leverage Elabor8’s deep experience in the Scaled Agile Framework (SAFe) in your transformation.
So against this backdrop, I’d like to set the record straight and clear up a few misconceptions about SAFe.
1. SAFe is not designed for every context
Does every problem need a hammer? Of course not!
SAFe is not designed nor is it necessary for every context. If you are either not working at scale e.g. require less than 50 people to build your solutions and / or have few dependencies across teams, then there are plenty of other options that might be more fit for purpose. Although there are still plenty of learnings that can be taken from SAFe, a full SAFe implementation is not required in these scenarios.
Further, while SAFe might be appropriate in certain parts of an enterprise, that does not mean that SAFe needs to be rolled out everywhere — only implement SAFe in those parts of the organisation where it makes sense.
2. SAFe is a Lean-Agile framework, not a methodology
A framework is intended to support a particular approach to a domain by offering an overview and some guidance that can be adapted or augmented as required based on the context to which it is applied.
In other words, unlike a methodology, a framework should not be treated as a cookie cutter that can be applied the same way in every context!
This is where the Lean and Agile values and principles that underpin the framework come into play. If elements of the framework need to be adapted or augmented based on context, the underlying values and principles will act as the all important compass to ensure you are moving in the right direction. While people will naturally tend to focus on the ‘how’, it’s important to never lose sight of the ‘why’.
3. SAFe is a configurable framework
Prior to the current version of SAFe, there was some confusion around the configurability of the framework. Can SAFe be configured and if so, exactly what should be adapted and what should be adopted?
That confusion was cleared up in the latest version of the framework (V4.5), by explicitly calling out four configurations of SAFe — Essential SAFe, Portfolio SAFe, Large Solution SAFe and Full SAFe. Essential SAFe is the primary configuration and the foundation on which everything else is built. It provides a starting point for implementing SAFe and describes the most critical elements needed to realize the majority of the framework’s benefits. Only after this foundation is in place should the other three configurations of SAFe be considered.
4. SAFe is not about command and control
The entire SAFe framework can be viewed in a single image, which is known as the Big Picture.
While the Big Picture is a great way to visualize the framework, the four horizontal levels of the framework — Team, Program, Large Solution and Portfolio — can sometimes be interpreted as a command and control hierarchy, which is absolutely not the intent!
SAFe has nine principles that guide the framework, and SAFe principle #9 is to ‘Decentralize decision-making’. While some decisions are best kept centralised such as those that have long lasting implications or benefit from economies of scale, in fact the vast majority of decisions should be decentralised. Taking a traditional mindset to implementing SAFe can lead to a command and control hierarchy being implemented, but this pitfall should definitely be avoided at all costs.
5. Leadership is lacking
The 12th Annual State of Agile report from VersionOne found that the 3rd biggest challenge to adopting and scaling Agile was, ‘Inadequate management support and sponsorship’. This challenge is independent of the framework you chose — without leadership actively driving the change then it will only go so far. As Deming taught us, ‘People are already doing their best; the problems are with the system. Only management can change the system’. Unlike other scaled Agile frameworks, SAFe places a very large emphasis on the role of Lean-Agile leaders in the transformation.
6. Shu Ha Ri
If you are working in a large traditional enterprise that has little to no experience with Agile and are faced with the significant challenges of developing large complicated solutions in a rapidly changing environment, how do you effectively transition to Agile? Shu Ha Ri provides us with a path forward.
When we seek to learn a new discipline we pass through the stages of Shu, Ha, and Ri. Shu Ha Ri is a Japanese martial art concept, which describes the stages of learning to mastery.
In the beginning stage, Shu, we don’t know what we don’t know so we learn by following the teachings without deviation. A great example of this is when Mr Miyagi from the movie, The Karate Kid, tells Daniel san to ‘wax on, wax off’. In Ha, we have internalised the learnings and are in a better position to start experimenting with new forms. Finally, in Ri, we can depart from the original teachings altogether and use our own deep understanding to create new approaches.
SAFe provides a great deal of guidance including role based training and implementation patterns — the Shu — and in this way is a great way to get the change journey started. Whether SAFe is the ultimate destination or just a transitory vehicle on the road to agility is really up to the organisation to decide.
Agile at scale is a hot topic and I don’t expect that to change anytime soon. However if we are going to have an informed debate then it’s important we have an accurate understanding of the intent of the different approaches and are not making judgements based on misguided implementations.
Call To Action
Get in touch if you’d like to discuss scaling agile within your organisation.
If you liked this blog, then you can check out my other blogs here:
