James O. Coplien

Scrum, as originally outlined in the Scrum Guide, is a framework for developing, delivering, and sustaining complex products by a single team.¹

These days, scaling frameworks promise to make the elephant dance as big organizations seek a slice of the Agile pie. They work in the sense that military hierarchy works, yet hierarchy is hardly conducive to Agile’s individuals and interactions. In a Scrum@Scale team-of-teams hierarchy, where each node has five subordinate nodes (other teams or individual developers), an organization of 625 people features an average of 7.5 hops between Developers. Small world theory² proposes that everyone on Earth is connected by, at most, six connection hops. Scrum@Scale establishes connectivity between 625 people that is not as good as society provides for 8 billion people.

But few Scrum developments need to be this big. Excuses for scaling include the assumption that a small group has small intellectual capacity and cannot handle the scope of a complex product. Yet the human mind is boundless. Another excuse is productivity, with Scrum talking heads speaking of increasing velocity by orders of magnitude through kaizen. If it’s between a better process and a larger organization, the choice should be clear. The Borland QPWs,³ Skypes, and other gems of history testify to the ability of small teams to build large things.

Nevertheless, business is more than just five Developers, a Product Owner, and a Scrum Master. You need distribution channels, sales, and marketing. Good Product Owners have a team that may include a model shop, analysts, and many others. Personnel takes care of payroll and pensions. Support holds customers’ hands. We too often pretend we can divorce these from development, but that’s a myth from the “build it and they will come” days. Many of these folks need a good connection to development; these days, it goes by the name enterprise Scrum. And hierarchy doesn’t cut it.

How does small world theory handle it? With hubs. With the advent of the internet, we found that web pages exhibit a pattern of connection where very few nodes with a very high degree of connection tie everything together. Such networks are called scale-free networks.⁴ In Carl Castillo’s figure from Wikipedia, we see the hubs highlighted. Each network has multiple “tops.” So it can be for an organizational structure.

Running an Agile enterprise is a matter of introducing such hubs and nurturing latent hubs, rather than routing communication through the least common manager. Scaled Scrum approaches recognize a few hub structures such as the Scrum of Scrums—far too few in number to be scale-free.

What are good hubs? Guilds. System testing. Architecture. Code stewards. The water cooler. Management is particularly important: weakening the management connection with empowerment programs leaves teams uncoordinated.⁵ To be Agile means stepping back from the extreme fads of the moment and honoring what history has shown to work well.