Nexus

Scrum was designed around one team. Keep it to ten or so developers working from one list on one cycle and the rules lock together. Grow the product until there are three or four teams and something odd happens: every team runs Scrum properly and nothing comes out finished.

It showed up as scenes like this one. Three teams each ran a two-week sprint and tried to merge their work on the last day, and the payment screen wouldn't open because the login team had changed how sessions were handled. The demo was the next morning; the fix took four days. Asked about it, all three teams said the same thing — our part was done.

The trouble was that all three were right. Each team's work had finished and merging belonged to nobody. Because it was all saved for the final day, conflicts always surfaced at the moment there was no time left to fix them.

Nexus exists to give merging an owner and to move it earlier. It's a set of extension rules published in 2015 by the people who wrote Scrum, and it leaves the existing roles and events alone, adding only a thin layer that connects teams to each other.

Attach every team to a single product backlog, group the people responsible for merging into one team, and put a representatives' meeting one layer in front of each regular event. The product backlog is one ordered list of what might get built next, and not keeping a separate list per team is where this starts.

1. Form the Nexus Integration Team. It holds one product owner, one Scrum Master, and a few people drawn from the individual teams. It carries a single accountability: that a merged result actually exists when the sprint ends.
2. Before the sprint, the teams walk the backlog together. What gets settled here is sequence and ownership rather than size. If the payment screen needs the auth module, that gets written next to the item and a team is picked to take auth first.
3. Planning happens in two layers. Representatives meet first and write one sentence describing what the teams will produce together this cycle; then each team breaks off to plan its own work.
4. Representatives meet for 15 minutes every day. The question isn't how far along anyone is — it's whether the merged result is broken right now and what new dependencies appeared yesterday. Each team holds its own daily scrum after that.
5. The end-of-cycle review isn't split by team. Instead of three separate demos, everyone looks at one merged thing together.
6. The retrospective is two layers too. Representatives pick the problems that cut across teams, each team works on them in its own retrospective, and the representatives reconvene to decide what changes.

The whole procedure exists to keep merging off the last day. What has to exist at the end of a cycle is not three team results but one usable, merged increment, and there is one definition of done (DoD) for the whole Nexus rather than one per team. If the login team runs tests and the payment team doesn't, the merged product takes the quality of the lower bar.

It fits when there are three to nine teams and those teams are building the same product. The second condition carries more weight than the count. If each team owns a different product there is nothing to merge, and the rules earn their cost only when teams share code and a release.

There's one more prerequisite: each team has to be running Scrum already. All Nexus adds is one integration team and a few meetings in front of existing ones, so if the cycle isn't holding at the single-team level, stacking a layer on top just repeats the same problem at a larger size.

Technical conditions matter as well. A rule that says merge daily does not survive an environment where merging takes half a day. Without automatic builds and tests on every push, the daily meeting turns into a place where people confirm that they still haven't merged.

The limits are clear enough. Past nine teams you have to group several Nexuses together, and at that size most organizations end up also weighing something heavier like SAFe, which specifies planning layers on top. The load on one product owner holding a single list for nine teams stays too. When that person falls behind, teams start keeping their own lists, and the moment the list splits Nexus is a name and nothing else.

"Payments and notifications touch the same table. Let's raise it at the Nexus daily first."

The problem sits between teams and can't be solved inside one, so it goes to the representatives' meeting.

"Let's not split the review by team this time — one demo of the merged build."

The point is to check on the spot that what three teams built actually runs together.

"We only have three teams. Do we need Nexus, or is a representatives' meeting enough?"

A suggestion to start lighter, depending on how often there's anything to merge.

Pagedeck has three engineering teams, covering document editing, sharing and permissions, and billing and admin screens. Because all three change the same app, a change by one team kept breaking another team's screen, so six months ago Mia took over a single list and Theo joined the integration team as his team's representative.

Theo spends 15 minutes with the other two representatives every morning at 9:50. What gets said is short: yesterday's push broke the build, or the permission model changes next week so hook in this week if you need to. Before those 15 minutes existed, the same sentences arrived on the last day of the sprint.

Plenty of people read Nexus as a new framework replacing Scrum. It has its own name and its events carry new names, so it looks like a different method. But the only thing it specifies is the layer between teams; inside each team, ordinary Scrum keeps running. Organizations that take it as a replacement delete their team events and swap in the Nexus ones, and then the daily alignment inside each team disappears and only the representatives know what's going on.

Turning the integration team into a dedicated department is the other one. Merging was supposed to get an owner, so a team that does only that looks like the logical move. But its members are normally people who keep building inside their own teams. Split them out and merging goes back to being somebody else's job, with teams shipping their own parts over the wall. The integration team then becomes the group working late on the last day stitching other people's code together, with nobody present who knows why any of it broke.