If you go to almost any Agile conference these days, the topic of SAFe is sure to come up. You are virtually certain to hear some good things and an equal number of bad things about it. There is no question that SAFe provides some value, but why the vehement insistence by many Agile consultants that SAFe is not Agile? Also, even though many companies that are using it, why are many not very excited about it? Exploring the answers to these questions can give us insights into why and how to use SAFe more effectively.
This article discusses the “good”, the “bad” – the counter-productive aspects,– and the “ugly” – those parts of the framework that can be misconstrued or don’t provide enough information to implement – of SAFe. If you are considering using SAFe, this article should help you decide if and how to adopt it. If you are already using SAFe and are having challenges, this should also help you get better results from your ongoing implementation.
An Objective View of SAFe
There are many concepts and directives that SAFe provides that are absolutely essential in doing Agile at Scale. These are:
These concepts and directives are easily identifiable in SAFe’s big picture, which defines a path for success and everyone’s role on the journey. In particular, SAFe appears “safe” (pun intended) because it:
These are good things and provides a starting point for an organization.
Ironically, SAFe’s promise of being a full solution creates the another set of challenges. If SAFe were implemented as a framework, it would suggest some tailoring or expansion to fit each organization. Instead, SAFe is presented as a complete solution and actually discourages modifications to it. This unfortunately creates a “one-size fits-all” solution approach and focuses organizations more on implementing SAFe than on solving their own challenges. True success with Agile at scale requires the following:
SAFe, as a solution, includes only Point 4. While points 1-3 are very important, point 5 is critical, and unfortunately does not arise very much in the Agile community. In other words, Inspect and Adapt has come to mean “how well are we following the prescribed practices” but rarely includes reflection on if the prescribed practices should be being followed. For example, in a Scrum retrospective, we may ask how well we are doing our sprints. But we don’t question if we should be doing sprints. In SAFe, since it’s a framework, we should not just be asking how well we are doing its practices but we should also be asking if these are the right practices we should be doing.
SAFe encompasses more than just the team, so there is an even greater need to ask these sorts of questions. While the “good’ mentioned above will get an improvement of 20-30% for many organizations (a significant improvement which explains a lot of SAFe’s success), the lack of looking for practices tailored for the specific organization adopting SAFe almost certainly guarantees a plateauing of success if SAFe is continued to be followed “by the book.” The one-size fits all approach also brings the risk of addressing the wrong challenges at the beginning and not providing enough success to continue The “all-in all-the way” approach can result in too much change initially which overwhelms an organization.
While SAFe addresses many important issues, the solutions it provides are often not the best available, or not deep enough. For example, many practices can help sequence work, other than the “weighted shortest job first” algorithm that SAFe recommends. In fact, SAFe borrows the idea from the work of Don Reinertsen, and modifies it in a way that many Lean experts would say degrades its effectiveness. Still, even if SAFe used WSJF exactly the way Reinertsen intended, it would not be the only algorithm that someone might use. The sequencing approach for a new mobile app, designed to attract and retain customers, might not be what you use for a technical debt-ridden back-end system.
Other suggestions provide a good starting point, but don’t provide enough detail for most people to follow. For example, UX and business intelligence groups often have very idiosyncratic ways of organizing and working. Not only do they work differently than most software teams, their approaches may vary widely across organizations. To effectively incorporate them into a scaled Lean-Agile work process often requires more understanding and guidance than SAFe currently provides. That’s fine, as long as SAFe is a framework open for adjustment, not a fixed solution.
The Bottom Line
If one follows SAFe’s mandate of “all-in all-the-way” and treats it as a solution instead of the start of the journey, the following often results:
How to Use and Adopt SAFe
In essence, SAFe should be used as a framework, not a full solution. This means:
There is no question that SAFe provides useful insights and direction. Adopting SAFe can be a very good way to start a Lean-Agile transition to Agile at scale. However, a pure, out-of-the-box adoption has significant risks, and is likely to curtail the benefits that could otherwise be achieved.
Critical thinking and modifications are needed to expand from the initial SAFe implementation. Both are definitely needed if a SAFe implementation stalls. . One must remember that no single solution will work everywhere. Although it is tempting to go for a complete well-defined solution up front, one must keep the focus on learning how to learn – so as to achieve long term success.