Nexus +

I would question the need for such a thing.

The Scrum Guide recommends that each Scrum Team consists of a Product Owner, a Development Team of between 3 and 9, and a Scrum Master for a total size of 5 to 11 individuals. Nexus is designed to facilitate between 3 and 9 Scrum Teams supporting a single product with a single Product Backlog producing one Integrated Increment. In terms of people, this would be between 15 and 99 individuals across all the roles, including between 9 and 81 developers.

At some point, I'd really consider looking at the size and composition of the Scrum Teams and how they are organizing around the Product Backlog before trying to scale to two or more Nexuses. I'd also start looking at the product and ensuring that what I have is truly one single product and not a product family or product suite.

Nexus+ is a thing and is covered in the SPS course. However it is perhaps defined more by what it is not, rather than by what it is. Since the challenges tend to be unique at an aspirational Nexus+ scale, a distinct framework has not yet emerged, at least as far as I know.

Remember that complexity increases exponentially and the preferred option would be not to scale further at all. Nexus therefore remains the basic organizing principle of Nexus+. Rather than another framework, in Nexus+ there are additional considerations for organizations to bear in mind. Here are my own notes:

1. whether it might actually, at this scale, become necessary to have an integration team...and if so, how its duties can be minimized.
2. whether dependencies between one Nexus and another can realistically be managed at all, or must be forbidden.
3. whether to establish an architectural platform (or an API) to ease product integration.
4. whether the Nexus+ can effectively amount to such a platform or API.
5. what are the implications of maintaining a platform/API on feature teams? Might a component team be needed? How powerful would it then be (see 1)?
6. how to accommodate a likely operational need for multiple Product Owners.
7. how to deal with integration concerns where Sprint cadences are now more likely to differ.
8. how to deal with integration points involving non-Scrum teams.
9. how to assure bottom-up intelligence.
10. In general, how to scale horizontally across the enterprise rather than vertically.