Before we go into the details, a word of warning in regards to scaling. No matter what framework you use, scaling always introduces overhead and complexity. This goes double for anything that is broken. If your current team has problems delivering a Done product increment, these problems will not magically go away when scaling; they will hurt even more. Make sure your processes, practices, and any automated flows are working for one team before adding more teams. Otherwise, you will quickly get stuck. At scale...

Also, there are different types of scaling problems that require different types of solutions. Make sure your solution addresses your problem.

Scaling:

Scaling Type - One Product - Multiple Products Multiple teams - Nexus - Portfolio management (with Scrum/Nexus) One team - Scrum - Kanban (warning – chaos) In this case, we will look at scaling Scrum using Nexus on multiple teams working on a single product.

Short introduction of the Nexus framework

If you know Scrum, this should look very familiar to you. Unlike some other frameworks, when you scale Scrum using Nexus, Scrum is still Scrum. What you get with the Nexus framework are a few additions to Scrum to handle cross-team dependencies, issues, and improvement opportunities to ensure teams can deliver an integrated increment each sprint.

Scale Scrum using Nexus and Azure DevOps

The neat thing with Nexus is that it requires NO CHANGE to our process template in Azure DevOps because we are still doing Scrum! The new role, events, and the Nexus Goal do not need to be modeled into our process template, and the Nexus Sprint Backlog is just an aggregated view of all the individual team Sprint Backlogs. So, the only thing we need to do is to set up our teams so they can have one common aggregated "view of everything" and their own filtered team views. Which is basically what everyone wants for any multi-team effort and is supported out of the box by Azure DevOps.

In a scenario where we have one team working on "ProductX" in Azure DevOps, this is what we need to do in order to scale to multiple teams working in a Nexus:

Go into Project settings and rename your existing team to "Nexus." Select the Area Path root as Default area for this team and set "sub-areas are included." Create a new team for each of the Scrum teams working on ProductX. Let the wizard create a Team area for each team (default choice). For each new team, go to Team configuration and select the same iterations as for the "Nexus" team. And we are done!

For "anything Nexus" like Nexus Sprint Planning and Nexus Sprint Backlog, we use the view of Nexus team. For team-specific stuff, we use the individual team views just like we did when there was only one team.

Why not a dedicated team for the Nexus Integration Team?

This is what the Nexus Guide says about the Nexus Integration Team: The Nexus Integration Team is accountable for ensuring that a "Done" Integrated Increment (the combined work completed by a Nexus) is produced at least once every Sprint. The Scrum Teams are responsible for delivering "Done" Increments of potentially releasable products, as prescribed in Scrum. Members of the Nexus Integration Team are often also members of the individual Scrum Teams in that Nexus. Common activities the Nexus Integration Team might perform include coaching, consulting, and highlighting awareness of dependencies and cross-team issues. It might also perform work from the Product Backlog.

So when trying to scale Scrum using Nexus, the Nexus Integration Team is a sort of semi-virtual team with a "servant leader" flavor. Even though the last sentence says it might perform work from the backlog, it should be rare and more of an emergency action than anything else. All in all, we are much better served by an aggregated "Nexus view" where we can get an overview of the current situation.

Further improvements

There are a lot of things we can do to make our life while trying to scale Scrum using Nexus just a little bit easier on a day-to-day basis. Here are a few short advices:

Use the predecessor/successor work item links to indicate dependencies. Check out various Azure DevOps extensions that might help us, here are a few suggestions: Work Item Visualization for visualizing dependencies. Feature timeline and Epic Roadmap also for visualizing dependencies. Dependency Tracker for tracking cross-team dependencies. Definition of Done to ensure all teams adhere to a common DoD.