I’ve been watching SAFe™ develop for quite some time, since I was defining Agile Transformation at a UK Retail Bank, and had sketched out something very similar, only to discover that what I was reaching towards was already well elabourated and tested against reality in multiple environments.
This last week, I went through the SAFe Program Consultant training (at my own expense) to understand it more fully, and test my assumptions and thoughts against it. I’m now much more confident in stating what I’d thought all along:
SAFe provides a set of effective practises that are more effective in enabling Lean|Agile approaches to cross the chasm to adoption in large, complex, risk-averse organisations than most previous alternatives. If you’re arguing that they’re undesirable or not necessary, I respectfully suggest you may not have seen or understood the target context.
I think this is somewhat the wrong question. Better is: Where SAFe?
It’s not targeted at environments traditionally responsive to Lean|Agile methods; it’s clear that there, there’s no contest. We won already. The sheer economic case for faster, more frequent, change responsive delivery with high quality is unarguable and proven in real life where it’s possible to either change the organisational model, or at least run a skunk works operation hidden and protected from view.
Where you’ve relatively little to risk that one person is fully accountable for, and the change is achievable without too much disruption, it’s all easy. Get my 6 people in a room? No problem. Get them working together with very limited interference? Sure, we can do that. Produce something that those people can deliver in a straightforward way on a rapid cadence, with little systemic inertia to changing direction? OK, done. We’re there already, stop selling.
But when your system supports tens of thousands of people’s livelihoods, and millions of customers? When a 2 day outage hits national and international news and has government & industry regulators taking A Dim View? When the whole system is a big and hairy ball of spaghetti that breaks unpredictably when you touch it? When you have an existing method that works well enough? Do you think you might be a bit more Risk Averse? And you can argue a strong case for it being A Bad Idea, but outsourcing and offshoring isn’t a trend that’s going away in those organisations.
Now that’s not to say that there is no Lean|Agile work going on in those kinds of organisations, but it’s often seen as a Software Developer Only kind of change, which is the origin of the Water-Scrum-Fall model. If you’re in the middle of that kind of system, you’re at best tolerated, and at worst, find the wider organisation pulling in the direct opposite way you want to go.
Would it not be better to have the system working with you?
What’s my System?
Alternatively (or additionally), consider that adding people to your small team to do something bigger and more complex doesn’t scale; Brookes’ Law absolutely applies, and you start breaking all that great self-organisation and sense of ba. So you add a second team. And a third. And now you have a co-ordination problem. If those teams aren’t on a common cadence – eg if your teams have a mix of 2, 3 and 4 week sprints – you’re waiting a long time until they co-incide to get a system level demo or delivery. 12 weeks in that case.
As good Lean thinkers we know that optimising system components has very bad implications for systemic level performance. When you’re co-ordinating N teams to deliver a common system or in a common value stream, what’s your system? The entire group of N teams. How do we get the system optimised and sprinting? Is that going to take a bit of top down alignment and imposition? As N increases, the chances are that it will.
What you want though is a model that provides just enough systemic structure to allow
N*(7 +/-2) people to co-ordinatedly deliver a common vision, while enabling all the good team level behaviours and practises to continue almost untouched.
This is very like Shearing Layers in physical architecture. Done right, inner layers can support rapid rates of change without impacting outer, slower layers. However, outer layers provide a context and set of constraints to inner change, and a limited set of services pierce through and tie the whole edifice together.
So in SAFe, the system is the Programme level, which works as a fractal layer above N teams. And it has a similar, slower, shape to an Agile team, delivering Features into PSIs as Programme level equivalents to Stories & Sprints, incrementally & iteratively realised through stories delivered by teams working entirely as they always have except where needed to co-ordinate into the larger entity.
Is SAFe The New RUP? Is it overloaded? Is it an imposed straight jacket?
Yes, of course it has more in it than Scrum. Or XP. Because it adopts both of those at the team level. But it’s not RUP (then again, the use context is conservative enterprises who would otherwise be doing Very Big Waterfall, and RUP would be an improvement). And unlike Scrum, you won’t find any caustic blog posts or articles from Dean Leffingwell telling you that you’re doing SAFebut. It’s a 100% pragmatic starting point of a set of practises known to be effective (or at least be more effective than either waterfall or unadulterated Scrum) in enterprise contexts, and says tailor it how you need.
Either way, what constitutes glacial for a startup is lightning fast for most enterprises. Planning only 2-3 weeks ahead seems like dangerous cowboy territory there. Allowing iteratively detailed planning that commits to most outputs quarter by quarter (and still gives some capacity to be more opportunistic than that) and actually delivers even to a working demo in that timeframe is absolutely radical when the alternative is having just about put together a bought into plan and a few high level design docs.
“We Shouldn’t Be Scaling Agile”
This is like those methods that claim
where what is really happening is that the method is defined in such a way as to exclude the use case requiring consideration of
$foo is Orthoganal to the Method
$foo. Not needing to scale is a Special Case. If you have it, great, and enjoy it. But you can only do so much with 7 +/-2 people in one room with a genuine onsite customer, and most of that involves a green field or beautifully clean & well tended architecture.
But as discussed above, SAFe is structured as shearing layer, such that from a team perspective, 90% of what you do isn’t scaled, with the primary scaling factors being related to co-ordination. From a programme governance perspective, the model abstracts away enough detail that an overall PO doesn’t get lost in the detail and can ensure that the overall system hangs together. It’s simply a systems wide view of the same effective practises. When your organisation has hundreds of teams – even when they’re self-organising & self-managing – there’s not a lot of choice to avoid being overwhelmed by the volume of data required for effective governance.
Lean|Agile methods and practitioners are rightly famed for being reality based and empirical, working with how things are rather than how we’d like them to be. Large, complex, risk-averse organisations exhibit a wide range of behaviours, some of which are far from ideal. But they’re not changing any time soon. Large complex risk-averse organisations aren’t buying small team Agile at the rate of the rest of the world.
So let’s stop with the rhetoric of
can’t that sound to me like faith-based arguments and either accept that better is better, or simply declare that these organisations should be entirely abandoned, and for them, waterfall really is best.
Me? I’m not prepared to give up on them just yet.2 Recommendations so far