Balancing Team Autonomy and Centralized Control
What is a leader on a multi-team Agile project supposed to do when there’s an expectation to make decisions that would bind all teams and for which he or she cannot hope to consider all viewpoints?
I often found myself in this position with generally two types of decisions to make.
The first were technological ones. These were easy because ultimately the work directly impacts a specific group the most. You just find that group, who of course are doing the work and understand the problem best, and just support their decision. It is well known that the people closer to doing the work have better information to make the decision. If you don’t trust them to make technological decisions, you are pretty screwed and should work on that. I was fortunate to have a very talented group of engineers that I fully trusted.
The second type were usually development decisions that did not have clear answers. Coding style, review process, Agile processes, etc. Decisions where everyone is a stakeholder. In these cases, I would always discuss the topic in an open forum, such as the relevant Community of Practice, or even via email. I would then take the decision of the group and make it “official policy.”
It’s important that these discussions not discipline discussions, or leadership discussions; they must be open discussion in a zero-barrier-to-entry forum. It is like early RFCs: if people are interested, they can discuss. If they are not interested, they do not have to take part, but they will have to abide by it. It was also my policy to revisit decisions every few months (maybe 6 for project-wide changes, or 2 for changes scoped to a team or two). This way people would have less fear of change. If something doesn’t work out, we can always go back to how it was. Where decisions were made on a discipline level, or the expectation to revisit these types of decisions wasn’t made clear, I think development decisions did not work well.
I feel this style of decision making walked a good balance between:
- Actually making decisions. It’s too easy for Agile project leadership to hide behind “team autonomy” as an excuse for not making decisions (technological, developmental, or otherwise) or being held accountable.
- Respecting team autonomy. Ideas could be piloted on not-unwilling teams with the understanding that things could go back to how they were if they don’t like it.
- Consistency between teams. We could force changes across teams, creating consistency where beneficial, without feeling so bad, because everyone who was interested could have a say.
This is what I aspired to, at least. And when I followed it, decisions tended to be positive. When I lost sight of it (or before I gained clear sight of it), my decisions were pretty average.
