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.

Main Points

• Where SAFe’s natural strengths lie, so you can decide if SAFe is appropriate for your organization
• Where SAFe’s weaknesses lie, so you can either reduce their effects (if you choose SAFe), or seek another approach better suited to your situation
• Where SAFe needs augmentation to reach its potential in your organization

An Objective View of SAFe

The Good

There are many concepts and directives that SAFe provides that are absolutely essential in doing Agile at Scale.  These are:

• A foundation of several elements of Lean Thinking (in particular, systems-thinking with a focus on removing delays in workflow and feedback with an attention on quality)
• An attention to having business strategy create the contexts for programs and teams
• An intake process that can avoid overloading the technology group by enhancing the focus on the most-important identified work
• Well-defined roles, including the role of management
• A holistic view covering the entire value stream
• An across-the board agreement for SAFe’s adoption
• A planning method that facilitates coordination of teams

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:

• Provides a role for management. While SAFe proposes a model of management that many will find unfamiliar, it at least describes what managers are supposed to do – something the Agile community has essentially ignored.
• Provides an approach that drives from delivering business value while aligning technology with business strategy.
• Leverages an organization’s investment in Scrum and/or other Agile methods.  By providing a “wrapper” for existing success at the team level and promising success at the organization level people can build on their investment

These are good things and provides a starting point for an organization.

The Bad

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:

1. An understanding of an organization’s problem.
2. A tailored approach to solve these problems – this includes identifying the order in which they must be solved.
3. A set of agreements that can be used to move forward in this transitions (we suggest using the guardrails approach we’ve created).
4. A regular cadence of reflection on how well you are doing the practices you’ve adopted, and how can you improve on them
5. A regular cadence of reflection on if you are doing the right thing (that is, should you be doing the practices you’ve agreed to – this requires challenging the approach you are taking).

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.

The Ugly

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:

• Organizations often get some improvement but plateau within 1-2 years and then find further improvements is very difficult
• Better practices are not investigated due to people making SAFe dogma, lowering the return available.
• SAFe ends up being a better waterfall, where teams work in increments but the organization’s agility doesn’t improve significantly.
• Organizations adopting SAFe typically do not become learning organizations because they become more concerned with adopting SAFe than in discovering what truly works for them.  This makes it even more difficult to move off of the plateau that’s been achieved

How to Use and Adopt SAFe

In essence, SAFe should be used as a framework, not a full solution.  This means:

• Investigating where you are and what your main challenges are.  Then adjust SAFe to fit your needs, instead of adjusting your organization to fit SAFe’s solution
• Undertaking a transition to SAFe – that is, adopting those practices that will not cause resistance and that will set the stage for additional progress – achieve a focus on solving your challenges not on implementing the canned solution SAFe provides
• Considering other practices than those espoused by SAFe
• Regularly looking to see if SAFe is best achieving the results you want to achieve or if modifications to the framework are necessary.

Summary

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.