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
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!
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.
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.
I don’t think that affects anything that I am talking about, but thanks for letting me know.
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?
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.
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. 😉
Richard – ironic. You’re right SAFe suggests what Dave suggests. Even funnier that Dave like many others who has spent years helping clients – few companies that implement in SAFe do it well.
CI/CD is not “joint system demo at the end of every iteration”. If you have an activity spike in fixed and regular iterations it is by definition discrete. Indeed as pointed out in the article a “Release Train” is totally unnecessary in a continuously evolving system.
“at the end of every iteration” continuous exactly the same way a snail continuously moves forward.
CI/CD is at the heart of SAFe. Release trains aim to create a common cadence for teams to have regular system demos. All detailed information is available for free at https://www.scaledagileframework.com/. There you will find all of your favourite concepts: release on demand, set based design, inspect&adapt, systems thinking, organising around value streams, value stream mapping.
Still an organisation needs to be ready for it. My customer has started with Essential SAFe recently. We have had interesting conversations with the enterprise architects. Essential SAFe in this case implies that the organisation and the project funding will not change (as opposed to with Full SAFe). Future will tell if the organisation is only paying lip-service to Agile and will burden the projects with more paperwork in order to fit the budgeting rules.
The process, politics and need for Senior people to feel safe have to be in sync with the “best” way to develop/create software and systems. I believe this is more of issue in the democratic type of systems and attitudes that the West (especially USA, Canada, UK, Western Europe) has. Culture affects a lot how much freedom a Junior or Mid Career or even a Senior technical person expects from the organization to deliver while feel engaged and happy. On the other hand, in order to develop good Systems, you also need wisdom that “well meaning” experienced Senior people bring to the table. Their advice might be part time but the guidance is well worth to incorporate their feedback in the process. If SAFE or PMI or PMO’s home grown process or RUP allows for enough freedom while delivering “Working system” then that process is fine. You will look back and say, that was ok.
In any decent sized System, there has to be somebody who can see far into the future (5 to 10 year – aka Solution/Enterprise Architect) and somebody who can manage the Money (Dev/Project Manager or Scrum Master) and guide people at Sprint level to not spend loads of dollars delivering simple functionality. There as to be somebody who has to save organization from getting overbilled by few over charging consultants (I am a consultant but I have seen how something can be overblown sometimes, many times)
In conclusion, as long as there is flexibility provided to Individual Team Member to deliver their best while keeping good level of Happiness and successful (met most of the goals of the project) SAFE or any other process might be ok.
I started doing Agile in 2003. That might not make me an expert, but it does mean I’ve seen a lot. I should also mention (confess?) that I’m a “SAFe 5 Agile Software Engineer” for no other reason that an employer required a SAFe cert and was willing to pay for it.
What your post gets exactly right is the seductiveness of SAFe to large corporations. Many large companies are realizing that “digital transformation” means they need to become, at least in part, software development companies. They’ve heard about Agile and find its buzzwords appealing, which triggers a knee-jerk reaction: “We have to be Agile!”
When they encounter SAFe, they predictably decide since they are a big company, and SAFe is for “big Agile,” then they should adopt SAFe — despite their complete lack of experience with software development, Agile or otherwise. What they fail to do is begin by starting small, then Scaling Agile culture and practices. SAFe is adopted to great fanfare and the declaration “We are now Agile!”
Of course, nothing could be further from the truth. My metric and advice is this: count the number of “standard operating procedures,” policies, guides, etc. which purport to govern or control their “Agile” process. If the number >1 and does not include the Agile Manifesto, run. If the organization seems to believe that Agile can be “proceduralized” at all, run faster.
> If the organization seems to believe that Agile can be “proceduralized” at all, run faster.
I completely agree with this one. I once worked in a company with hundreds SOPs and SWIs. For the “agile transition” we started to write agile documents (also to be compliant). This was a complete disaster. What we should have done instead is not adding more processes, but removing some and making the others more lean and structured to really focus on input and output and not one hundred roles and steps.
SAFe for me feels like all the ideas for agile have been swept into a big bucket and some fairly rudimentary “instructions for use” provided. This is backed up with a two day course where you can get a “practitioner certificate”. To learn all of the techniques well enough would need years of experience and reading (at least they provide references). The problem is that in large corporations, people tend to go on these courses and then become self declared experts. They then proceed to wrap agile nomenclature around existing processes, add in some “release train engineers” who tell everyone what to do and hold 6 conference calls a week. Everyone then stands around scratching their heads wondering why nothing as changed.
IMHO, SAFe seeks to find a solution to massive team sizes when the _real_ solution should be to not have massive team sizes. Service Oriented Architecture came to be to solve this exact problem (to the casual reader this term is much like Agile, CI, and DevOps in that it’s been manipulated to mean things that it isn’t).
If teams all behave in such a way that their services are externalizable, then no inter-communication and coordination is ever required across huge swaths of the company requiring a framework such as SAFe.
Pingback: SAFe ist nur eine mittelgute Idee – digitalien.org — Stefan Knecht