Scrum at Scale is complicated. I mean really complicated. It sometimes is referred to as Scrum Nexus and sometimes Scrum of Scrums. Essentially, they’re variations on the same theme – working a complex problem with more than one scrum team.
I’m most familiar with Scrum Nexus, as described by Scrum.Org. The main relevant points, however, are common to most approaches for doing scrum at scale. Essentially, you have an overarching nexus organization over top of the scrum teams doing the work. Each scrum team is still composed of a scrum master, product owner and three to nine development team members. But on top of that, we now add a Nexus scrum master and possibly one or two Nexus development team members to aid at the Nexus level.
The Product Owner?
What about the Product owner? Isn’t there one at the Nexus level? Yes, indeed there is, but it gets really complicated for the product owner. There is a single product owner for the Nexus, and each of the scrum teams in the Nexus. So that product owner can get spread pretty thin. How can they be at all the teams’ ceremonies (especially if they overlap)? Well, the product owner will have to prioritize where he or she is needed most. But there are also a set of Nexus ceremonies that the Nexus product owner can use to communicate with all teams at once.
Scrum Team Ceremonies
Scrum teams go through four sets of ceremonies throughout a sprint. It starts with Sprint Planning (going through the product backlog and determining what can be pulled into a sprint backlog to be working on in the next sprint). Every day of the sprint requires a 15 minute scrum meeting (the standup, where each member of the team can go through what they did yesterday, what they’re planning to do today, and what’s blocking them – at least that’s one way to do a scrum meeting). At the end of the sprint, you do a Sprint Review (a meeting where the Product Owner and key stakeholders can see what’s been achieved in the sprint, and have a discussion of what they like, don’t like, and what direction we should head from here). Finally, the team sequesters itself and has a Sprint Retrospective (a team-only event where they internally look at what went right, what went wrong and what things can be changed to improve for the next sprint).
Scrum Nexus Ceremonies
In Scrum Nexus, you have the same four ceremonies, but they start at the Nexus level, and then at the team level. Let me explain.
The Nexus Sprint Planning
It’s here that the product owner, Nexus scrum master, and two representatives from each scrum teams’ development team sit down and discuss what each team can do in the next sprint. But from what backlog? There’s only one product backlog in a Nexus, and all teams pull from it. Once decided, and a Nexus level sprint goal is set, the representatives go back to their teams to do their own sprint planning, based on the stories pulled from the Nexus sprint planning.
The Nexus Daily Scrum
Much like the sprint planning, each team sends a representative to the Nexus daily scrum to discuss what’s been accomplished yesterday, what’s to be done today and any blockers. These representatives go back to their teams and participate in the scrum team daily scrum.
The Nexus Sprint Review
I’m sure this is starting to sound familiar – each team sends one or two representatives to a Nexus-level sprint review to show what has been accomplished, and take back any feedback from the product owner and key stakeholders on the work, along with any trends. I’ve seen it where all the sprint teams assemble to do the review, and use a large conference room. That way everyone hears what’s going on, but the representatives are the ones showing the work completed in the sprints. This approach works well, as it allows all the teams to see each others’ work and adjust thinking for the next sprint.
The Nexus Retrospective
Here we go again! Representatives from the scrum teams get together with the Nexus scrum master and product owner to discuss, at a Nexus level, what went right and what can be improved. This is usually kept reasonably short, so that those representatives can return to their teams and have the team-level retrospectives before the sprint closes out.
You can see that the Nexus does add a layer of complexity to the daily and scrum period work. So if you’re thinking of adding the Nexus layer to a body of work, do so with a hard look first. Coordinating the work or dependencies of multiple teams isn’t enough of a reason to use Nexus. The key is the single backlog for all the teams. Scrum at scale (of which Nexus is an example) is designed to have multiple teams tackle one complex problem. Not four related but disparate problems, but one. That’s why you can have one product owner to handle the product backlog – there is only one product backlog.
It’s not technically necessary to align the scrum lengths, start/stop days or ceremonies for scrum at scale, but it helps. It makes it far simpler to do a Nexus sprint review if everyone finished their sprints on the same day. The Scrum Guide (https://scrumguides.org/scrum-guide.html) does not demand this alignment (and it violates each team’s right to self organize under scrum, but many organizations do impose this. Your mileage may vary!
Scrum at scale is hard. It’s hard to get good at scrum in the first place. Adding a layer of scrum of scrums, or Nexus onto it is even harder. But if you’re going that route, don’t invent your own wheel. Learn from others and follow their best practices.
- Scrum.Org’s Scaled Professional Scrum Certification: https://www.scrum.org/scaled-professional-scrum-certification