Good But Not Good Enough (2023)

I recently took the SAFe SPC training, with instructors Jennifer Fawcett and Al Shalloway. My bottom line assessment is that it will be a marketing success, organizations trying it will see improvement, and some will see great improvement.

And I don't like it. SAFe isn't really Agile in its heart. It does have many good elements, which I'll talk about here. And I still don't like it. I'll talk about that as well.

Part of what kept me from going entirely negative on SAFe was Al Shalloway's contributions. His Agile values and approaches are quite good. That meant that his sections of the lectures, and his answers about what he'd do in real cases, shifted the balance from what I believe we'd have gotten from the other instructor alone.

SAFe contains many good elements, and if an organization actually did what it said, they would likely prosper and move more and more in a direction I consider to be "Agile". I think an organization taking up SAFe will receive some very valuable advice and will likely improve. They are, however, in grave danger of never really making it to Agile as I understand it.

Still, there are some things in SAFe that might well generate more improvement than Scrum alone. That's because Scrum chooses not to include elements that may be important to many projects, even to all projects. Scrum has chosen the path of being a simple but difficult framework. SAFe tries to provide many more answers. That can help. It can also be a serious problem.

The Good: Things to like about SAFe:

I'll talk here about what I like about SAFe, with comments regarding what "Scrum says" on those same topics. Even though I do like what's here, I'm not saying that "Scrum should say" things like this. I do think that Scrum teachers and proponents should say them, and that organizations using Scrum should know about these things and apply them.

Clear Definition of Levels

SAFe distinguishes three levels, portfolio, program, and team. Activities at this level are different, and SAFe describes fairly well how to hook them together.

We might prefer self-organization, but the SAFe breakdown isn't bad and parts of it are good. The advice may not be Pure Agile but it's Pretty Darn Good.

Scrum and Agile really don't offer much help at these levels, and large organizations have these levels or equivalents. Without guidance these levels are likely to be inefficient and to militate against Agile ideas. SAFe's guidance is better than no guidance at all.

Focus on Lean

SAFe explicitly incorporates ideas from Lean. It includes some excellent material on Lean Leadership, which provides for developing people, empowering them, and getting things out of their way.

SAFe also calls directly for Value Stream Analysis, which is almost always a very powerful way to remove waste from the organization.

Scrum and Agile do not explicitly include these ideas. In fact some Scrum proponents have explicitly denounced them, in the belief that people will figure things out. People can benefit from help in figuring things out.

Portfolio Level

SAFe gives explicit advice on managing the portfolio, in particular in limiting WIP at the top level. It offers an approach to communicating about what needs to be done in terms of "Themes", leading to "Business Epics" and "Architectural Epics".

Scrum and Agile do not offer much help at these levels. Story cards in a lunch box or on a wall can actually work at the highest level, but they're not likely to be accepted even if they would. The C- and VP- and Director-levels want something more expensive and fancy, all too often.

Program Level

Large organizations often have many products that fit together into a "Program". Microsoft Office is a Program in SAFe terms, with products like Word and Excel inside it. SAFe provides a way for Product Management to work with Product Owners to work out what is to be done and get it into a Release Plan.

Scrum and Agile answers to how to do this often come down to "figure it out". SAFe provides a structure in which to figure it out. It's not the best that can be found, but it's not bad.

Develop on Cadence, Deliver on Demand

This rather nice concept captures the idea of building software in iterations, and shipping it when business conditions call for it. From the viewpoint of selling SAFe, it subtly suggests that you, the big powerful business person, can ship whenever you want to while the little programmers code away in their happy little two-week Iterations.

But in fact that's what you want to do. Build software that's ready to ship and ship it when you're ready. Some of the mechanism for doing this was not made clear to me. One big idea is the Release Train.

Release Train

SAFe develops "Potentially Shippable Increments (PSIs)" using a five-iteration "release train". (Unfortunately, they use the PSI term differently from Scrum, where the idea is to produce a PSI every Sprint.)

The idea in SAFe is that multiple teams are on the same train and develop Stories (at the Team Level) which roll up into Features (at the Program Level) over five iterations. The last of these five is a "Hardening, Innovation and Planning" Sprint.

SAFe explicitly says "Hardening if necessary". Realistically it often is. Idealistically I'd like to push against it. And SAFe does push against hardening: The SAFe literature is pretty explicit in looking at three kinds of activity in Hardening:

• Stuff you must do and can probably only do in hardening
• Stuff you should be doing earlier but have to do in hardening for now
• Stuff you absolutely should have done earlier and for which you're using the hardening sprint as a "waterfall crutch".

This is pretty solid advice. Generally, if you read the words in SAFe, there's a lot of pretty solid advice. I am concerned whether the advice will be found, read, and followed. Lots of the good bits are hidden inside, like very rare chocolate chips in a cookie.

Team Level

SAFe uses a version of Scrum at the team level, which they call ScrumXP because it includes specific "Code Quality Practices" adopted from XP. We'll visit the quality practices in a moment.

SAFe has some important differences from pure Scrum at the team level.

