When scaling Scrum, we balance cost and effort with benefits and advantages. Costs and effort come from adding teams. Benefits and advantages come from delivering more value in the same amount of time.
Scrum practitioners know that scaling Scrum is more than just a math problem. Common sense tells us that there will inevitably be integration conflicts when teams work together on a single initiative. These conflicts arise from interdependencies. We know that it takes discipline and effort to make dependencies transparent and eliminate them. This effort is put into perspective if an integrated increment can be delivered at the end of each sprint. Only delivery will create value for the organization.
Continuously eliminating dependencies and integrating all work is deliberate practice. It is at the heart of Nexus. At its core, the Nexus framework helps multiple teams continuously integrate their work into a product.
Scrum practitioners will find themselves using the Nexus framework because it extends Scrum only minimally. Organizations that choose to scale Scrum with Nexus are committed to continuously delivering value to their users. They don't waste sprints training employees in new roles, implementing new processes or ways of working, setting up new infrastructure, or waiting to get support from external consultants.
This article provides an overview of the Nexus framework for practitioners who are already familiar with Scrum.
The Nexus Framework Explained
We will discuss the framework step by step and explain how the elements allow us to identify and eliminate dependencies across teams. We assume that the reader knows the Scrum Framework well and therefore we highlight just the elements add to the Scrum Framework.
We start on the left with the Product Backlog.
Working on a product requires a Product Backlog. It is the only source of work carried out by Scrum teams. To make this work transparent, Refinement is a helpful practice in Scrum. In Scaled Scrum, however, Cross-Team Refinement is mandatory.
1. Cross-Team Refinement makes the Product Backlog transparent.
In the Cross-Team Refinement, the Product Backlog is broken down. This is done until it is clear which team pulls the work and whether there are dependencies between the items. This level of transparency is necessary to eliminate dependencies in advance. Forecasts are made to determine which team will most likely work on which Product Backlog item in the upcoming sprints. Cross-Team Refinement simplifies planning for the next Sprints.
Representatives from each Scrum team participate. They are not selected based on their role but situationally based on the work to be refined. How often the representatives meet for cross-team refinement is determined by uncertainty within the Product Backlog. Since refinement is an ongoing process, no timebox is prescribed. Typically, Scrum Teams continue refinement within their teams so that the Product Backlog items are ready for selection in a Nexus Sprint Planning Event.
2. Nexus Sprint Planning coordinates activities for the Sprint.
Nexus Sprint Planning initiates the Sprint. Within this event, the work and all activities necessary for this Sprint are coordinated. Ideally, all members of the Nexus participate in Nexus Sprint Planning.
The event begins with representatives of the Scrum Teams and the Product Owner inspecting the refined Product Backlog and setting a goal for the Sprint.
3. Nexus Sprint Goal enables focus across teams
This goal provides an overarching goal for all teams in a sprint. It helps create coherence and focus for the Nexus. It also encourages Scrum teams, rather than working on separate initiatives, to work together.
The Product Owner introduces the Nexus Sprint Goal to define the purpose of the Sprint. Together, the Scrum Teams select the highest priority Product Backlog items that, when completed, will realize the Nexus Sprint Goal. The ongoing refinement process should have already identified and largely eliminated dependencies for the selected Product Backlog items.
After the initial selection of Product Backlog items, the individual Scrum Teams proceed with their sprint planning.
Nexus Sprint Planning serves as a container for the Sprint Plannings of the individual Scrum Teams. It is completed when a rough plan of achieving the Nexus Sprint Goal and a detailed plan for the first days of the Sprint, has been created. This overarching plan is captured in the Nexus Sprint Backlog.
4. Nexus Sprint Backlog is a real-time picture of dependencies
It consists of the Product Backlog items that the developers in Nexus believe are necessary to achieve the Nexus Sprint goal. This new artifact makes visible all the teams' forecasted work and all the dependencies between them.
The Nexus Sprint Backlog helps coordinate work across team boundaries. For example, if Scrum Team A depends on Scrum Team B to complete a Product Backlog item and Scrum Team A does not make progress in completing it, this would be visible in the Nexus Sprint Backlog.
This backlog allows teams to collaborate during the sprint across teams. It can be seen as the aggregation of the Sprint Backlogs of the Scrum Teams. It helps the Nexus to stay accountable for the dependencies during the Sprint. The Nexus Sprint Backlog represents a real-time picture of the workflow during the Sprint and needs to be updated daily. This update should take place in the Nexus Daily Scrum.
5. Nexus Daily Scrum makes integration issues visible
Developers from the teams and the Nexus Integration Team meet before the Daily Scrums to review progress against the Nexus Sprint Goal. They review the current state of the integrated increment (the work of a Nexus completed together to date) by making transparent any integration issues and new dependencies that have emerged.
Representatives use this information as input to their team's Daily Scrum. The role of the Nexus Integration Team in this is to help teams identify their integration and dependency issues and the need for action at the team level.
Of course, this is not the only time that cross-team communication takes place. The Nexus Daily Scrum represents a minimal opportunity and a shared time to update the Nexus Sprint Backlog.
6. Only an integrated increment creates the necessary transparency for empiricism
A Product Backlog item only fulfills the Definition of Done if it has been fully integrated into the product. Only then is a new increment of the product created. The integration into the product creates the necessary transparency that drives empiricism. A usable increment must be created by the end of the sprint at the latest. Ideally, integration and delivery will occur more frequently.
Integration of work should come before any other work to be done. If there are integration issues, they must be resolved first before other Product Backlog items can be implemented and integrated into the product.
7. Nexus Sprint Review to inspect the integrated increment
The Nexus Sprint Review replaces the Sprint Reviews of the Scrum Teams to provide a holistic view of the outcome of the Sprint. The purpose is to get feedback from stakeholders on the increment and identify product improvements.
Since this can be a large event, the focus should be on high-level results. If there is a need to inspect a detailed output, the Product Owner and stakeholder can review specific parts of the product at any time during the sprint. As with Scrum, the results of the Nexus Sprint Review serve as input to adapt the Product Backlog.
The Sprint Review takes place at the end of a Sprint. Afterward, the Scrum teams have enough information to conduct the Sprint Retrospective.
8. Nexus Sprint Retrospective enables improvement across the Nexus
There are numerous ways to conduct the Nexus Sprint Retrospective. One common way is:
As input to the Scrum Team Retrospectives, representatives identify issues that affect multiple teams. As a follow-up, each Scrum Team conducts its own Sprint Retrospective. The cross-team issues can serve as the basis for this. After the team retrospective, representatives reconvene to visualize the improvements. This helps teams stay accountable for its implementation during the sprint.
Regardless of how a Nexus conducts its Sprint Retrospective, it must remain true to the guiding principle: The Nexus uses bottom-up intelligence to fix problems that hold back the Nexus as a whole.
9. Nexus Integration Team is accountable for the integration
The Nexus Integration Team is the most misunderstood element of the framework. The Nexus Integration Team is not a separate team, nor is it intended to do the integration work.
It focuses on the accountability to integrate the work of each team to create a usable increment consequently. If no one is accountable, this could lead to delays in integration and minimizes transparency. Without this transparency, empirical work is not possible.
Nexus Integration Team members come from Scrum teams. The composition may change over time depending on current integration needs and priorities. Their work on the Nexus Integration Team takes precedence.
The Product Owner and a Scrum Master are permanent members of the team. The remaining members are individuals with the skills and knowledge necessary to solve the Nexus problems.
Rather than solving problems directly, the Nexus Integration Team leverages the skills and knowledge of Scrum Team members to achieve optimal solutions to issues identified. Common activities performed by the Nexus Integration Team include coaching, consulting, and creating awareness of interdependencies and cross-team issues. Only in emergencies do Nexus Integration Team members step in to help teams resolve critical issues.
In summary, the Nexus Integration Team is the focal point for integration.
Nexus extends Scrum and maintains its competitive edge
The Nexus framework extends the Scrum framework to include the Nexus Integration Team, the Nexus Sprint Backlog, Cross-Team Refinement, and the Nexus Daily Scrum.
Nexus thus represents a minimal but sufficient extension to Scrum. This extension enables teams to deliver an integrated Increment at the end of the Sprint. The transparency that results from an integrated increment is the decisive competitive advantage of Nexus. It is the only way that organizations remain able to react to changes at any time.
Want to learn more?
Hopefully, this article was useful for you. The Nexus Framework is one of the many interesting topics that is covered in the Scaled Professional Scrum course. If you’d like to join the Scaled Professional Scrum course, check out my class schedule page for more information.