BT

Facilitating the Spread of Knowledge and Innovation in Professional Software Development

Write for InfoQ

Topics

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

Adoption
Style

BT