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

Overview

SAFe provides many good concepts to organizations that are either planning to go Agile or who have already been doing it but have not been able to get their teams to work together well. While there are many things to learn from SAFe and the overall view it provides is useful, the solutions it provides are often not the best available or deep enough to truly help. In many ways SAFe is a waterfall analysis and planning approach using Agile teams for implementation. It can definitely move large organizations towards Agile but will not achieve it on its own.

SAFe is mostly a collection of practices developed elsewhere and put together in an attempt to create a cohesive system. While SAFe creates an understanding of what is needed across an organization, its piecemeal growth has resulted in a disjointed system that is more complex than is necessary. In addition, some of these practices have been modified from their original intentions, and, unfortunately, not always for the better.

SAFe attempts to solve its complexity challenge by having different configurations – Essential, Large Solution, Portfolio, and Enterprise. The levels are implicitly correlated to the size of the organization using it. Small to mid-sized companies (up to several hundred in development) or self-contained groups within larger companies, however, need many of the concepts needed at the levels above the program. This has created the challenge of forcing people to implement all of the levels or leave important concepts out even though all organizations need them. This is discussed in detail in the Why Essential SAFe is Both More and Less Than What’s Needed at Small to Mid-Scale chapter.

For organizations that need a well-defined starting point with training materials they can license, SAFe may offer a vehicle to create a common understanding of what is generally needed. However, how to start with it must be carefully considered since its all-in all-the-way approach tends to lock people into its starting practices when others are almost certainly more applicable.

We can learn from SAFe but should not get caught up in having to follow it.

The Overall Picture SAFe Provides Us

In the previous chapter (SAFe From a Value Stream Perspective – please read now if you haven’t already) I showed how to view SAFe from the perspective of the  value stream. Doing so both puts our focus on the work, not so much the roles and artifacts, and enables us to better see why SAFe is useful.

Earlier in this book we discussed the need for the following to be accomplished in order to be effective:

1. make agreements across the organization on how to work together
2. create strategies with clear objectives and key results that can be seen across the organization
3. identify the most important business increments to build and to realize value from
4. have a well-defined intake process that has clearly defined requirements with acceptance criteria
5. plan work in a time frame and manner that enables the greatest amount of value to be realized
6. organize the development groups around the products, services and internal operating needs of the organization and have the teams work with the Agile approach appropriate for them
7. integrate the development group with any ops, marketing and support organizations necessary to realize value
8. add any missing roles necessary to the facilitation of flow.

Let’s look at how well SAFe provides each of the items to us by looking at SAFe viewed from the perspectives of the value stream.

Rating SAFe in the Value Stream

SAFe has been known to work well at the program level but that few adopt the upper levels. I’ve color coded how well SAFe does the aforementioned needs for effectiveness going from green (good) to red (missing). The visual confirms the observations. Let’s go through each and explain the rating.

Create strategies with clear OKRs

COMPLICATED AND CONFUSING. SAFe is very complicated and confusing here. Their tying strategies to the level of a large organization makes this more complicated than it needs to be for small and mid-size organizations. You’l find very few even attempting it. The redefining, reusing and overloading terms such as MVP, MMF, Solutions and Epics, makes it very confusing, adding to the complexity.

Identify most important items to build

COMPLICATED AND CONFUSING. To be fair, few do this well. It requires the equivalent of the minimum business increment which SAFe does not have explicitly. Their reuse of the MVP and the redefinition of the MMF are confusing at best. While SAFe appears to provide this information, it does it at the epic and feature level. Epics, though, are too big to do WSJF on since not all of the epic will be built. Features, however, if not valuable to the customer on their own, does not really have a cost of delay. MVPs are used for discovery, not defining what the next chunk of value is for an existing product or service.

Have a well defined input process

EXCELLENT. SAFe shines here and this is one of the main reasons SAFe works so well. If all you do is avoid overloading teams they will improve significantly.  SAFe’s reducing the size of the work items coming into the teams also has a significant improvement – even if they are not always sorted properly.  Eli Goldratt once remarked – “Often reducing batch size is all it takes to bring a system back into control.” This is definitely one of the high quality aspects of SAFe.

Plan your work

GOOD for large organizations. FAIR for mid-size ones.  For large organizations that couldn’t get anything done in a year, it would be quibbling to argue the organization could do better than 3 months. But for mid-sized and smaller organizations, planning only 2-4 weeks out is readily achievable and is much more effective and efficient.

Organizing development groups and how they work together

GOOD to POOR. SAFe has mixed ratings here. If all you have are teams with dependencies between them then SAFe’s ART creation is fairly good. But if you have one or more platforms that support each other or that support separate applications, SAFe’s ART creation is too simplistic.

Technical Agility

FAIR. SAFe’s technical agility has good and bad. All of SAFe’s technical training has been done by people outside SAFe.  There are intricacies in the relationship between process agility and technical agility that is hard to understand unless you understand both.  See  SAFe is not created where requirements, analysis and development are cohesive. See The Relationship Between Acceptance Test-Driven Development and Design Patterns. SAFe also does not have a stand alone ATDD course but merges it with its ASE course which means essentially that product owners won’t be in full attendance. But most important, SAFe relegates ATDD training to the second tier – it should be taught right up front.

DevOps

GOOD. SAFe doesn’t do anything special here, but it attends to DevOps well. Again, this is where SAFe shines in that it lets us know what we have to do.

Rating Other Factors

Make agreements across the organization on how to work together

MISSING. SAFe, like other frameworks, just suggests people do the framework. We have found  that people agreeing how they are going to work together, as we describe in the Guardrails, to be invaluable. These can readily be added to SAFe, of course.

Roles in Essential SAFe

MISSING in Essential SAFe. The roles in the higher levels of SAFe are still needed for small organizations doing Essential SAFe but the way SAFe is defined they are missing in it.

Systems Thinking and Lean

MENTIONED, not followed. SAFe mentions systems thinking and Lean but doesn’t really abide by either. Systems thinking is not attended to by having SAFe being implemented in pieces. That’s not how systems works. Lean thinking is not being followed because SAFe works in big batches. See If Russ Ackoff had Given a Ted Talk for a brilliant description of this.

Training materials

GOOD but not flexible. One of the biggest attractions to SAFe is the large breadth of training materials available. Unfortunately, how to use them is not offered. And the training materials have to be presented as is – even though SAFe says you can use it as a flexible framework. In reality, that is just not true.

Summary

SAFe’s biggest value is that it discusses the need for many things even if it doesn’t provide it well. At the program level, it’s pretty good and this is where you see it used the most. If you are a small to mid-sized organization, however, there are better solutions. Our suggestion if you are using SAFe is to take what works and use FLEX to improve it. How to do this is the topic of the next chapter.