As per my previous post on SAFe, if you have multiple teams working on individual products with minimal dependencies, then I don’t think you should worry about scaling; multiple independent Scrum teams can work harmoniously alongside each other just fine.
However, some organisations believe they need multiple teams working on the same thing. They then start looking for help on how to “scale Scrum”.
For such organisations, where 3 to 9 cross-functional Scrum teams are working together, Ken Schwaber has created Nexus. He says that “Nexus is a framework for developing and sustaining scaled product and software delivery initiatives. It uses Scrum as its building block.”
In short, it’s like Scrum but with added focus on dependencies and how teams work together to achieve a single goal.
Single Product Backlog
If multiple teams are working towards a single unified goal, then it makes sense to have one Product Backlog that all of the Scrum teams use.
The complexity of multiple teams working on the same product is addressed by placing a specific focus on refining the backlog: dependencies are identified and removed or minimised. Backlog items are sliced thinly to minimise dependencies.
Nexus says that refinement continues until work items “are sufficiently independent to be worked on by a single Scrum Team without excessive conflict”. I like this.
How do they plan a Sprint?
This isn’t so good.
There is a Nexus Sprint Planning session which is attended by representatives from each team. These representatives select work items (for one Sprint) for their team.
I think this is a weak point of Nexus because it doesn’t involve the whole team. Who are these representatives and why should they commit the team to certain work items?
On the plus side, Nexus places a strong focus on dependencies, making sure that the individual teams work together where dependencies remain.
I also like that the multiple teams are expected to work together to produce at least one potentially shippable integrated increment each Sprint. That’s at least one combined increment which all teams have contributed to.
The output of the Nexus Sprint Planning is a central Nexus Sprint Backlog: this documents which team has taken on each of the items in the Sprint.
Individual teams then meet to plan their own sprint (speaking to other teams where appropriate). Each team works from their individual Sprint Backlog.
Sounds idealistic. How do you make sure the teams work together?
A core element of Nexus is the Nexus Integration Team which is made up of the Product Owner (the owner of that single Product Backlog), a Scrum Master (who has “overall responsibility for ensuring the Nexus framework is understood and enacted”) and one or more team members from the Scrum teams (to supply whatever skills are needed to ensure that potentially shippable integrated increment gets delivered). It is acknowledged that the people on the Nexus Integration Team may change over time as needs change. However, while they’re on the team, work relating to the Nexus Integration Team takes priority over all other work.
Their job is to coordinate, coach, and supervise the application of Nexus and the operation of Scrum. Kind of like overseers of all the Scrum teams in the Nexus. They are accountable for making sure that at least one potentially shippable integrated increment is produced each sprint; Scrum teams are responsible for delivering the increments.
The Nexus Integration Team is also responsible for creating a definition of “Done” that can be applied to the integrated increments. Before you scream in horror, Nexus makes it clear that individual teams can apply more stringent criteria to their own work, but never less than overall one. That makes sense to me.
There’s a Nexus Daily Scrum where reps from each team meet to identify any integration issues which they then report back to their teams:
- Was the previous day’s work successfully integrated? If not, why not?
- What new dependencies or impacts have been identified?
- What information needs to be shared across teams in the Nexus?
Teams then have their own Daily Scrum.
What happens at the end of the Sprint?
As mentioned, at least one potentially shippable integrated increment should have been created during the Sprint. Therefore, it makes sense to replace individual team Sprint Reviews with a single Sprint Review covering the work of all the Scrum teams in the Nexus.
Scrum teams hold their own Sprint Retrospectives but, in addition, there is also a Nexus Sprint Retrospective where representatives from each team discuss shared challenges and address common scaling dysfunctions, asking questions such as:
- Was any work left undone? Did the Nexus generate technical debt?
- Were all artifacts, particularly code, frequently (as often as every day) successfully integrated?
- Was the software successfully built, tested, and deployed often enough to prevent the overwhelming accumulation of unresolved dependencies?
Conclusion
I’m not a fan of any scaling framework. I believe organisations should focus on finding ways to remove dependencies and break streams of work down so that they can be worked on by single teams. This allows the team to run short development cycles and keep feedback loops short.
My concern is that, by having up to nine teams working on one product or service, this process will be clogged up and slowed down.
But, if you have to have a scaling framework, Nexus is the one I dislike the least so far.
The Definitive Guide to scaling Scrum with Nexus: The Rules of the Game is downloadable for free at scrum.org