It is not the strongest of the species that survive, but the one most responsive to change.
― Prof. Leon Megginson (wrongly attributed to Charles Darwin)
It is not necessary to change. Survival is not mandatory.
― W. Edwards Deming
Why Scaling Matters
“Well, we used Scrum and it worked really well for us, so we added more teams …“
If you work as a Scrum@Scale Trainer, this is how a surprising number of conversations start. Experienced Scrum Masters and coaches ask for lunch or coffee dates and more often than not, the above phrase will be uttered, invariably to be followed by a description of the mayhem that ensued afterward.
Your next move in that situation is to ask what scaling framework they are using, but you already know the answer to that question.
It is not so much that they chose the wrong framework — even though you can arguably do lasting damage to your organization by choosing the wrong scaling framework — it is that they did not choose a framework at all and just started ramping up.
Welcome to the age of inadvertent scaling.
Are We There Yet?
Given that the first Scrum team started working in 1993, and the Agile Manifesto has been around since 2001, one would be forgiven to ask, “are we there yet?”
On one hand, just as software is eating the world, Agile is eating the world of work. A look at the most valuable companies on the planet quickly shows that almost all of them are agile, with most doing Scrum. So the answer should be a resounding “yes!”
the preponderance of Scrum in the most valuable public companies1
But on the other hand, while some of the most dominant companies in the world are succeeding with Scrum, there are also many organizations that lag behind in its adoption.
This is to be expected as every adoption (think cell phone or electric car adoptions over time) will happen earlier in some places and later in others.
But considering how the Scrum vanguard — companies such as Amazon, Tesla, ING, and Spotify — are upending industries and how long Scrum has been around, surely something else is going on. Why is not everyone doing Scrum?
A significant factor in the discrepancy between the vanguard and the laggards is that many companies have difficulties extending Scrum from a limited number of teams to many, never mind the whole organization.
And it is true: Scrum as a framework “in which people can address complex adaptive problems, while productively and creatively delivering viable products of the highest possible value” is not limited to single teams per se, but it also does not necessarily address how to organize networks of Scrum teams.
Yet successfully running networks of Scrum teams operating consistently within the Scrum Guide is what scaling is about. And without scaling, your organization will have a hard time attaining the elusive state of business agility, where the whole company will be agile. Even worse, unless the entire organization is saturated with Scrum, the teams at the bottom of the hierarchy will always remain a beachhead — vulnerable to the non-agile rest of the organization striking back like the Empire and sweeping it away.
Why Scaling Often Fails
Besides “inadvertent scaling,” where organizations just spin up teams without knowing how to coordinate them, there are several other typical reasons why scaling Scrum does not work.
The Scrum That Wasn’t
When doing the initial interview for a coaching engagement, clients often state that they are “doing Scrum.” This, however, is rarely true.
So let us be honest with each other for a minute: When people say they are “agile,” usually they are not. What they mean by this is that they use agile jargon to describe what they have always done (more or less successfully).
What is being done under the name of Scrum is usually some form of “ScrumBut.”2 While doing Scrum was maybe the original intention, over time, too many exceptions were made when resistance was encountered, with the result being a system that is often Scrum in name only.
If one understands Scrum to be a system of feedback loops, then dropping one of the loops will eventually lead to an imbalance of the whole system that will at best lead to a subpar steady state, but at worst will unbalance the system in a way that will make it fold in on itself, as the organization will find ever more ways to install more and more “fixes” for Scrum that would not have been necessary had Scrum been followed more closely in the first place.
This is also one source of the perennial conflict between Scrum coaches and clients. The customer complains that the coaches sound like a broken record in their exhortation that the problem is that “they are not doing Scrum right.” While there is certainly always room for improvement in how that message is communicated by many Scrum Masters and coaches, the fact is that all parts of Scrum serve a specific purpose. And if you leave them out, that will cause problems.
And the less experienced you are in Scrum, the more likely it is that the solution you devise to compensate for the part of Scrum you are not doing will mimic tumor cells, first growing, then spreading and soon overwhelming your teams, requiring increasingly more band-aid solutions. Unfortunately, it often only becomes apparent that band-aids were the wrong solution when it is too late.
If our goal is business agility, then it should be easy to imagine that building an agile organization on this faulty team-level foundation is bound to fail ignominiously.
Business Agility is More Than Team-level Scrum
The other problem with clients thinking they are doing...
