Scaling Scrum:Why Scrum Masters SHOULD NOT be coordinating between Development Teams

When multiple Development Teams (henceforth teams) are involved in building a product using Scrum, they have to coordinate to build ONE product increment. In most cases, this means that they have to have some sort of coordination between them to ensure that all features work seamlessly so that the “Increment” is releasable at the end of the Sprint. The need for coordination arises due to reasons like (a) lack of specific technical/ product knowledge by a Development Team (b) private code bases – only one team can access the code base and check into it (c) fragile and brittle code – lack of proper automated tests (technical debt) makes it impossible for any team to do the work. Only the team that knows the code base can work on it (d) Teams building components (e.g. middleware team, data warehousing team) instead of building end-to-end customer centric features (e) align teams and ensure that everyone is going in the same direction

The need for coordination between Development Teams create tight coupling and slows everybody down (and the organization stops to be “Agile”), not to mention it creates a lot of waste in the organization (e.g. adding specialists role for coordination) . Many of the problems associated with coordination are avoidable by creating cross functional feature teams (e.g. using a feature team adoption map), creating internal open source code base (so that anyone can check-in code) and by having robust eXtreme Programming technical practices. However, some coordination is unavoidable (e.g. two teams checking code into the same area of the source code). In cases where coordination between teams is necessary, it is imperative that the Scrum Master does not become the coordinator (rather the team members have to coordinate amongst themselves). Why ?

• Scrum Master coordinating increases the number of hops for the flow of information. Rather than two team members talking amongst themselves, it would be two Scrum Masters talking among themselves and acting as go-between. Now this has become a game of telephones. If the Development Teams are in different geographies (e.g. a colocated Development Team in New York and another collocated Development Team in Bangalore), having specific person coordinating with teams ultimately increase the cycle time for feature development
• People doing hands-on work know a lot more information and can share more/less appropriate information. Scrum Masters are not hands-on so they have less context about the problem that they are trying to solve
• The Development Team is self-organizing. By the same lemma, Development Teams must be self-organizing. Scrum Master coordinating between Development Teams undermines self-organization
• It creates a dependency on the Scrum Master for the Development Teams. A Scrum Master’s job is to make themselves redundant to the Development Teams (so that they can focus on organizational impediments)
• The person doing the coordination has lot more “power over” over the other entity (in this case Development Team). When Scrum Master does the coordination, it creates an imbalance in the Scrum Master – Development Team relationship.
• When trying to scale (think of 10 teams checking code into the same module), with more coordinators, things tend to become more centralized (e.g. coordination meetings) and creates hierarchy (Example 1 – project managers, program managers, portfolio managers. Example 2- Scrum of Scrums, Scrum-of-Scrum-of-Scrum, etc). Hierarchy impedes faster information exchange (and thus reduces the agility of the organization). Decentralized coordination techniques (e.g. Just Talk, sending observers to other Development Teams Daily Scrum) do not create bottlenecks and enable faster flow of information
• When the Scrum Master is coordinating, the Development Team is either (a) waiting or (b) not working on the highest valuable Product Backlog Item. Both of these are wastes and can be avoided if the Development Team members are coordinating amongst themselves
• More importantly, the current design of the organization (unintentionally) generates the waste it is designed to generate. These will never be recognized as wastes/impediments, will be swept under the rug and nothing will change in the design of the organization. And the true benefits of implementing Scrum will not be realized.

Acknowledgements: Thank you Michael James for granting me permission to use your image in my article