Disciplined Agile

Why SAFe Being Architected Around Levels Makes It Easy to Start But Difficult to Maintain

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

SAFe is organized around levels:

  • Essential SAFe is the most basic configuration of the framework and is intended to get teams working together.
  • Large Solution SAFe adds getting multiple Agile Release Trains (ARTs) working together.
  • Portfolio Portfolio adds the strategy of the organization.
  • Full SAFe includes both Large Solution and Portfolio SAFe

Most companies start with Essential SAFe, the intention being to enable a quick start that provides immediate improvement.  While this is often achieved, most organizations experience a stall or even backtrack in their progress. This is not so much due to their implementing SAFe improperly as it is that starting at the program level and working up has inherent challenges to it.

True agility requires:

  1. proper strategy and portfolio management so that work can be properly distributed to the teams
  2. teams being organized properly so that they can pull this work and avoid overloading themselves while being able to coordinate with each other
  3. teams working in an effective manner

The challenges of starting at the program level are different, depending upon the size of the organization.

The Challenge of Starting at the Program Level for small to mid-size organizations

More large companies are collections of smaller development organizations. So this section may be relevant to you even if you are part of a very large organization. The way SAFe is organized by levels puts you in a damned if you do, damned if you don’t situation.  Consider Figure 1 below.

SAFe essential

Figure 1: What’s needed but missing in Essential SAFe for small to mid-size organizations

The concepts and practices in the higher levels are still needed in these organizations. Unfortunately, they were designed for really large organizations and are therefore more complex than what is needed. Your choice is to use only Essential SAFe and miss much of what’s needed or take on Full SAFe and over-burden yourself with complexity.

This creates a dilemma for any small company who wants to just use Essential SAFe or for small development organizations in large companies – you either have to adopt more than you need or you have to leave out much of what you need.

The Challenge of Starting at either Essential or Full SAFe for Large Organizations

If you are a very large organization you get caught in the damned if you do and damned if you don’t as well.  Starting with Essential SAFe is clearly focusing on only part of your problem. It is likely an attractive place to start, but it doesn’t get at the issue of reducing the dependencies across the ARTs. Although Essential SAFe is designed to get teams in a train working together and Full SAFe is designed to get ARTs working together, to be effective you need to decouple the teams and ARTs instead of dealing with the extensive coordination required if you don’t.

Another Challenge With Levels

Another challenge is if you start with Essential SAFe the jump to the higher levels creates a significant bar of adoption. Whatever appetite for change was present in the organization is often used up in the Essential SAFe adoption. Taking on another initiative to implement the higher levels is often too long a bridge to cross.

How This Causes SAFe Adoptions to Plateau of Fall Back

SAFe has become notorious for having a good start only to plateau or even fall back from what it achieved. This happens so often it is inappropriate to blame the individuals in the organization. The sequence of events that result in this are:

  1. Initial SAFe improves the efficiency of the trains
  2. Little has been done, however, to identify the smallest items of work that can be built and have value realized for that can also be sequenced to improve the sequencing of work. SAFe’s use of epics and MVPs is insufficient for the task. New concepts are needed (and will be presented later).
  3. After the initial improvement, management:
  1. takes an attitude they’ve done their part getting things started and
  2. start demanding even more get done

This last step is the killer. SAFe devolves to the push system it was trying to eliminate. Even though the teams are working better together, the dependencies across them has not been significantly reduced. By not providing a way of getting small, clearly identified increments to work on that are properly sequenced, the extra demands soon result in more delays and work going beyond capacity since delays literally create additional work to be done.

While SAFe may profess the dual-operating system many now espouse, it doesn’t provide the mechanisms or perspectives on getting there. This will not be surprising to system-thinkers. System-thinkers recognize that systems are more about the relationships between the components than they are about the components themselves. Organizing SAFe around levels makes it difficult to see how the different roles, artifacts and practices interact with each other. A different perspective is needed and is presented in the next chapter – Seeing SAFe from a Value Stream Perspective.