Defined by Scrum.org, Nexus is a framework that drives to the heart of scaling by minimizing cross-team dependencies and integration issues.
This article is a part of “Different Scaling Frameworks” for Agile
Defined by Scrum.org, Nexus is a framework that drives to the heart of scaling by minimizing cross-team dependencies and integration issues.
At its heart, Nexus seeks to preserve and enhance Scrum’s foundational bottom-up intelligence and empiricism while enabling a group of Scrum Teams to deliver more value than can be achieved by a single team.
It aims to reduce complexity and cross-team dependencies while still giving the teams the flexibility and autonomy to change the way it operates within the Nexus boundaries – Namely some flexibility in the process, product structure, and communication structure.
Teams in Nexus
The Nexus framework defines a Nexus as a group of 3 to 9 scrum teams. Each of these teams has a single product owner and a single product backlog. In order to, handle dependencies, Nexus recommends a “Nexus Integration Team”. Where as for the common requirements, Nexus recommends Cross Team Refinement.
The Nexus Integration Team deals with integration issues that would prevent the Nexus from delivering an integrated product increment. It consists of the product owner, plus a scrum master and members from the development teams.
Cross-Team Refinement is an ongoing activity to identify cross-team dependencies and surface early which team will likely work on an item. Who attends can vary with the items up for refinement.
Roles in Nexus
- The Nexus Integration Team consists of the Product Owner, a Scrum Master, and Nexus Integration Team Members
- Three to Nine Scrum Teams
Workflow in Nexus
- Common Product Backlog Refinement in order to help with : the identification and minimization/removal of dependencies in the Product Backlog
- Nexus Sprint Planning: a review of the Product Backlog by representatives from each Scrum Team
- Development Work: the integration of all work into a shared environment for testing
- Nexus Daily Scrum: daily meetings of representatives from each development team
- Nexus Sprint Review: a meeting at the end of the Sprint to provide feedback on the Integrated Increment built over the sprint
- Nexus Sprint Retrospective: a meeting of representatives from each Scrum Team to identify shared challenges. The Nexus Sprint Retrospective is followed by Individual Sprint Retrospectives
As with any Scrum Framework, Nexus consists of Scrum Teams and their associated components: roles, events, artifacts, and rules.
Events in Nexus:
- Refinement of the Product Backlog. This is a forecast of which team will deliver Product Backlog items and identify dependencies across those teams
- Nexus Sprint Planning: coordination of all activities for all Scrum teams during one Sprint
- Nexus Sprint Goal: an objective for the Sprint
- Nexus Daily Scrum: an inspection of the Integrated Increment’s current state to identify integration issues or cross-team dependencies/cross-team impacts
- Nexus Sprint Review: an event held at the end of the Sprint to provide feedback on the Integrated Increment built over the Sprint
- Nexus Sprint Retrospective: a meeting to inspect the previous Sprint and plan improvements for the next one, ensuring continuous improvement
Nexus is also defines Artifacts, opportunities for inspection and adaptation that are crucial in providing transparency.
Artifacts in Nexus
- Product Backlog: a single Product Backlog for all Nexus Scrum Teams managed by the Product Owner
- Nexus Sprint Backlog: a combination of Product Backlog items from the Sprint Backlogs of the individual Scrum teams
- Integrated Increment: the sum of all integrated work completed by a Nexus, inspected at the Nexus Sprint Review
Advantages of Nexus:
- High level of productivity
- Optimization of all efforts
- Most of the work is done by independent Scrum team. As a Result, more significant number of developers are able to work in a Self Managed way.
- Possibility to detect anomalies in productivity
- Practices to address issues that might appear in large teams