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)?

individual responsibility.jpg

There are a few responses.

  1. 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.
  2. we want specialization by letting each team focus on one subset.
  3. 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.

Read more



ครูณาส่งหนังสือที่ครูแปล ชื่อ Becoming super natural มาให้ ผมได้ข้อมูลที่ตื่นตาตื่นใจหลายอย่าง หลายอย่างผมก็ยังต้องใช้เวลาค่อย ๆ ทำความเข้าใจไป แต่วันนี้อยากเอาเรื่อง จักระ ทั้ง 8 จุดมาแบ่งปัน จากในหนังสือ ผมได้ลองนั

By Chokchai
Scrum master focus

Scrum master focus

ครั้งแรกที่ผมได้เรียนว่า สกรัมมาสเตอร์ควรแบ่งโฟกัสการโค้ชของตัวเองเป็น 4 เรื่องคือ 1. องค์กร 2. engineering practice 3. product owner 4. ทีม ผมอดคิดไม่ได้ว่าคนบ้าอะไรจะไปเก่งทั้ง 4 อย่างซึ่งมันใช้ความรู้และทักษะที่แตกต่างกันเหลือเกิ

By Chokchai
Community of Practice (CoP) คืออะไร?

Community of Practice (CoP) คืออะไร?

กาลครั้งหนึ่ง… ชมรม Community of Practice (CoP) เป็นคอนเซปต์ที่ถูกกล่าวถึงใน Large Scale Scrum เทียบง่าย ๆ ก็เหมือนชมรมตอนเราเรียน ม. ปลาย นั่นแหละ ใครสนใจเรื่องอะไร ก็ไปเข้าชมรมนั้น แล้วก็ไปทำกิจกรรมร่วมกันในเรื่องที่เราสนใจ เพื่อฝึกฝนและแลกเปลี่ยนความรู้ บางทีอาจจะมี

By Chokchai