Nexus is about integration. It's very hard to do integration well without an adequate toolchain, but following the Nexus framework should enable you to iteratively improve your organization's ability to integrate. Your main challenge seems to be either:
- A misunderstanding of the way that the Nexus Product Backlog items are refined, visualized, and selected across teams.
- Missing Product Backlog items related to developing the capabilities required to actually integrate the Integrated Increment.
In either case, the process side of the problem can be addressed during the Nexus Refinement and Nexus Sprint Planning events.
Using the Product Backlog Effectively in Nexus
The following is a restatement of your interpretation of Nexus as it applies to your situation:
A move to Nexus means teams should select the highest priority stories even if it means all teams start working on the same code, i.e. all teams would work simultaneously work on teleconference integration.
This is an understandable misinterpretation based on common Scrum practice. However, it is incorrect for three reasons. The reasons are:
Scrum Teams within Nexus are expected to be structured around subsystems.
While not clearly stated within the guide, the framework nevertheless contains this guidance:
To the extent that requirements, team members’ knowledge, and code/test artifacts are mapped to the same Scrum Teams, dependency between teams can be reduced.
When software development using Scrum is scaled, these dependencies of requirements, domain knowledge, and software/test artifacts should drive team organization.
Remember, Nexus is all about integration, not adding more resources to the same set of tasks. Structuring your Scrum Teams around feature sets or subsystems that need to be integrated, with an eye towards minimizing cross-team dependencies, is the ideal.
The Nexus framework requires the Nexus Integration Team to refine the Product Backlog to eliminate or minimize dependencies between teams.
The Product Backlog needs to be decomposed so that dependencies are identified and removed or minimized. Product Backlog items are refined into thinly sliced pieces of functionality and the team likely to do the work should be identified as early as possible...Only when the Product Backlog items are adequately independent can they be selected and worked on without excessive conflict between Scrum Teams in a Nexus.
This isn't really about assigning work to teams. Rather, it is supporting the notion that the teams should work on loosely-coupled areas that are integrated daily within the Nexus. This is much easier to do when teams are formed around feature sets or subsystems.
The Product Backlog in Nexus is not intended to be addressed in strictly linear order.
Instead of a strictly linear or sequential order, a Nexus Product Backlog is intended to carry additional information to guide selection of items during Nexus Sprint Planning. Consider the following statements:
As the Product Backlog items are refined and made ready, indicators of which team will do the work inside a Sprint are made visual.
Product Backlog items are refined into thinly sliced pieces of functionality and the team likely to do the work should be identified as early as possible.
The first part of cross-team Refinement should be spent decomposing Product Backlog items into enough detail in order to understand which teams might deliver them, and in what sequence over upcoming Sprints.
During Nexus Sprint Planning, each team selects work for the Nexus in a Scrum-like way, but teams should be selecting the topmost backlog items that support their specific Sprint Goal within the overarching Nexus Sprint Goal. Any additional refinement or reordering can be done by the Product Owner on the fly, if needed.
By ensuring that your Scrum Teams are cross-functional but as loosely-coupled as possible with other teams, you are more likely to achieve scale. Your use of the Product Backlog must support this organizational structure, and be optimized for cross-team refinement and integration.
Add Missing Integration Stories to the Product Backlog
The goal of Nexus is to scale Scrum for integration between subsystems. If your process or toolchain doesn't support integration, then you need to iterate until it does.
The role of the Nexus Integration Team is to identify what needs to be done to facilitate integration. If integration is difficult because you lack the tools or infrastructure to integrate properly, then the Nexus Integration Team should work with the Scrum Teams and the Product Owner to create and prioritize integration items on the Product Backlog.
This isn't just an ideal; it's actually a requirement of the Nexus framework. The guide specifically says:
The Nexus Integration Team takes ownership of any integration issues. It is accountable for successful integration of all work by all Scrum Teams in a Nexus. Integration includes resolving any technical and non-technical cross-team constraints that may impede a Nexus’ ability to deliver a constantly Integrated Increment.
If the Product Owner or the stakeholders won't allow integration to be prioritized, the Nexus implementation will probably fail. Treating Nexus as a way to scale resources without addressing integration misses the entire point of the framework.