Reviews of SAFe based on knowledge rather than supposition are increasingly supportive that it has positive intentions, and useful practises.

While there are still genuinely held concerns, some of these are based on risks rather than certainties, and assert assumptions which may not be true. Through open dialogue rather than doctrinal rhetoric, we can come to shared understandings of the benefits, costs and risks involved, and move forward in uncovering better ways of developing software.

In the last week, there have been two thoughtful reviews of SAFe, as expressed via SAFe SPC Training.

The words of Toyota Chairman Fujio Cho, Go see, ask why, show respect are now famous as basic lean principles.

John Shook

The articles that came out of this were thoughtful, insightful, and based on actual knowledge, rather than supposition and knee-jerk reaction to everything from (at best) conference presentations to (at worst) assumptions based on hearsay, or even active spoiling. They deserve huge respect, not just because of the authors (I never was much of an Appeal to Authority person but no-one can argue that Ron’s experience and history of thinking and communicating doesn’t command respect), but because they have taken the time and effort and not a small amount of money to find out for themselves what SAFe is actually about via attending SPC Training.

Given that the articles were so strong, it’s been disappointing to see tweets linking to them with simplistic summaries, in some cases cherry picking quotes and apparently seeking to use the articles as a way of furthering a rock-throwing agenda.

Here’s an example (I saw quite a few along these lines) of a fairly clear attempt to hijack for agenda purposes:

In private life, I’ve been active in campaigns for political change long enough to recognise a “extract a risk from a balanced commentary, express it as a racing certainty and claim it as a summary” FUD straw man at a hundred paces. That’s not to say that all tweet summaries have been this poor (or, depending on your disposition, less like something I’d agree with. I’m perfectly open to seeing my own biases…)


That a single article could spark two such differing summaries made me want to do it justice and address some specific areas where I think Ron hasn’t seen quite seen the wood for the trees. Note that this is entirely non-judgemental of Ron, and of the training session in question (which was run by people I respect), as I wasn’t there. It’s also entirely possible that I’ve misunderstood the article. To repeat for clarity: In no sense do I think that Ron is A Bad Person, A Stupid Person, or a Person With Agenda. Nor that the training he attended was Bad Training. I’m simply trying to extend the spirit of enquiry by contributing my understanding which is at variance with what I perceive Ron to be saying.

Finally, I really do need to point out that I’m not speaking for SAFe in any official capacity. I am certified as an SPC, but I’m not representing anything but my own knowledge, experience and understanding of what SAFe is and should be.

Right, caveats out of the way.

Ron Jeffries’ Review

SAFe – Good But Not Good Enough

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.

I think this is the key to it. If I had heard that assumption asserted as solid fact, I’d have run a mile too. What I heard in my SPC class (and wrote about at the time) — and certainly chimes with my own experience of many of exactly this kind of organisation — is a little more nuanced, and goes something like:

Given an organisation that is large, and conservative
    And a need to deliver things bigger than a
        single Agile team could handle in a
        business-acceptable timescale,
    And longer product development pipelines (including 
    	governance) than can be addressed by putting a few 
    	empowered business people in the same room 
    	as the technical team,
    And a history of resistance to existing Agile process
    	and organisational models (eg Scrum)
    When I attempt to increase agility
    Then I should attempt practises that have been more 
    	successful in organisations with similar 

(Chris Matts has had the beautiful idea of writing that in a format that may be familiar).

Being a large organisation isn’t enough on its own to warrant most of SAFe’s practises. And having a product that can be easily worked on by a single team would discount most of it from the get go. So this

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.

is spot on, but goes to the question Where SAFe?. If a single team, fine. If you have multiple teams, you are going go need to co-ordinate, and that’s 90% of SAFe’s Programme Level. The more teams, the more structured this will need to be. And if you need to co-ordinate with external teams, not all of whom are within the Agile culture bubble, or your Sphere of Influence, and you are following a wider product strategy, then what?

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.

That idea is very much built into SAFe. The overall usage model is “start from here. Then evolve to what you need” and as it explicitly directs to fully adopt the Agile Manifesto and Principles, then that value of Simplicity should be there and acted on. If you evolve out of needing the process scaffolding, dismantle it. Use just enough and no 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.

