As more and more organizations embrace agile ways of working there is a steady increase in the desire to “scale agile”. There are a number of scaling frameworks available for us to choose from or get inspired by. The Nexus framework (created by Scrum creator Ken Schwaber and Scrum.org) is one such framework. If you haven’t heard about Nexus I strongly suggest you have a look. It is a lightweight framework that “drives to the heart of scaling by minimizing cross-team dependencies and integration issues”.
In this post we will look at how to scale scrum using Nexus on the Azure DevOps cloud plattform. We will start with a single scrum team working on ProductX in Azure DevOps and transition that setup into multiple scrum teams using the Nexus framework to coordinate their work. Our focus is specifically what we need to do in Azure DevOps to support this way of working. Spoiler – it is super easy!
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 have 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||One Product||Multiple Products|
|Multiple teams||Nexus||Portfolio mgmt
(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. Without going deeper into the Nexus framework this is what we add to the mix:
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 modelled 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” flavour. 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.
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.
Want to learn more about the Nexus framework?
Sign up for my Scaled Professional Scrum class in Stockholm 2-3 April.