Is SAFe safe?

I recently made a passing comment in one of my videos about SAFe, it was a bit of a cheap-shot on my part if I am honest and I got picked-up on it, appropriately, by a viewer.

It is too easy to take cheap-shots at things, so here is my slightly more reasoned explantation of why I am not a fan of SAFe.

My Experience of SAFe

My direct experience of SAFe is limited, but I have worked with several clients that have adopted it as their corporate agile strategy.

The results that I have seen have been in-line with the predictions that I would have made based on my reading of the SAFe approach, and so has tended to reinforce my opinions, and no-doubt, prejudices.

Not Obviously Wrong But…

I have said for years, since I first became aware of SAFe’s existence, that if I look at any small piece of it, while it looks too bureaucratic to me, it is mostly not wrong.

Many people dislike the commercial stuff around SAFe, but for good or ill we live in a capitalist world, so I have no objection to that.

My reticence, and experience, is that I have never seen it work successfully, and I don’t know anyone, anyone that has seen a real successful agile project at least, that claims to.

This is a limited sample of course, and depends on how we measure success, but the orgs that I have seen try SAFe look indistinguishable from the orgs that pay lip-service to Scrum to me. In both cases, they look like waterfall orgs to me.

How Orgs Change

The problem is less a problem of SAFe itself, but more a problem of my perception of how people, and in particular, organisations, adopt change. On the whole they try really hard not to adopt any change at all!

Organisational and cultural inertia is a real problem, and a real barrier to progress. This means that these orgs will read SAFe and then try to force-fit it into their pre-existing mental model. I think that SAFe’s problem is that it looks too much like what went before, therefore fits too neatly into the wrong mental models.

Revenge of the Mutant Methodologies

When I first saw SAFe it reminded me, very strongly, of a previous attempt, RUP (Rational Unified Process). If you looked at RUP from the perspective of small iterative, what these days we’d call, “agile”, teams then RUP made good sense. I was involved in several successful projects based on a very light-weight adoption of RUP. I think that is probably what its creators intended.

The problem was that almost no-one in industry saw it that way. RUP was designed as a kind of self-build-kit for development process, attempting to point (for me strongly) at a more iterative, collaborative (we’d now say “agile”) approach.

What nearly everyone read though was “Ok, so we have to do all this extra paper-work and bureaucracy to do”. One of the first steps in RUP was “select the important artifacts that you will use”, what nearly everyone did was “pick all of the artifacts that RUP ever mentions”. In practice it was often the most bureaucratic version of waterfall that you have ever seen.

The Release Train Plateau

SAFe looks like that to me. There are things that I think are wrong, more complex and wrong, in SAFe.

I dislike the idea of Release Trains, and think that they are an anti-Continuous Integration step, in my experience they often move teams further from where they need to be rather than closer. In some ways you can see Release Trains as a step along the way to Continuous Delivery, in practice they seem to me to, much more commonly, represent a plateau that halts team’s progress towards a more effective flow-based approach.

CD Works Better!

In one of my more successful consulting projects I worked with a moderately large team in a very big organisation, that had nominally adopted SAFe. There were several hundred people in the team that I was working with.

Inevitably, I guided them using Continuous Delivery principles. Starting points were “work so that your SW is always releasable” and “optimise for speed of feedback”. This team outperformed, based on internal company metrics, every other team in the org and now acts as an example and coach for others in the org.

It is Hard to Change

I don’t think SAFe is evil, I can imagine some circumstances, with the right combination of people, where it would work. The trouble is that you can say that about anything, even waterfall sometimes works by accident, if you have people in-place that can navigate it.

I think that SAFe is misguided.

It is incredibly difficult to make changes in big orgs, but I don’t see any evidence that SAFe helps on that journey.

Having said all of that, my experience is limited, please do let me know in the comments where I am wrong in this?

———————

You can watch me explain more of my thoughts over on my Continuous Delivery YouTube Channel

This entry was posted in Agile Development, Culture, Effective Practices and tagged , , , . Bookmark the permalink.

7 Responses to Is SAFe safe?

  1. as I often joke:
    “do you know that there is a new SAFe version out and that you have to update all your costly certifications immediately?”

    it is call User Needed Scaled Agile Framework ….

    and the accronym is …eh… UNSAFe!

    • Phil says:

      Hi Stefan,

      I am interested to know where you got this information from.

      I work for SAI and know that when we upgraded from 4.6 to 5 (the picture above is out of date) the upgrade path was free for all certifications and it wasn’t required immediately.

      Just curious thats all.

  2. Gary K Evans says:

    Dave, you are spot-on about both SAFe and RUP. I was heavily into ‘lightweight’ RUP. My very first published paper was a one-page description of ‘RUP for Developers’ and one page was all I needed. I was continually dismayed by orgs that adopted every artifact, every role in RUP and then wondered why the silver bullet did not hit the right target. I am an SPC and my first view of SAFe years ago was, “This is too much like RUP.”

    The foundational point that orgs missed is one that Dean Leffingwell reiterated when I invited him to speak at our Agile Practitioners’ Workgroup when I was working with a major U.S. financial company. He was very straightforward: “SAFe will not be successful if you don’t have your teams working successfully first.” This was a wise admonition, but in my consulting I have seen every pathology in-place as the org tries to ‘be SAFe.” The irony, of course, is that if we actually get the teams operating effectively and efficiently (as in CD) then we really don’t need SAFe.

  3. davef says:

    I don’t think that affects anything that I am talking about, but thanks for letting me know.

  4. Erik Buitenhuis says:

    Nice to compare SAFe and RUP. Both can be used in an agile way, and I have seen them been used as such. And both suffer from the same problems. Where Scrum defines the minimum process, and you need to add stuff to make it work in your specific context, SAFe and RUP take the opposite approach. They are large, complete, try to define a solution for every problem. They include many optional roles, deliverables and meetings. And many organisations, in moving from a traditional way of working, wanting to do it right, implement all those things, making their processes heavy, with lots of bureaucracy and no agility. Decision makers like SAFe because they recognize their organisation in SAFe (enterprise architect, solution architect, product manager, etc…). Still, for these organisations, SAFe is often an improvement compared to their traditional, waterfall approach. Yes there are more agile, more lightweight ways around, but it is a step forward, and isn’t that what agile is about? To keep making steps forward, to keep improving?

  5. An Le says:

    I’m not quite familiar with SAFe nor RUP but from my experience, no framework could work if the one who navigates it is not the team themselves. On a medium/large scale projects, there are just too many things that one or a few individuals could handle. That’s why we need autonomous, self-organizing teams. We need to move forward as a single body. I really like the analogy of the project teams are a human body. Your agility (the ability to coordinate between different parts of your body) will determine what you could do, e.g. walk, run, jump, or dance.

  6. Hi Dave, thanks for the critial but not mindless rant about SAFe that we also often see 🙂 I like that you worked on the CI/CD pipeline of that team and it outperformed. But this is actually something that is also a key aspect of SAFe. The framework says that all teams should have a joint system demo at the end of every iteration and this together with the “team and technical agility” competency describes your point. The system demo is perceived as the main event together with the PI planning. Basically, what I wanted to say is that what you have done actually corresponds perfectly to what SAFe also suggests. 😉

Leave a Reply to Phil Cancel reply

Your email address will not be published. Required fields are marked *