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.
Ken Schwaber's Blog: Telling It Like It Is 
Yes Ken. You are correct. Scrum does not scale. However that’s a weakness of the prescribed process… Anyone operating at that scale should have doubtless evolved their processes beyond scrum.
However, that does not imply scale is not possible.. Or even difficutk..Just scrum ain’t it. Actually it never was.. It should have been a good start point but has just become dogma..
There are many companies and organisations who operate effectively at scale. It’s not even much of a challenge.. Just good communication, good structure, good separation of concerns.. The building blocks of all good engineering..
There are so many setups that operate at scale it’s not even an interesting problem. It’s only limited approaches like scrum that make it so.
The whole thing is phrased wrong. It should never have been ‘how do you scale scrum’ it should be ‘what works at scale’..
No ones goal should be scaling scrum.. The process exists to serve the function not the other way around..
Reblogged this on Technology Unplugged..
Hi Ken,
In the last part, you give two choices. I was wondering why is the architectural and platform structure the only way. Imo, the reality of large products gives more possibilities and is often some segregation into feature areas or domains and subdomains. Of course, this is often similar or same as structuring architecturally. But, just as often, there could be minor part which is common and major parts are specific, and therefore only minor part is shared among all teams. If this part is small enough to limit dependency, then problem of sharing among more than 10 teams is rather minor. Each specific area is done by one set of teams. All sets together could still produce one increment if delivering an increment has no dependency between sets. Think of Apple OSX which has many feature areas, but still results into one increment (I do wonder how Apple actually builds OSX).
Reblogged this on Schirmer.org and commented:
Ein paar Gedanken von Ken zu großen Teams und warum das Management die Probleme (Herausforderungen) oft nicht sieht.
Nicely said because the context of some enterprise just don’t care about scaling because of all the design thinking such as micro service which separated but weaven by the service contract, originally created by individual interaction.
Somehow, the illusion of service contract push people into the comfort zone of no need for the conversation. It is the natural cycle and I have to admit that sometimes we just can’t resist the human nature.
Reblogged this on PROMPT>> init 6 and commented:
Good idea on scaling scrum
That is a very good idea Ken. Scaling Scrum comes down to scaling how developers design the architecture of the system.
Reblogged this on SutoCom Solutions.
I fully agree 10 scrum teams, the Nexus is optimal to get out a “reified” software. Beyond that the complexity in the interactions kills the effectiveness. However isn’t this similar to what SAFe is also advocating with its train approach, where they say that a train should not have more than roughly 100 people (consider scrum teams + few other roles supporting the scrum). I would be interested to know the difference you see if any in the Nexus vis-a-vis the Train approach
Reblogged this on Hirendoshi73's Blog.
Pingback: Studying for the PSM II exam – Thoughts on Software Management and Development