Seeing the system dynamic: coordination role vs. self-organization

Introducing coordination roles is a very common choice made by many organizations to deal with coordination complexity. I realized during the recent course that this quick fix is seen by many as the only solution while it is hard for many to even image that there is another fundamental solution. Therefore, I decide to write down this dynamic to help see it.

In scaling environment where multiple teams need to coordinate with each other, it is so tempting to introduce coordination roles for them. Those roles are often called project/feature coordinators/managers. When I asked why teams could not directly work together, that possibility seemed so far  from reach. I know that the burden has been shifted.

The below is the CLD (Causal Loop Diagram) for this dynamic.

Organize time - coordination role vs self-organization.png

This is a typical "Shifting the burden" system archetype.

There is a related dynamic of solving this complexity by coordination vs. by organization design, which was illustrated in another article. In this article, we assume that the complexity is still manageable through coordination.

When we face coordination complexity, it is easy to introduce a role and give him/her the responsibility to coordinate that complexity away. When he/she is successful, the complexity decreases. This forms B1-loop.

The more fundamental solution is to build the capability in self-organization so that teams can work together and coordinate directly to reduce the complexity. The capability building will take time thus a delay is involved. This forms B2-loop.

The more interesting characteristic in this dynamic is the additive R-loop. The success of coordination roles increases the organizational appreciation on them, and then, the dependence on them. This dependence shifts the focus away from building capability in self-organization, which makes it more relying on coordination roles.

You see the additive loop in play when you hear people say that there is no way for teams to directly coordinate with each other as their capability is not sufficient.

LeSS vs. SAFe

It is interesting to compare LeSS and SAFe on this regard.

  • SAFe defines PI planning (aka big room planning), where teams identify and coordinate dependencies by themselves. That is in line with the principle of self-organization.
  • LeSS defines joint Sprint planning, where teams coordinate directly with each other. That is in line with the principle of self-organization too.
  • SAFe defines SoS (Scrum of Scrums), where SMs participate to coordinate cross-team issues. This is the solution of having coordination roles. In fact, it is even worse, as it alters SM role. SM is never a coordination role, but a facilitation and coaching role.
  • LeSS defines many coordination mechanisms, with the preference over decentralized ones. Even for SoS, that is not participated by SMs, but team representatives.

I feel sad that SAFe takes the spirit of self-organization in planning, then moved to coordination roles afterwards.

I feel more sad that people from different teams could not Just Talk without involving coordinators/managers.

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