First, SAFe describes the development team as being made up of "devs and testers", rather than as fully cross-functional. It's not that they say it shouldn't be cross-functional, they just don't address it. Note, in an attempt at fairness, that their assumptions include a lot of business analysis up at the Program Level/ If you do that, there might be be less need for that kind of skill at the Team Level. Note also, however, that this reduces the opportunity for creativity at that level. This is not all good.

In fairness, SAFe's planning isn't all top down. The Program Level sends down big Features to the Teams, and the Teams parse these into smaller Stories, estimate them, and report back how much they can accomplish. There's a bit more than lip service given to the idea that the Teams still decide how much can be accomplished. It's still top-down and easy to misuse.

In our class, there was a great deal of pressure from our role-playing Product Owners, and from the Product Managers and the exceptionally forceful Release Train Engineer. Teams were pushed hard to bend over and accept the amount of work that "had to be done".

It was also the case, in our class, that the work handed down from the Program Level was incredibly poorly allocated across teams, almost guaranteeing serious dependencies and an inferior architecture. This despite the existence of an architect who was doing his best to come up with something sensible. In my experience, parsing work at the top of an organization almost inevitably leads to mis-allocation across teams, and always reduces the chance for creative solutions.

The story from the SAFe instructors was that this mis-allocation simulated the kind of give and take, and the freedom that the Teams have to really sort out a good solution. With 20 people in the class, it was chaotic. With 100 or so, it would have been ... even more interesting.

Nonetheless, when you have committed to using a large group of developers, you do need to sort these matters out somehow. The chaos and top-down behavior we encountered should be compared to another real approach, not to an idealistic notion that you really should work with a smaller team or allow self organization. SAFe offers an answer: I'd like to see it compared with other answers.

Code Quality Practices

SAFe has Code Quality as one of only four core values. It explicitly recommends these practices, crediting XP for most of them:

• Agile Architecture
• Continuous Integration
• Test-First
• Refactoring
• Pair Work
• Collective Ownership

There's little doubt that these practices contribute strongly to the ability to build solid software over more than the short term. I am delighted to see a method come right out and recommend them. It's kind of unfortunate that it had to be SAFe to do it. I'm looking at you, Scrum.

The Bad: Things not to like about SAFe:

SAFe's Fundamental Assumption

SAFe's fundamental assumption is "You're large, therefore you need to 'scale', therefore organize like this and impose this approach." That turns out to be wrong.

First of all, you're probably not large, you're probably kind of biggish. If you're a Fortune 1000 company full of programmers, well, maybe. If you only have a few thousand programmers, probably not.

Second, most of your projects are not really very large. Most of them can be handled by a single Agile team, or a few Agile feature teams. All of these can be handled in the standard Scrum or Agile fashion, with an empowered Product Owner to guide them and a few joint meetings to keep coordinated.

Third, most of your teams may not really be Agile at all. Until all your individual teams can really do what Agile teams do, using all those XP practices that SAFe does wisely recommend, it's not time to start directing them with a large process. It's time to get them trained and experienced in doing software right. After they can do it, you'll find that most of them don't need all that top down large process after all. The large process is trying to compensate for the problem rather than fix it.

Fourth, most week to week and month to month planning doesn't require a large-scale top-down coordination effort. Yes, your Product Owners need to work actively with their colleagues, and with your Product Managers or other visionaries. But they're perfectly competent to work these things out without imposing a big process on them.

Finally, many of your multi-team projects can turn into single team projects once you get your teams competent in really doing Agile Software Development. You don't need to build a big process because you don't have a big problem any more.

SAFe assumes that you need a big "solution" and then provides it. More than likely you don't need a big solution. You might need extra coordination and direction in a few areas. Get the teams all cross-functional and Agile, divide up the work accordingly, and then see what's next.

SAFe Isn't Really Safe

SAFe gives what may be sincere lip service to good Agile and Lean practice. These are things your organization should know, understand, and do. No doubt about that.

However, SAFe wraps those ideas in a package that is designed -- intentionally in my opinion -- to appeal to today's managers and executives who do not understand Agile, but who know they have a problem to which Agile may be the solution.

If everyone in the organization were to read the fine print in SAFe, then the organization might very slowly evolve to the level of effectiveness that real Agile provides. That's not going to happen. Managers and executives are too busy to read the fine print. They are too busy doing their job to study how to do their job. They will too easily fall into old patterns of management behavior, and when they do, SAFe will be installed in a fashion that won't just fail to support Agile, but that will suppress it.

Bottom Line

There is much to like in SAFe. I can't tell how cynically some of its advice is offered, but whether it is cynical or not, the nature of the target market is such as to work to reduce SAFe's effectiveness.

SAFe will be successful in the market. People will benefit. They just won't benefit nearly as much as they might if they set out to do things in a fashion that truly supports Agile Values and Principles.

SAFe is good. It's just not good enough. It provides some benefit, but endangers an organization's progress toward really high functioning. As someone who has been in the Agile movement since before it started, I do not like it. It's fast food. You can do better.