What is Scrum At Scale (or SAFe or Scrum Nexus)?

Scrum at Scale is complicated. I mean really complicated. It sometimes is referred to as Scrum Nexus, sometimes Scrum of Scrums and sometimes scaled agile framework (or SAFe). Essentially, they’re variations on the same theme – working a complex problem with more than one scrum team in parallel.

Scrum at scale (SAFe, Scrum Nexus or Scrum of Scrums) has 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.

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.

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 that product owner. It’s the same person as the scrum teams’ product owner. So the nexus, and each scrum team has one product owner, and it’s the same person.

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 they are 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. It’s far more difficult for the product owner, but leveraging the nexus structure can help put it all into a doable package of work.

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.

So sprint planning is first done at the nexus level, with representatives of each scrum team. Then, these representatives take the results of what they’ve decided to do back to the team, and they do sprint planning based on this. It’s more time consuming, but it ensures that the teams are aligned with what the nexus needs doing.

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.

You can have separate sprint reviews, but the combined nexus sprint review with all teams presenting makes more sense. It’s an excellent coordination exercise, and those stakeholders invited see the nexus move forward, rather than just one team or another. It’s a key tool in ensuring that the scrum teams aren’t siloed off by themselves, and not taking in the nuances of how they and their product interact with the other teams.

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.

Here, it’s advisable that the scrum teams each have their own retrospective after the nexus one. The smaller audience and the intimate group of just the scrum team ensures that you can get the most value from the retrospective. So which retrospective does the product owner attend? They definitely want to be in the nexus retrospective, but after that, it’s up to the product owner. Choose the team that needs the most input from the product owner, or choose none and let them discuss amongst themselves. Both are valid options.

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 or scrum of scrums. 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.

Should Teams Align Their Scrums?

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 the work is even harder. But if you’re going that route, don’t invent your own wheel. Learn from others and follow their best practices.

Scrumalliance.Org doesn’t offer a scaled scrum certification, but Scrum.Org does: