We love individual responsibility more than we would admit
Once 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" (the left side). Why is it so natural to do this, rather than the alternative - we split it into two teams, responsible for "A" together (the right side)?
There are a few responses.
- we don't know why we do this, with the variants of "we have been doing this", "others are doing this", "is there any alternative", and etc.
- we want specialization by letting each team focus on one subset.
- we want clear responsibility by letting each team work on one subset.
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 is for the 3rd response.
Mental model
The iceberg model is a systems thinking tool. It helps progress our thinking from the obvious event to the patterns of behavior, to its supporting structures, and its 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 look at the topic of responsibility, is the mental model here that "clear responsibility is necessary"? It is hard to dispute about 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 that "we want individual responsibility" in disguise. The mental model is really that "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 is difficult to find someone accountable, so as to blame or even fire him. By contrast, individual responsibility makes it more "clear".
However, the sole focus on its responsible part leads to strong local identity, and eventually silo mentality. Many people say that they hate silo, but the love for "clear" responsibility in fact helped create it in the first place. Maybe we don't really hate silo, do we?
From Individual responsibility to Shared responsibility
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 better."
This happens in Scrum adoption. One-team Scrum breaks down individual responsibility on the individual members, and defines shared responsibility on 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 adoption too. LeSS - aka multi-team Scrum - breaks down individual responsibility on the individual teams, and defines shared responsibility on 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, as LeSS is Scrum.
The shift in this mental model happens at two levels - one-team (Scrum) and multi-team (LeSS), but they are essentially the same shift.
Espoused theory vs. Theory-in-use
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 in 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 individual team take shared responsibility, but fail to take it into 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 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.
