Why We Need Nexus
When Ken Schwaber and Jeff Sutherland created Scrum, they did so not to build a process, but to deliver the software they were working on. Scrum emerged from the need to do work in a complex world. Scrum draws on two idea sets, empiricism and empowered / lean teams. Those two ideas are fundamental to being agile and they hold true in teams of three people to teams of teams and organizations as a whole. But at scale those ideas are easy to ‘say’ but very hard to ‘do’. Problems in the areas of planning, dependency management, team organization and application complexity undermine the ability of the organization to both empower the teams and apply an empirical approach. For example, it is hard to deliver done software when you are dependent on components that is being worked on by the other team. And without done software it is very hard to get empirical feedback on that software.
Scaling and staying agile is hard. When I was working at Tasktop, I encountered this as we grew our engineering and support organization. I wrestled with questions like ‘how many Product Owners should we have?’ to ‘where should support reside?’. Questions that the Scrum framework cannot answer because they are so dependent on the situation. I remember asking Ken, my long-time mentor and he would say, ‘the organizational model will fall out of the retrospectives’, ‘your Scrum Masters need to be empowered’, ‘if you have one product you should have one Product Owner’. But ultimately, what he was saying is: Trust in your teams and the Scrum framework and you will solve these problems. Process will emerge, and evolve.
But, in the same way that Scrum provides a few simple rules, when teams are scaling Scrum they need guidance. A few (and no more) rules that help organizations scale teams of teams working in the same domain/product/endeavor. Nexus is a framework that is still Scrum, but provides clarifications that help teams of teams work together. Ken says it much better than I do.
“I designed a defined framework for using many Scrum Teams on a single product or problem. The result is Nexus, an exoskeleton that rests on top of many Scrum Teams. Nexus provides information and management information for guiding their working together.”
Ken Schwaber from the foreward to the Nexus Framework for scaling Scrum by Bittner, Kong and West
Nexus was developed by Ken Schwaber and the Scrum.org Professional Scrum Trainer community based on their experience of using Scrum in the large. Like Scrum it is not a process created by methodologists or academics but instead practical guidance from the wild. The rules are simple, but still like Scrum hard to apply. For example, the importance of one Product Owner and Backlog makes for some tough decisions about leadership versus doing all the work. The Nexus Integration Team (NIT) has been added beyond traditional Scrum to provide clarity around the importance of an integrated increment – an idea that comes from the likes of Continuous Integration/Delivery and Trunk Based development. Refinement is now a mandatory event, which makes sense as the bigger your team the more attention that needs to be applied to planning. But ultimately Nexus is still Scrum providing the bare minimum needed to be empirical and empowering your teams, or in the case of Nexus, teams of teams to effectively deliver value to their customers, and get better in doing it one Sprint at a time. Nexus enables you to scale from the team out.
Scrum Nexus on