Again, the nuanced view of this is: if other approaches have failed, and you find you need a bigger solution, here are some ideas. If you don’t, great! But some people actually do, and telling them that they don’t when you don’t know their circumstances is perhaps why other approaches haven’t succeeded. You can only ever answer the question of “should you?” in context.

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.

When the training for all levels has opens with a big section on the significance of Agile and Lean. When the training to organisational leaders goes through the Agile Manifesto and Principles line by line. When the leadership principles so explicitly say “Adopt the Agile Manifesto fully” and preface it with a cautionary Deming quote saying “You have to really understand this, not just the benefits”. When there is a huge emphasis on changing management approaches to one that enables self-organisation (remember the rugby videos?). When the exercises time and time again focus on “empower the team to tell you how and how much”? I really don’t think you can suggest that the framework is trying to smuggle Agile in by the back door by misdirection.

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.

Absolutely it does. This is a positive point. It is why SAFe stands a better chance of being adopted and having organisational wide transformative effects. It talks the language of the audience. You are not that audience. You get this already. But by talking about the problem that the audience has, and responding to the help that it is asking for (remember: you cannot push help on anyone). To be adopted, Agile and Lean need to be sold. But like the most effective sales pitches, this works in part explicitly by challenging executive assumptions and offering insights that hadn’t previously been considered. Absolutely this is Agile and Lean by the front door, as a solution to problems that executives acknowledge they have. And with a clear message of If you want the benefits, here’s what you need to do to secure them.

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.

As I noted up above, there is certainly a risk of this. And if we leave SAFe only to those who don’t understand the Agile & Lean underpinnings, that risk is stronger. But that’s true for all change. I’ve seen traditional Scrum and XP initiatives fail for exactly the same reasons. Does this mean the method is lacking? No.

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.

Yes, there’s an icon on The Big Picture that says “Developers and Testers”. However, it also says that POs are in the team, and that at a really detailed level, much of this work is BA territory. In the learning materials (slides 8/9 of the Team module) it teaches that Agile teams work across functional silos, illustrating specifically Product Mgt, Architecture, Development, Test & QA

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.

Some at each level. Each organisation will find their own balance point, however.

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”.

Yeah, that’s genuinely not good. It’s not in the training guidance, and while you might do it with a team you knew very well to encourage pushback (and experienced Agile Change Agents are not shy at coming forward on this!), you wouldn’t with a class of strangers.

Bottom Line

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.

Leaving aside the question (addressed above) whether SAFe truly supports Agile Values and Principles, I think there’s a Curse of Knowledge question here. If you’ve been working for a long time with knowledge of how things work really well, it’s often hard to remember what it’s like not to know. And how frightening it can be to let go of old practises that have worked well enough so far.

And if you cannot be wise, pretend to be someone who is wise, and then just behave like they would.

Neil Gaiman, Make Good Art

Remember our premise: SAFe’s context is in organisations that have been unable to adopt fine dining. Who are currently hungry. Are we really saying that it’s Tête de veau or nothing? I’m a pretty good cook, but the first thing I learned to make was Macaroni Cheese.

Let’s get managers and executives hooked on the benefits of Agile & Lean, and be very clear what needs to change for those benefits to be sustained, including some pretty radical changes in leadership style. And after a while, behaviour will shape attitudes, as it always does. Knowledge will evolve through practise. It may take 3 years, 5 years or longer, but it will go in the right direction over time.

Post Script: There is another review I want to talk about, but I want to get this out first rather than waiting until I’ve written another thousand words on the subject. Always improving the flow by reducing batch size…

1 Recommendation so far
Follow me

Martin Burns

Transformation Consultant at CA Inc (formerly Rally)
Previously: Leader of software delivery portfolios in large scale orgs.
Specialism: Transforming complex delivery organisations to be more Lean/Agile.
Mindset: Continuous Improvement Obsessive
Follow me

Latest posts by Martin Burns (see all)

CC BY-NC-SA 4.0 SAFe: Responding to Ron Jeffries’ Review by Martin Burns is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.