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.

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.