Thinking Ofscaling Scrum

Thinking of scaling your scrum team? Think again.

Some processes like waterfall, have independent isolated phases of development (requirements, design, build and test) that are separate and can be scaled by adding resources into the separate phases.

In contrast, scrum is “scale free.” It uses highly coordinated, cross function teams that grow like ecosystems do in a piecemeal and organic way. In such teams, adding people beyond a certain point will slow things down, mainly due to the greatly increased overhead of communication, synchronization and being assimilated by the team. An analogy would be trying to speed up the task of sorting a deck of cards by adding more people.

In a talk given by Jeff Sutherland at the UPscALE (Upscaled Agile in Medium & Large Enterprises) event he said “Scrum scales fractally rather than hierarchically. The true success of your scaling efforts doesn’t really depend on whether you can hire more people in your preexisting organizational structure. Instead, the real key to scaling is whether the values of Scrum(Focus, Openness, Respect, Courage, Commitment) have been truly adopted and internalized throughout the organization” – so essentially until work has been done to get the most from existing teams adding more people will simply enlarge the problem.

In Jim Coplien’s article in IEEE Computing, he also suggests it is much better to improve the existing the scrum team so they can do things in less time rather than adding more people. If you could get an order of magnitude performance improvement in your scrum team – why would you consider adding 10 times the people?

The idea is to concentrate on increasing business value with as few people as possible, in this way you “lean down” instead of “scale up”.This idea, to lean down, is counter intuitive to many organizations, which tend to add more people to existing teams. Frequently, the new roles add little value, exponentially increase the burden of communication, reduce performance and only serve to assuage the worry that competitors may somehow outperform them. Ironically, these same organizations frequently suffer from significant “developer friction” and practices that inhibit performance.

So when faced with the prospect of adding resources, or migrating a large resource pool of engineers to scrum, stop and think if this is the best option, consider that it is better to increase the velocity of existing teams rather than add more resources to the mix.