Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ


Choose your language

InfoQ Homepage News Scaling Scrum Without the Scrum of Scrums

Scaling Scrum Without the Scrum of Scrums

Leia em Português

This item in japanese


Scrum has proven effective at promoting communication between members of a development team.  The question of how to scale this high-bandwidth communication across teams, especially in large organizations, remains an area of active exploration and debate.  Will Read has proposed a mesh-network inspired alternative to the popular Scrum-of-Scrums meeting for achieving this goal.

Will points out that the Scrum of Scrums creates a hierarchical, tree-shaped communication network.  People are the creators and consumers of information in the system, and they are the leaf nodes in the tree.  This structure works reasonably well for drawing information to, and disseminating information from, a central control point.  However, this may not be the best way to coordinate the work of the developers.  The type of information that individual developers need to know is unlikely to get transmitted up and down a tree effectively.

Jim needs to know about the new Logging API so he doesn't have to rewrite one of his own. Bob needs to know that Sue has a problem with the parameters being passed to her function because she wasn't expecting NULL to be allowed. Dave needs to know that he needs to add upgrade the Linux servers to the latest Java VM to fix a bug Mark found, and the new employee, Mindy, needs to figure out where to download the third party DLLs from.

This type of information is more likely to flow across a mesh network where individuals and teams connect with each other in a more ad-hoc and as-needed basis.  The question then becomes, how can a company create a mesh network that promotes this type of information to flow?  Promiscuous attendance at daily stand-up meetings is one approach.  If two or more teams often work in the same code, or otherwise are likely to have interdependencies, then it may make sense to allow members to attend the stand-up meetings of the related teams.  Will also suggests some additional approaches:

  • Promote and facilitate the self-management of the network
  • Assign related feature sets to teams in ways that promote connectedness of the mesh
  • Schedule an off-site for teams that don't often work together
  • Identify the natural hubs, and promote cross-hub communication
  • Consider moving people between teams that have strong connections

Will describes the benefits of this type of communication network this way:

Through this Mesh network, a company can produce a much more adaptive communication structure that disseminates knowledge more reliably, is at less risk of a communication failure, and addresses the issue of limited bandwidth in a way that scales to any sized company. Best of all, it fits with Agile principles of self-organizing, and removing waste in a way that enhances your business.

As described, the mesh network is designed to promote information flow between developers, not  status reporting up to management.  For this, the tree may still be the preferred approach, though the amount of bandwidth needed will be greatly reduced if the focus of that communication is around status, progress, and priorities.

How do the Scrum teams in your organization communicate with each other?  How well does it work?  How could it be better?  Leave a comment and share with the community.

Rate this Article


Hello stranger!

You need to Register an InfoQ account or or login to post comments. But there's so much more behind being registered.

Get the most out of the InfoQ experience.

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Community comments

  • It Depends on How the Scrum of Scrums is Executed

    by Tim Elton,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    We've found that Mesh alone only goes so far in promoting communication. We created a SoS where each team nominates a representative to attend for a Sprint. The reps rotate so all team members will eventually get a turn to attend. We run the SoS exactly the same as the Daily Scrum Meeting by each rep answering:
    - What did my team do yesterday?
    - What did my team do today?
    - What impediments is the team facing?

    This approach has removed the hierarchy problem sited in the article. It works great in combination with the suggested Mesh approach.

  • Your message is awaiting moderation. Thank you for participating in the discussion.

    I used to work for this company that had two teams which were not in the same geographical location. The two teams were working on two different products but they were led by the same CTO; therefore, we were asked to keep the technology level in the two products at the same level so that managing technology risk and all those things is a lot easier. It goes without saying we had serious communication issues and to some extent we had lack of communication to begin with. However, we used a Wiki that had RSS update feeds, and everyday when I had a few free minutes I used to go through what was new in the wiki and after a while I was an active member of the other project's discussions.

    I could never put this idea into practice but I do believe programmers should blog their programming life and everybody in a company should browse those blogs. This will give a very good visibility to what is going on throughout a company.

  • Re: It Depends on How the Scrum of Scrums is Executed

    by Tim Elton,

    Your message is awaiting moderation. Thank you for participating in the discussion.

    - What will my team do today?

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p

Allowed html: a,b,br,blockquote,i,li,pre,u,ul,p