Can we Scrum with Nexus?

1. A Nexus would only be cancelled if the Product became obsolete, and the Scrum Teams which constitute the Nexus are no longer needed. Is that what you mean, or are you referring to Sprint cancellation?

2. The ability to collaborate becomes attenuated when more than 9 parties are involved. If more than 9 teams are needed to build a Product, what are your thoughts on how to approach the matter?

3. What does the Scrum Guide say about trying to vest product ownership in a group? Shouldn’t the 3-9 teams within a Nexus be able to self-organize in such a way that a Product Owner is accessible, and shouldn’t the PO be able to manage his or her time effectively? If not, is everyone ready for Scaled Professional Scrum?

Thank you Ian for taking the time to reply.

1. I was referring to the Sprint cancellation - although I must admit it is unclear what is the Sprint in Nexus. I assume, all teams within the Nexus constitute a Sprint. Hence - If a team within the Nexus finds it's goal obsolete it should trigger a new Nexus Sprint Planning session. It rather more complicate as being within a Nexus coordination it is required.

How do you see this Ian?

2.1 WIP. I would first try to see if there is absolutely no way to reduce scope of the MVP so that the degree of scaling is manageable.

2.2 Stretch. If the features selected for the MVP are reduce to the absolute minimum required to release a first version  of the product - I would try to stretch, adding few more teams and check if we are still able to self-organize on a single backlog and a single PO.

2.3 Divide. When none of the above it is possible and the product is definitely way bigger than we can successfully organize within a Nexus - I would look for ways to create discrete products. Perhaps per region, interface, service, variation etc. I would explore for a such architecture that would allow multiple Nexuses run independently. With this I expect that at some point we need to expect diminishing returns.

What am I missing?

3. This is the root of this post. I was concern that Scrum at Scale adds too much admin work and dilution of clear product ownership and availability. Hence, the entrepreneur spirit of true atomic Scrum teams may fade. It is very clear there is no shared responsibility - there is only ONE responsible for the outcome of the development teams. I was emphatic I guess - How it is possible to do such a task....

But now you triggered me:

able to self-organize --> I see now that when we scale Scrum we need to look past typical one product one team and self-organizations capabilities of the team. We need to grow once more and be able to self-organize in tandem with multiple teams and act as a whole.

ready for --> I see now how it is not for everyone and scaling comes with its own characteristics - it may not be possible for all to successfully scale.

Scaled Professional Scrum --> It is no free lunch. I was tricked because everywhere you look now you see scaled delivery. It is like there are no constrains to do it. But I see now in fact there is.

I would like to add a final note. Why very few organizations seem to care about the implications and constrains of the scale factors? Is it because they are oblivious or disrespectful?

Thank you in advance.

If a team within the Nexus finds it's goal obsolete it should trigger a new Nexus Sprint Planning session.

Why, when the overarching Nexus Sprint Goal might still remain valid?

What am I missing?

The preferred option should be to descale the organization and the challenge faced, rather than to seek recourse to a scaling mechanism. The WIP/Stretch/Divide techniques you outline seem reasonable.

However, the more you try to scale, the closer you get to an organization working in its own unique context, and the harder it is to abstract a generalized scaling framework. There may well be a Nexus+ which is useful beyond Nexus, but it is harder to elicit its rules.

I would like to add a final note. Why very few organizations seem to care about the implications and constrains of the scale factors? Is it because they are oblivious or disrespectful?

Do they care about the empirical process control which first ought to be demonstrated by even just one small team?

Thank you Ian for taking the time to help the community.

Why, when the overarching Nexus Sprint Goal might still remain valid?

It is clear now regarding Nexus Sprint, overarching Goal and cancellation - further on discussion will be splitting hairs.

Do they care about the empirical process control which first ought to be demonstrated by even just one small team?

The evidence says they do not. At this point we are 15 teams in a project following SAFe setup. My intention it is not to blame the tool as the success depends on us. Nonetheless I would like to share with you few mechanisms In SAFe that obfuscate transparency:

• Emphasis on bigger is better;
• 'Done' inflation - at this point we have 4 types of done;
• Design & Discovery 'Sprints' - where it is ok to not get things done. Creates a dangerous precedent;
• Cool off sprint at the end of the PI;
• There's no single clear owner responsible for the product. In my setup there are more than 10;

It fair to say that it doesn't matter what scaling process it is used if the organization it is not ready and empirical process control is not honored.

PS: I will try Nexus in a parallel project to check the differences;

Thank you Ian and Scrum.org.

Awesome community - respect.