Scaling Scrum with Nexus
Scrum is primarily defined for one team, with a maximum of 9 members. When more than one team is required, the system is called Scaled Scrum.
There are different ways of scaling Scrum. Unfortunately, most of them are focused on generic advice, not clearly defined, or are just too complex.
Scrum.org has recently released their own framework for scaling Scrum, called Nexus. It’s explained in a short 11 page guide. In my opinion, it’s the best option, because:
- It’s simple, and straightforward. It seems like many forget that Scrum is supposed to be simple. I sometimes even suspect they make it too complex to impress the audience.
- It’s practical, and the defining guide is really a definition rather than a set of generic advice. This is, unfortunately, very common nowadays for authors to just provide vogue, generic advice when they are talking about Agile. Many even believe that Agile is nothing but that; while its core should be a framework/methodology. Scrum.org supports this basic need in a great way.
Let’s take a quick look at Nexus.
There can be 3 to 9 teams in this framework. Each team consists of 3 to 9 developers, and therefore, the maximum number of developers supported here is about 80.
Note: the term “developer” refers not only to programmers, but also anyone else who has a part in the production of the solution, including, but not limited to designers, analysts, and testers.
Each team still needs a Scrum Master, and since this role is not necessarily full-time, one person can be the Scrum Master for more than one team. However, not more than one Scrum Master would be assigned to one team.
Product Owners? No, there’s no Product Owners in each team. One project has only one Product Backlog and one Product Owner, to minimize complexity, and ensure that prioritization is done properly.
Each team produces its own “Done” output during each Sprint. The outputs create one “Integrated Increment” for the whole project, and this is what the supplier demonstrates to the customer for feedback and adaptation.
The Nexus Integration Team
There’s a new “integration” layer added to the framework to ensure that an Integrated Increment is created at the end of each Sprint.
There’s a “Nexus Integration Team” in this layer to:
- Coach, and
This team consists of one or more ream members, who can be dedicated to this job, or also be a developer in a development team. There’s a Scrum Master assigned to this team, who’s expected to be expert enough in Scaled Scrum.
This is also where the Product Owner is placed. Remember, there’s only one Product Owner in this framework.
This is how events are handled in this framework:
- Sprint – all teams start and finish their Sprints in the same time.
- Sprint Planning – it is done in two steps:
- Nexus Sprint Planning – teams coordinate to select items from the Product Backlog and assign them to their teams. The items will be captured on a Nexus Sprint Backlog.
- Local Sprint Planning – then members of each team get together to create their own Sprint Backlog based on the selected items.
- Daily Scrum – it is done in two steps:
- Nexus Daily Scrum – first representatives from all teams get together to discuss the dependencies and impediments related to the scaled way of working.
- Local Daily Scrum – then the representatives go back to their teams, bringing the information from the integrated daily standup, and conduct their own Daily Scrum.
- Sprint Review – there’s no local Sprint Reviews; only an integrated Nexus Sprint Review, which demonstrates the Integrated Increment to the customer, and receives feedback.
- Sprint Retrospective – there are three steps here:
- First, representatives from all teams get together to discuss what happened during the Sprint, with a focus on integration and improvements related to the scaled way of working.
- Then, they go back to their teams and discuss the information from the integrated meeting, along with their inside issues and ideas for improvement. They come up with plans for improvement.
- Finally, the representatives go back to the integrated meeting to share their improvement plans.
Is that all?!
Almost. Remember that it’s a framework: the minimum structure you need to increase your chances of success. You have to add tools and techniques to apply it to your projects.
This is not everything you need, but is the most important part of it.