Scaling Is The Answer To The Wrong Question

If you’ve read one of my favorite 80’s books, Hitchhiker’s Guide To The Galaxy, you’ll recall it concerns the search for the Answer to the Ultimate Question of Life, the Universe, and Everything. I’m not giving away much by revealing that answer is merely the number 42. It turned out that discovering the correct question was a more important and difficult problem.

By “scaling Scrum,” we usually mean using more than one team. About 10 years ago – when some Scrum trainers had a scaling topic in their CSM classes and some didn’t – there were discussions whether or not this was appropriate in an introductory class. The argument against sounded reasonable at first, something we still hear today, “You can’t scale what you can’t do.” The argument was that it was necessary to get good at single team Scrum before thinking about how to use multiple teams. Sounds reasonable, right?

History suggests we missed the mark by failing to reframe the “Scaling” topic into How To Do Scrum In An Organization With More Than Nine People?

How To Do Scrum In An Organization With More Than Nine People is relevant to nearly every class participant I’ve had. Nearly every company “doing Scrum” screws this up.

My objection to “You can’t scale what you can’t do” is that you also can’t do what you can’t do. People who come to Scrum classes suffer scale-induced impediments such as these:

• They’re parts of component teams (instead of feature teams), or insufficiently cross-functional teams, or other teams that are just cogs in a larger traditional process. In the big picture, they’re still doing waterfall.
• They’re surrounded by project managers renamed as Product Owners or Scrum Masters.
• They don’t have access to real Product Owners.
• They aren’t allowed to talk to customers and end users.
• They were thrown together by someone else.
• They’re shared “resources.”
• They’re affected by harmful HR practices.
• They’re affected by excessive hierarchial layers, overspecialization, and role distinctions.
• They’re geographically distributed.
• They fail to continuously integrate with other parts of the product.
• They have mountains of technical debt.
• They’re constantly fixing regression failures and other production emergencies.
• They’re making everything worse due to pressure to increase their velocity.
• They have managers who don’t understand Agility.

Due to these scale-induced impediments, they’re not even going to succeed at single-team Scrum. Just teaching single-team Scrum in a vacuum (as rationalized by “You can’t scale what you can’t do”) hasn’t helped real organizations enough, opening the door to monstrous processes that try to fill in Scrum’s gaps.

To be able to learn and adapt to reality (let’s call that Agility), organizations desperately need some of the scaly-ness removed. You can’t understand Scrum without realizing its implications for organizational design, both structure and policies.

While we should teach descaling organizational complexity first, unfortunately we’ve been treating those lessons as a subcategory of “scaling Scrum.” This provides an excuse not to teach them in introductory (e.g. CSM) classes. That excuse vanishes when we state the question correctly: How To Do Scrum In An Organization With More Than Nine People?