Like so many famous quotations there’s a dispute about who said that they rob banks because “That’s where the money is.”
But this is pretty much the only reason anybody has put “Agile” and “Scale” in the same sentence. In our heart of hearts, Agile practitioners knew that we didn’t know how to scale Agile and we knew that SAFE, DAD, LeSS and - most embarrassingly of all - Nexus weren’t going to cut it. But big businesses with money wanted to pay us to (try) do it. Ironically perhaps, lot of those big businesses were banks.
Because everybody likes money - as Jerry Seinfeld says “that’s what distinguishes us from the animals” - I’ve also had a go at pretending to know how Agile can Scale. But the “Emperor’s new clothes” aspect of the whole endeavour defeated me.
The cognitive dissonance playing out on the face of the trainer on the SAFE practitioner course that I attended (I didn’t sit the exam) was terrifying to behold and was one of the main things that put me off.
So, to be honest (and I think that’s a big reason why I’m involved in this Agile endeavour) I’ve avoided the scale questions and concentrated on getting on with the bits of Agile that work: delivering software using Scrum teams and XP practices (why does that sound old fashioned?).
Then I stumbled on liberating structures at a Lean coffee morning. I read the book and attended the course. There was no cognitive dissonance in evidence.
The central argument of “Liberating Structures” is that most business is managed using “Five main conventional micro structures.” These are:
But I think actually in software development there are at least two other “standard structures” - at the mega level:
I Agile we use some different micro structures:
And parallel to the deadline and the Gantt chart we use several “mega level” strategies:
When we’ve been challenged to come up with a description of how Agile might run at scale, it’s these meetings that we’ve tried to use to solve the problems at every scale.
For example, Scrums work (reasonably well) as a state-sharing and problem-solving tool. But the same idea doesn’t work so well at Scrum of Scrums level. It just doesn’t.
Similarly a backlog of backlogs sounds great but without a lot of adhoc manipulation it just degenerates into command and control. Comparing velocities between teams is almost the archetypal Agile anti-pattern and “coordination” of incremental deliveries starts to look a lot like release to a deadline.
But what if some other meeting, at some other frequency, did work at that level? What if we have some candidates that we can suggest to start with but understand that these structures might be different for different organisations? (from the canon of liberating structures I think these would be “What? So what? Now what?” and “What I need from you”).
I’ve got to admit I’m a tiny bit excited now.
I’ve been doing this a long time. I’m good at helping teams deliver software using Agile. I’m starting to think I might genuinely be able to help organisations do the same thing at a larger scale. If you want help with that, get in touch. Mark Stringer 07803 257 982. Mark.Stringer@mumbly.co.uk.