SAFe: The Good, the Bad, and the Ugly

Absorb what is useful, reject what is useless, add what is specifically your own.  – Bruce Lee

This chapter is for those who want a detailed analysis of what works in SAFe^® (the good), what should be replaced (the bad), and good concepts but where better implementations and/or more depth is needed (the ugly). As we go through what SAFe does well and where it could be improved, it will be helpful to keep these things in mind.

The Good

Much of the good of SAFe is that it is the first fully documented system intended to achieve Agile at scale that is holistic in nature and based on Lean. While DA FLEX predates SAFe, its documentation was not available until now.

The biggest contribution SAFe to the Agile community regards its redefinition of Agile at scale from getting teams to collaborate from a bottom up perspective to a business-driven approach where teams collaborate to achieve the results directed by the business. This holistic, business perspective is what sets SAFe apart from Scrum @ scale, LeSS and Nexus – all of which are essentially collective team-based approaches.

SAFe also explicitly uses Lean principles, incorporates Kanban as needed, espouses technical practices and DevOps.  By having a clear role for management (which is needed but not properly attended to by other Scrum based methods) SAFe sets the stage for adjusting the organization at needed.

In addition, SAFe:

• Has a well-defined take process that can avoid overloading the development group
• Big room planning that provides business vision and socialization
• Provides training materials to help companies avoid the need for creating their own
• Leverages an organization’s investment in Scrum and/or other Agile methods
• It’s collection of Inspect and Adapt methods is very effective
• The “introduction” of Weighted Shortest Job First. While WSJF was introduced by Don Reinertsen years before SAFe, it was introduced to the Agile community by SAFe.

The Bottom Line of the “Good”

The net result of this is that SAFe has enabled very large companies to deliver software in three months where before they often were not able to deliver much in a year. SAFe also mentions many good concepts that people can explore on their own.

The Bad

• SAFe ties several concepts to the higher SAFe levels even though they are needed at all of the levels. SAFe started to help groups of companies within a large organization to work together. Portfolio and product management was not addressed initially. As SAFe has grown it has put concepts such as Strategic Themes, solutions, MVPs in the levels above the program level. Unfortunately, all companies and many sub-orgs in large companies, need these concepts. This puts those attempting to do Essential SAFe in the dilemma of missing critical concepts or having too complex a system for their needs.
• SAFe is getting more complicated with each release. As SAFe has expanded it has added more and more concepts in an increasingly complicated manner. The reasons for this is that SAFe is architected around levels and not the value stream. Another reason is its penchant for redefining and overloading terms which is mentioned in the next point.
• SAFe has caused much confusion with its overloading, re-defining and misusing existing terms and concepts. For example, MVPs are intended to be used for new products but are used as the holder of anything that is built in stages that require validation. MMFs were redefined from Software by Numbers’ definition to represent experiments in Lean-UX (they are not in the book, btw). Epics are used several different ways in SAFe. Value streams were redefined in 4.0 and only partially brought back to the 60 year old definition that is commonly used. All of this not only tends to cause confusion but dilutes the knowledge from which they sprang.
• For all of its the terms, there is no explicit equivalent to the MBI in SAFe. The concept of the minimum business increment, which we have found to be the most useful concept in my 20 years of experience with Agile, is not explicitly used in SAFe. An MVP is not the same as an MBI since MVPs are about new products and MBIs are about extensions to existing products. Yet this is missing as an explicit concept in SAFe. This forces people to bring this concept to SAFe.
• Overly complex strategies and portfolio management. The above have combined to make SAFe’s top levels significantly more complex and less effective than they need to be.
• SAFe is used with companies much smaller than it was intended for. One can say this isn’t a problem with SAFe but we consider over marketing of a framework to be part of the framework.

The Bottom Line of the “Bad”

SAFe presents many good concepts but has some serious flaws in how it is designed, extended and used. To properly use SAFe one needs to know many concepts that aren’t in SAFe. Frameworks should contain the knowledge you need, not require you to know things and redefine the definitions in SAFe to work. Taking SAFe as a model to follow causes many challenges that can readily be avoided. SAFe is a framework. Keep the good, avoid the bad.

The Ugly

By “ugly” we mean there is value, but it’s been defined or prioritized in a way that makes it of less use.

