One of the attempts to provide a framework to help agility grow and blossom beyond a single team level, is Nexus. Nexus’s rationale is Scaled Professional Scrum. Nexus and Scaled Professional Scrum were collaboratively developed by Ken Schwaber, David Dame, Richard Hundhausen, Patricia Kong, Rob Maher, Steve Porter, Christina Schwaber, and Gunther Verheyen at Scrum.org. Nexus is positioned as the exoskeleton of Scrum. A nexus is a unit of development (in Scaled Professional Scrum).
What is Nexus?
Nexus is a framework consisting of roles, events, artifacts, and techniques that bind and weave together the work of approximately three to nine Scrum Teams working on a single Product Backlog to build an Integrated Increment that meets a goal. It uses Scrum as its building block. The Nexus Guide (free downloadable PDF) contains the definition of Nexus, consisting of:
- artifacts, and
- rules that bind them together
A Nexus consists of a Nexus Integration Team and approximately three to nine Scrum Teams.
The Nexus Integration Team is a Scrum Team that consists of:
● The Product Owner
● A Scrum Master
● One or more Nexus Integration Team Members
Every day the Nexus Integration Team and representatives from the Scrum Teams will have their Nexus Daily Scrum to discuss integration issues, dependencies and sharing information across the teams. Joined to this Nexus Daily Scrum the individual Scrum Teams will have their own Daily Scrums. The Scrum Teams will develop their parts and integrate and test their work with that of the other teams.
At the end of the sprint, we have the Nexus Sprint Review demonstrating, showing the Integrated Increment. This is a joined review with all team and replaces the individual Scrum Team Reviews. An overall Nexus Sprint Retrospective focusses on inspection and adaption and consists of three parts:
- An identification of issues impacting more than one Scrum Team.
- The individual Scrum Team Retrospectives.
- Actions to be taken.
Lacking practical hands-on guidance
Unfortunately, the Nexus Guide is superficial as soon as it becomes practical. Under Software practices: “Many software development practices are needed to bind the work of the Scrum Teams collaborating to create an Integrated Increment. Most of these practices require automation. The automation helps manage the volume and complexity of the work and artifacts especially in scaled environments”
At Transparency: “Software must be developed so that dependencies are detected and resolved before technical debt becomes unacceptable. The test of unacceptable technical debt is when integration occurs, and it remains unclear that all dependencies are resolved. In these cases, the unresolved dependencies remain hidden in the code and test base, lowering the overall value of the software.”
In other words, there’s no attention to:
- team formation;
- long term planning, despite an overview of sprints, while refining the product backlog;
- preparation of starting to work with Scrum;
- embedding an increment in the organization.
Scaled Agile Framework (SAFe) versus Nexus
My Capgemini colleagueexplains in Dutch the differences between Scaled Agile Framework (SAFe) and Nexus.