The best architectures, requirements, and designs emerge from self-organizing teams.
Control and autonomy
One of the latest thought I read on SAFe was about it not being agile.
And I agree, on many ways SAFe has noting to do with agile, as it has everything to do with control.
The fact that everything is being dumped into SAFe makes it hard to say what can work for you and what won’t.
“When in doubt, put more ingredients in it” doesn’t really work.
Looking at SAFe and saying “it works” it’s like looking at a ready-made soup and saying “it works”: yeah? But why? What’s really inside your soup?
From the look of it, one thing stands very clear: SAFe it’s something built out needs of control.
There are trains involved too, so we are looking for predicability, obviously.
But let’s not shoot on SAFe any longer, and let’s take a look at something supposedly agile like the the Spotify “model”.
I’m not here to tell you why it isn’t a model and shouldn’t be taken any more seriously than SAFe.
There is this interesting matrix Henrik Kniberg drew back in in 2014: make no mistakes, they used the word “alignment” but they could have used the word “authority” as well.
What drives most of the “controlled” part of a decision are:
Let me be clear about this: we can’t eradicate opinions, authority and egos from he workplace.
What we can do is to find ways to limit the damage that opinions, authority and egos have to each other’s autonomy — and, ultimately, to the company’s bottomline.
But how do you change something so radicated as management styles thought?
Everybody wants to me agile, but nobody wants to give up on their opinions, ego and authority at work.
You start with a reflection about what are we doing in a controlled way and what are we doing in an autonomous way, and then you understand and explore where you could build a middle ground.
A reflection about “controlled autonomy”
Whenever I face a company or a team that has to deal with the shortcomings of too much control and not enough autonomy, I usually invite them to do this Integrated~Autonomy exercise.
It revolves around three basic questions:
- “How is it that we can be more integrated and more autonomous at the same time?”
- “Where is there tension between our desire to standardize and the request for more customizing or autonomy?”
- “What is the rationale for standardizing? What is the rationale for customizing?”
This exercise sparks a deep reflection about “How we do things around here”, which is something we always take for granted and leave to the implicit knowledge of a company’s inner workings.
Before taking for granted that “more autonomy” is always good, it’s important to face that:
- Aspects that might seem overly controlling might be really needed
- Full autonomy on certain actions or decision might be really too risky
It’s obviously a balancing act. It’s easy to lose yourself in the land of “If I can do it, and you can do it, nobody does it”. As there is analysis paralysis, there can be autonomy paralysis too.
Yeah, Spotify, because despite everything wrong about calling it a “model”, their original principles about the engineering culture are stil crystal clear and to the point. Especially the alignment/autonomy matrix. So take another close look at Spotify Engineering Culture #1 and #2.
As any (former) programmer, I love some good old “defaults”. Build with people a few simple rules to follow, autonomy will arise.
Chersterton’s Fence: before removing a constraint, always ask yourself why the constraint was put into place. Removing it might create unwanted second- or third-order effects.
See you next week
Episode 2 will be about power and vulnerability.
Out on Monday, May 31st.
Just a reminder: you subscribed to this newsletter because you probably read or wanted to read something interesting about Agile a few months ago.
This newsletters drops in “seasons”, like a TV show, so I will be publishing constantly for a short while — seven weeks in a row — and then disappear for a few months.
My name is Davide and I’m an organizational consultant who’s sometimes called an “Agile coach” (beware the capital “A”, beware the “coach”).
We can have a quick chat about if and how I can help you.