For an array of reasons, I’ve decided to become familiar with SAFe (the Scalable Agile Framework) and it’s proving an interesting education. The underlying model is not bad, and in fact it has one or two practices I wish I had known about earlier. My favorite? If you have multiple teams working on stuff, collect sprints into “increments” – buckets of 5 sprints – and have high level planning around that. Fun extra caveat – you only plan on 4 working sprints. The 5th sprint is nominally for creativity and exploration, and I love that idea, but the fact that it could also be used for hardening or deployment is a nice bit of flexibility.
Cynically, yes, it’s just a different wrapper around quarterly planning, but I admit I like the idea of models rolling up which is sort of the point of things like SAFe and Scrum@Scale.
Downside? I could not tell you why, but the diagrams I’ve run into as I learn SAFe are consistently horrible. I don’t think it’s necessary intrinsic to the framework, but the keystone image you see when you first go to find out about SAFe looks like this:
And I think that sort of establishes a tone of erring on the side of comprehensiveness over clarity. That’s not necessarily a bad thing, but it was definitely at odds with my expectation of something in the lean & agile space. That might just be on me, though.
Never Not Learning 
We’ve found that SAFe seems to steer organisations away from small, frequent releases – https://www.thoughtworks.com/radar/techniques/safe . I’d be interested to hear your experiences, though.
That feels like it would be the inevitable consequence, if only because it seems like there’s an assumption of coordination. Not sure what I think about it though – on one hand, there’s obvious downside in velocity, but on the other hand, I wager it’s still faster than the alternatives.
I think that assumption of coordination is the problem. You should do everything you possibly can to ensure that teams can deliver independently. For small organisations, that’s not too hard. For big organisations, hard, but it’s absolutely necessary. (Ironic that one of the problems of SAFe is that it… doesn’t scale.) Middle sized organisations often coordinate because on the face of it it seems easier, but it actually really hurts them.
Yeah, that’s the paradox that fascinates me. Coordination really can be a problem, especially with more architectural projects, but at the same time that can be a crutch – an excuse to not think cleanly enough about what’s needed to to be able to deliver value.
I suspect the trick is to treat coordination as more of a bug than a feature. That is, if you need to shift away from delivery to coordinate, then that needs to be seen as a problem to avoid repeating. That’s a hard sell, though, since I think most orgs would think of that as “good teamwork”. Requires an org invested in learning.
> the trick is to treat coordination as more of a bug than a feature
You’ve hit the nail on the head here. How fatally does that undermine SAFe?
Not fatally, I think , though it definitely reveals where the “Scrumbut” element of it can creep in. It’s not necessarily bad that the methodology have weak spots – that’s inevitable even – but the question becomes what the practices are to address it, and *that* I don’t know yet.
But it also brings up the deeper question of what the *purpose* of SAFe is. At the most cynical interpretation (It’s for leadership to be able to say they’re “Doing Agile” while still keeping as many controls as possible) then this actually *is* a feature. But if the purpose is to enable agile practices to scale up, it’s definitely a tripwire.
As always, Dan North is worth a read.
> My argument isn’t that packaged scaling methods are unhelpful per se, rather that they are neither necessary nor sufficient for successful transformation. They can be anything from a useful starting point to an expensive distraction, but one thing they are not is a solution.
https://dannorth.net/2018/01/26/in-praise-of-swarming/