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.

the-goodman-iceberg-model.png

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

Scrum master ทำแค่เนี๊ยะ

Scrum master ทำแค่เนี๊ยะ

เวลามีคนถามว่า Scrum master ทำอะไร แล้วผมตอบว่าทำให้ Scrum เวิร์คสำหรับทั้งองค์กร ซึ่ง โฟกัสหลัก ๆ 4 อย่างก็จะอยู่ที่ Product owner, ทีม, engineering practices และ องค์กร บางครั้งที่ผมจะได้ยินเสียงตอบกลับมาเบา ๆ ว่า “แค่เนี๊ยะ?” ในฐานะ

By Chokchai
how to สร้าง Knowledge Management

how to สร้าง Knowledge Management

ตอนเรียน Large Scale Scrum กับ Jurgen de Smet สิ่งหนึ่งที่ผมได้เรียนรู้ คือ ปัจจัยสำคัญหนึ่งที่ทำให้องค์กรหนึ่ง ๆ จะเร็วขึ้นได้ คือ จะต้องเรียนรู้ไปพร้อม ๆ กันได้ ซึ่งถ้าอยากทำแบบนั้นได้ก็จะต้อง share ownership

By Chokchai
โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

โลกการเขียนโค้ด ตอน ซามูไรกับสปาตั้น

ซามูไรที่ได้รับความไว้วางใจให้แก้ core logic จะมีสัญชาตญาณซามูไร คือแก้ตรงนี้ จับยามสามตาแล้วรู้เลยว่าจะไประเบิดตรงโน้น แล้ววิ่งไปสกัดบั๊กไว้ก่อนความเสียหายจะเกิด (ถ้าเป็นในหนัง ตอนนี้เป็นบทที่บั๊กร้องว่า “มืงรู้ได้ไง?!” :D) หลังจากที

By Chokchai
ประสบการณ์ TDD

ประสบการณ์ TDD

มันมีบางชั่วขณะ ที่ผมอินกับ Test-Driven Development (TDD) มาก จนอยากจะแนะนำทักษะนี้ให้คนเขียนโค้ดทั่วโลกที่สนใจเลย ผมคิดว่า ทักษะนี้มีผลเยอะมาก ๆ กับความรู้ความชำนาญในการเขียนโค้ดของผมทุกวันนี้ แต่ที่ผมไม่เคยอธิบายเป็นคำพูดออกมาได้คือ ทำไมนะ? เมื่อเช้าตอนกำลังอ่านเกี

By Chokchai