Scaled Professional Scrum is based on unit of development called a Nexus. The Nexus consists of up to 10 Scrum teams, the number depending on how well the code and design are structured, the domains understood, and the people organized. The Nexus consists of practices, roles, events, and artifacts that bind and weave the work together to produce a whole.
We have found that when we get above ten Scrum teams that their ability to create usable products frays. The complexity and the dependencies that require resolution are overwhelming. The ability to create a “done” increment and not leave behind a pile of technical debt is daunting without shortcuts that reduce product viability.
Some high tech vendors claim to regularly employ 100 or so Scrum teams on products and product families. They are not scaled, however. Scaling carries with it the responsibility that all of the attributes of the smallest element are found in the sum of all of the elements (100 or so teams perform like one team). This is similar to the mathematical expression that generates uniform, interlocking fractals.
Let’s look Scrum’s fundamental principles: empiricism and bottom up thinking. Empiricism requires inspection of known artifacts and appropriate adaptation.
Working software has no egregious unresolved dependencies. Business functions interoperate intelligently, the people with the knowledge to create them worked together to build these, the data layer, UI layer, design, and code all are woven together into something that works and can be readily added to in the future. And, when tested, they do what is expected and do it with everything else as expected. We have come to call an increment that does this “done.” Sometimes “done-done.” In Scaled Professional Scrum I refer to it as reified (reification generally refers to making something real, bringing something into being, or making something concrete).
If all things are optimal, I have found that no more than ten or so Scrum teams can build a “reified” increment that is truly done, usable, and doesn’t leave technical debt. If the starting point consists of sloppy code and design, poorly formed ideas, and people that aren’t skilled or work together well, then a much smaller number of teams is the only viable approach.
However, when you get to twenty or so teams it doesn’t matter how optimal the context is. To take them and integrate their selected product backlog into a system that has a new working increment added to it just doesn’t happen. The complexity of dependencies that must be resolved is too great. However, management doesn’t believe this because, duh, they aren’t software developers. So they put 100 teams on it.
Since we can’t reify our integrated work at this scale, we instead demonstrate our working branch of working, partially tested functionality.. Management sees many functions working, but they aren’t integrated into a whole (reified). Then comes ship date. Whoops … we have to integrate all of the stuff. Guess what happens… the death march to make it look reified even though it is patched together.
Think of IOS and the SDK, or the new Google Brillo and Weave. These are standardized structures that define how functions must work together to be part of the system.. The same is true for the IOS and SDK of the Tesla, except in spades.
So you can have hundreds and hundreds of Scrum teams working on the same product area. However, when you have functionality that requires more than nine or so teams you have two choices:
- Build architectural and platform structures (IOS, API, etc.) that defines how the functionality from each set of Scrum teams must deliver and interoperate.
- and/or take longer and only do as much as the nine or so teams can do at once. Then do more. Then do more.