• Relegating ATDD to second round training and then offering it from a developer perspective. SAFe is finally offering Agile Software Engineering classes. But it does so with a focus on the developer, not the triad (customer, developer and tester). We have found ATDD to be something that should be delivered in the first round of training. Initial SAFe training ignores ATDD which results in it never taking place.
• Weighted Shortest Job First has been modified to make it simpler (good) but in such a way that it can produce incorrect results (bad) and uses the wrong paradigm to explain it (worse).
• Guidance for creating programs is incomplete and requires a better understanding of value streams than what SAFe provides. There are several ways to create programs, whereas SAFe only discusses one model.
• Planning events can be a great thing in SAFe for large companies. The social aspect and visibility to management vision is very impactful. But a planning event doesn’t need to require the long-term detailed plan SAFe espouses.
• Generic Courses for All Roles and Sizes. The challenge with promoting frameworks is that they focus training on them. Leading and Implementing SAFe classes cover all roles and all sizes of an organization. But if you are a small company or development group you will find much of the training is devoted to topics which have little value for you.

Bottom Line of the Ugly

Take what’s provided in SAFe and always look to make it better.

And the Missing

It’s not fair to SAFe is at fault for anything missing in it. After all, you’re supposed to fill in frameworks. The challenge, however, is that SAFe is so large as it is, and the training and coaching takes so long as it does, that many people don’t look for what’s missing.

• Architecture is mentioned but the guidance is too limited to be useful.
• Lack of Scrum integrated with Kanban. It’s great that SAFe discusses both Scrum and Kanban. But more is often needed in large organizations. Not all teams ideally follow one or the other but require a blend or even need a different approach based on Flow altogether.
• Middle Up-Down Management is the essence of Lean Management. SAFe is consistent with this but doesn’t go into any depth on it.

The Bottom Line of the “Missing”

Know that many things are missing in SAFe and that instead of doing the normal full SAFe training perhaps less SAFe training and instilling a few of these concepts.

The Bottom Line of SAFe

SAFe does several things well but is not the best of the best in many areas. I’ve never understood why people accept less than the best of best. When one considers frameworks to be tools one can take what works, modify what can be improved and put in concepts that are useful. SAFe, in particular, is a collection of other people’s ideas that SAI (the creators of SAFe) have put together. There is no reason you can’t modify it to work better. Of course, “best” depends upon the organization that is adopting it. Using SAFe as a framework for what can work will create a significantly better approach than taking SAFe’s pre-defined methods and applying them across the board in your organization.

While a degree of consistency is important, this can be achieved through the use of consistent terms and intentions. For example every program needs to coordinate their teams and do planning as appropriate but they can accomplish these intentions as appropriate to them.

Let’s see how SAFe does with each of the areas we’ve shown are essential for effective Agile:

• Make agreements across the organization on how to work together. SAFe, as do all frameworks, does not explicitly discuss agreements such as DA FLEX does with the guardrails. Whether intended or not, this has people put a focus on following SAFe as a way of aligning. This creates a box (SAFe) that is hard to get out of.
• Define strategies and tie them to the development teams with portfolio and product management. While SAFe discusses the right issues, it uses a combination of overloaded, redefined and misused terms. This causes confusion and, although SAFe can be used here it does not provide its own path for understanding.
• Well defined intake process. SAFe lays this out pretty well and has some details on handling architectural work with product development value. The challenge with SAFe’s intake process, however, is that, because the equivalent of MBIs are not used in it, it is hard to educate leadership with it as described in the Using the Intake Process to Educate Leadership chapter.
• Planning. SAFe is fairly good here except that it doesn’t provide a way to do just one or two sprint planning when teams are Agile enough to take advantage of this. SAFe’s planning method is intended for large companies with multiple dependencies. When applied to what it was designed for SAFe gets is good. When applied to smaller programs then it is more waterfall than need be. When adopting SAFe this is one of the key areas to consider adapting to your needs.
• Organizing Development Groups and have them work together. Coordination with a common cadence and continuous integration is virtually always the best way to go. However, SAFe provides little guidance when more than a collection of well defined Scrum or Kanban teams are working together.
• DevOps. SAFe does nothing special here but attends to DevOps well.
• Effective management to create a good ecosystem for development. SAFe recognizes the need for this but does little to provide significant guidance.
• Roles required. SAFe does not have the equivalent of the business architect role. It should.

Adopting SAFe

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 initial improvement but stagnate after a year and backslide
• 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

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
• Considering other practices than those espoused by SAFe when they are more appropriate
• Regularly looking to see if the SAFe framework is best achieving the results you want to achieve or if modifications to the framework are necessary.

In Summation

Our recommendation, of course, is to use DA FLEX. But 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.

• DA Transformation Roadmap: Improve SAFe