Be aware! A painful list of misconceptions about SAFe

The Scaled Agile Framework (SAFe) has found widespread adoption and with endless training and certification options available on the market, it is not surprising that it continuous to be the most popular scaling framework today.

Now that is great, really great, as we believe that SAFe is a great vehicle that can help organizations excel in the marketplace. The tricky part is that you can not simply adopt SAFe by “flipping a switch”. It requires you to change your ways of working, but also your organizational structure, the way you manage your portfolio, and how you empower your teams. It requires change from every single person that is part of the system. Now as if that was not tough enough, you are also often challenged with a number of misconceptions about what SAFe is and how it works, which leads to misunderstandings, but even worse, disappointment with agile methodology in general, leading folks to circle back to old habits in many cases. 

We put together a list of the most common misconceptions you might come across, and outline why you need to be aware and take action when you hear them: 

1. “We need to adapt SAFe so it works for us”

Hearing that you need to adapt SAFe to fit a specific business environment is a dangerous starting point. While it is understandable that you might not start out with Full SAFe, but rather with Essential SAFe, there are areas you should not adapt or leave behind that are put forward by the framework. For example adopting the lean-agile principles is key, in order to align everyone on the agile release train towards a common goal and to create the right mindset to be successful. The same goes for the relentless efforts to plan dependencies and align the agile release train. If you notice an immediate urge to adapt SAFe, you need to be careful and pay close attention. A common tendency is to reject the parts that are hardest to implement and change, but those often turn out to be the most important areas in which change is needed. It is a good trigger for you to “dig deeper” and understand the reasons why the framework should be adapted. The learning from these conversations highlights the specific areas where you need to apply coaching and change “old habits”. 

2. “I can still do what I want and operate independently” 

You might hear this phrase from sceptics (and there are many), but to be fair, often also from teams or team members that have been successful with their individual teams in the past. They feel that there ability to decide and drive their projects forward is diminished. And they do have a point! By implementing SAFe, you apply system thinking and require your team members to act as a one big team, focusing on common objectives. Those common objectives have to exist though. You cannot start SAFe and assume that your team members will act as one, if there priorities and targets are not aligned. If these comments are simply a misconception, you might be ok. But if they are result of an actual missing or even non-existent shared purpose of your system, you might have to reconsider whether you are making the right decision to adopt the SAFe framework. If the common goal exists and the business need calls for a framework like to SAFe to be implemented, you need to follow through and ensure that you apply system thinking across the board.

3. “Let’s implement SAFe for our small team”

A natural and often useful approach is to “start small”. Doing small projects, slicing the scope of what you are trying to deliver and the like are all helpful tools and actually much related to the agile mindset you want to create. But you cannot simply apply that approach to SAFe. Even when you choose the most basic version, Essential SAFe, you are building up a system that includes new roles, ceremonies and requires skilled agile coaches to support your journey. It is a framework that suggest to have at least around 60 members as part of your release train. If you have significantly less members, you are creating “overhead” with SAFe that can actually create a serious negative effect. People may feel burdened with SAFe and rightfully so, might wonder why you are not applying other frameworks that could be a better fit and a more "lightweight" (e.g, Scrum of Scrum or in smaller teams, Scrum or Kanban). 

4. “SAFe is a great portfolio management tool”

If that is your main intent, we do not suggest to apply SAFe. While the Portfolio level of SAFe provides valuable tools on how to manage a portfolio, and even more so to develop a portfolio that is based on value (e.g. by applying WSJF), SAFe is much more than that. It focuses on system thinking and transformation of an entire unit or organization.Thus considering SAFe to be only about portfolio management is a misconception, that unfortunately leads to the perception that you are “doing SAFe”, although you just look at one layer. The danger here is that this can become a shared understanding of what SAFe is about, and that it is “easy to implement”, as you just need to determine the projects you are trying to do by running them through structured prioritization. It is a sign that there is a lack of understanding that applying a scaled agile framework is hard and requires significant change. To be fair, this is by far the least concerning misconception, but nevertheless one that provides an opportunity to educate and explain the benefits of a SAFe implementation, which goes far beyond portfolio management.

This article was written together with my co-author, Matthias Bullmahn, systemic and Lean-Agile Coach and trainer.