This chapter is from the book
This chapter is from the book
This chapter is from the book
Nexus Events
Nexus adds four events to Scrum, and replaces one Scrum event, to help Scrum Teams divide and coordinate work across teams in the most effective manner.2 The events defined by Nexus are
Refinement is a formal event for the Nexus to collaborate on the details of the Product Backlog Items (PBIs) and see that they are adequately independent, so that the teams can select and work on without excessive conflict. In the process of working out the dependencies, teams also work out which backlog items they will likely work on. The Nexus continually refines the Product Backlog, as needed, and there is no specific time box for refinement.
Nexus Sprint Planning helps the teams in the Nexus to collectively agree on the Nexus Goal and how each team will contribute to it.
The Nexus Daily Scrum helps the Nexus to make integration issues transparent so that the Scrum Teams can know who is responsible for fixing them. It is a daily opportunity for the teams in the Nexus to sync with one another.
The Nexus Sprint Review enables the Nexus to gather feedback on the Integrated Increment. It replaces individual Scrum Team Sprint Reviews.
The Nexus Sprint Retrospective helps the teams share experiences and coordinate their resolution of shared challenges.
Refinement
In Scrum, Product Backlog refinement is not a mandatory event, but it is a strongly recommended practice. In Nexus, refinement is essential; it helps Scrum Teams work together to determine which team will deliver specific PBIs and to identify cross-dependencies across teams. Refinement is a cross-team event, with as many Scrum Team members present as is necessary to understand and decompose the PBIs.
Refinement results in a Product Backlog that is granular enough for Scrum Teams to pull work without creating unmanageable dependencies. During Refinement, the Scrum Teams should focus on these questions.
What work will each team pull?
In what order does that work need to be done to deliver the greatest business value earliest, while minimizing risk and complexity?
Nexus Sprint Planning
The Nexus takes the refined Product Backlog as input for the Nexus Sprint Planning event (see Figure 2-4). Nexus Sprint Planning helps to synchronize the activities of the Scrum Teams in a Nexus for a single Sprint.
)
Figure 2-4 Nexus Sprint Planning
Nexus Sprint Planning consists of:
Validating the Product Backlog. The Scrum Teams review the PBIs and make any necessary adjustments needed to the work from the Refinement event. All of the Scrum Teams should participate and contribute to minimize communication issues; however, only the appropriate representatives (those who feel that they can make a contribution to refining the PBIs) from each of the Scrum Teams need to attend.
Formulating the Nexus Goal. The Nexus Goal is a Sprint objective that is met through the implementation of PBIs by multiple teams.
Scrum Team Sprint Planning. Once the Nexus Goal for the Sprint is understood, each Scrum Team will conduct its individual Sprint Planning events in which the members create their own Sprint Backlogs. As they identify dependencies with other teams, they work with those teams to minimize or eliminate the dependencies.
In some cases, this will mean that the sequence of work across teams may have to be adjusted to let one team finish its work before another starts.
This could be accomplished by breaking apart dependent work so that some parts can be worked independently, or by one team choosing non-dependent PBIs to work on, to avoid waste resulting from unresolved cross-team dependencies. Teams may also work together to shift work from one team to another to better balance the work. The NIT will help to make sure that dependencies are communicated and visualized on the Nexus Sprint Backlog.
Nexus Sprint Planning is complete when each Scrum Team in the Nexus has finished its individual Sprint Planning events.
The Nexus Daily Scrum
The Nexus Daily Scrum brings together the appropriate representatives from individual Scrum Teams to inspect the current state of the Integrated Increment and to identify integration issues or newly discovered cross-team dependencies. Topics typically discussed include the following.
Was the previous day’s work successfully integrated, and if not, why?
Have any new dependencies been identified?
What information needs to be shared across teams in the Nexus?
During the Nexus Daily Scrum and throughout the day, the Nexus Sprint Backlog may be updated by the Scrum Teams to visualize and manage current inter-team dependencies. It is not simply an aggregation of the individual teams’ Sprint Backlogs, since each team will have work for itself as well as the Product Backlog work that it needs to do. Work that is identified during the Nexus Daily Scrum is then taken back to individual Scrum Teams for planning inside their Daily Scrum events.
The Nexus Sprint Review
The Nexus Sprint Review replaces individual Scrum Team Sprint Reviews and is held at the end of the Sprint. Its purpose is to capture feedback from stakeholders on the entire Integrated Increment of the Nexus. The Nexus Sprint Review replaces the individual Scrum Team Sprint Reviews because individual Scrum Teams might not produce a meaningful Integrated Increment on their own when Nexus is used.
There are several benefits to having a single Sprint Review for the Nexus, including the following.
Teams are logically each other’s stakeholders, so they can provide one another with feedback that helps the Nexus improve.
If individual Scrum Team Sprint Reviews were held, stakeholders may not be able to attend all of them, and even if they did they would not see the integrated Product.
Some issues only become evident when the integrated Product is reviewed as a whole, especially when each team is developing one or more components. Each component may work in isolation, but they may not work together to produce an integrated Product.
Reviewing the Integrated Increment as a whole brings all the teams in the Nexus together and reminds them that their goal is a single integrated solution.
Even when some teams may actually deliver logically separated subproducts that may be independently reviewed, shipped, and used, there is value in reviewing them in the context of the Nexus’ integrated Product Increment.
All members of the Nexus participate in the Nexus Sprint Review.
The Nexus Sprint Retrospective
The Nexus Sprint Retrospective provides the means by which the Nexus enables inspection and adaptation. To conduct the Nexus Retrospective:
Representatives from across the Nexus meet and identify issues that have impeded more than a single team to make shared issues transparent to all Scrum Teams. The representatives consist of the NIT members, as well as anyone with an interest in sharing their perspectives on inter-team issues.
Each Scrum Team holds its own Sprint Retrospective, just as they would do in Scrum, but the team also considers issues raised from the first part of the Nexus Retrospective as input to its team discussions while the members determine actions to address these issues.
Representatives from the Scrum Teams meet once again to discuss common issues identified in the Scrum Team Retrospectives. They agree on how to visualize and track the identified actions that will enable the Nexus to learn and adapt as a whole.
Questions to Ask in Every Nexus Sprint Retrospective
Nearly every Nexus encounters common scaling challenges. Questions that help teams to identify challenges include the following.
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?
When challenges are identified, ask the following:
Why did this happen?
How can technical debt be undone?
How can the recurrence be prevented?
Nexus Events are described in more detail in Chapter 5, “Nexus in Action.”