Nexus - Maximum of 9 teams and 81 people
Hi,
If a Product is very large and complex and the time required to bring it to market is less due to other external factors, the management decides to put in large number of resources to build the product quickly. Scrum is adopted and Nexus guide prescribes having only a maximum of 9 Dev teams having max of 9 dev team members (81 in total). If this resources number is very small when compared to building the product quickly, what are the different options to be considered keeping in view the management's request?
1. Breaking down the product into different sub products and hence have separate product backlogs and separate teams ?
2. Cutting down the features to be brought to the market in the specified time ?
3. Any changes to the Nexus scrum framework?
or
4 Any other options ? please advice.
Thanks,
Reddi
Hi,
In usual scrum, a development team cannot spend more than 10% of their time in Product Backlog Refinement. But in scaled scrum, there is no specific mention about this.
1. Who specifically (Representatives or whole teams) ,is going be involved in the refinement sessions?
2. How much time is involved? There is no time box defined, so what if it starts consuming more time from the development teams?
Thanks,
Reddi
If you break a product down into "sub products" with their own Product Backlog and Product Owner, then they're no longer a Product. Products have their own Product Owner and a single Product Backlog. When you break a single product into multiple sub products you have, in simple terms, an integration mess.
You can break the product into multiple components, loosely coupled through APIs, but this only works if the components don't have unique product functionality. For example, lots of products these days need mechanisms for gathering feedback and usage information, and those mechanisms aren't product specific. You can refactor these components out, but that means that you can't have cross-team dependencies that need to be resolved in a Sprint.
Before assuming that a Product is large, I'd confront the typical reality that most of the features in any product are never really used; a lot of what gets built and delivered is pure waste. Figure out what really needs to get built by delivering in small batches, measure the result, and improve. In other words, inspect and adapt. This is basically your option #2, and is the right thing to do no matter what size your Product.
Additionally, the "9 person per team" and "9 teams" "limits" in Scrum and Nexus are not absolute. Is 10 persons per Scrum team absolutely wrong? No. Is 20 persons per Scrum team wrong? Yes. Somewhere between those two numbers there is a point where adding people makes things worse. It's not Scrum's limitation; it's human behavioral dynamics. Same goes for the number of teams.
It is possible to organize "Nexuses of Nexuses", something called Nexus+. This is discussed briefly in the Scaled Professional Scrum course. To pull it off requires first getting really good at Nexus, just as Nexus requires the teams to first be really good at Scrum. Rather than jumping straight to something like Nexus+, first try reducing scope and release size and increase your feedback cycle speed; you'll probably find out you don't need a lot of the features you think you need, and that will simplify almost everything else.
Regardless of scaling considerations, is there a clear Product Owner who can define product value?
this thread seems to be outdated, cottect?