(Originally published by Lv Yi on June 8, 2020)
When a team responsible for “A” (be it a function, component or customer domain) grows too big, we split it into two teams, responsible for the subsets of “A” that are as independent as possible (the left side). Why is it so natural to do this, rather than the alternative - split into two teams, responsible for “A” together (the right side)?
There are a few responses:
I don’t know what to do with the 1st response, and I have explored the 2nd response in the series of Number of backlogs and multi-learning. This article addresses the 3rd response.
The iceberg model is a systems thinking tool. It helps progress our thinking from an obvious event to patterns of behavior, to their supporting structures, and the underlying mental models. The below diagram is from Michael Goodman’s original article that introduced the iceberg model. In other places, mental models may also be illustrated as a separate deeper layer.
For the topic of specialization, we explored mainly the structure, but mental models, such as “people can or can’t learn”, were also implied there.
Now let’s look at the topic of responsibility. Is “clear responsibility is necessary” the mental model here? It is hard to dispute this. Who wants its opposite – “unclear responsibility”? However, when two teams are responsible for “A” together, is the responsibility unclear? Not really. It is not unclear, but shared. What is the opposite of shared responsibility? It is individual responsibility. The response is actually “we want individual responsibility” in disguise. So, the real mental model is “individual responsibility is necessary”.
Why do we want individual responsibility? Because we assume that shared responsibility means no responsibility. When something goes wrong, shared responsibility makes it difficult to find someone accountable, so we don’t know whom to blame or even fire in case of failure. In contrast, individual responsibility makes it more “clear”.
However, the sole focus on the responsible part leads to strong local identity, and eventually to silo mentality. Many people say that they hate silos, but in fact our love for “clear” responsibility helped create them in the first place. Maybe we don’t really hate silos, or do we?
I purposefully make “individual” unclear – be it individual person or individual team. The underlying thinking is the same. We need to improve our mental model from “individual responsibility is necessary” to “shared responsibility could work, and even be better.”
This happens in Scrum adoptions. One-team Scrum breaks down individual responsibility for the individual members, and defines shared responsibility for the team instead. The team takes shared responsibility towards its common goal. While individual responsibility makes it easier to hold someone accountable, it doesn’t make the group a real team working towards a common goal. Individual responsibility creates silos in the group and leads to local optimization.
This happens in LeSS adoptions too. LeSS – aka multi-team Scrum – breaks down individual responsibility for individual teams, and defines shared responsibility for the product instead. Multiple teams take shared responsibility towards their common goal. It has the same logic as one-team Scrum. This should not be surprising since LeSS is Scrum.
The shift in this mental model happens on two levels – one-team (Scrum) and multi-team (LeSS), but they are essentially the same.
Espoused theory is reflected by what we say, while theory-in-use is reflected by what we do. We realize the gap through the discipline of mental models.
When we let the whole team take shared responsibility when adopting Scrum, that is our espoused theory. When we still define clear responsibility for individual members and hold them accountable for their own parts accordingly, we have a different theory-in-use.
When we have already let an individual team take shared responsibility, but failed to take it to the next level, i.e. multiple teams take shared responsibility on one product through shared product backlog and shared product increment, there is still a gap between espoused theory and theory-in-use.
The gap is not necessarily bad. When we realize the gap, we ask ourselves – do we really value the espoused theory? If yes, then the gap represents the tension between the reality and our vision, so as to help create the path of least resistance. If no, then the gap is not real. As there is no commitment to the espoused theory, we will only manipulate the gap but fail to achieve our vision.
RSS feed