Nexus Explanation — Scaling Scrum
I have pulled this article together from various sources, as a good reference to go through when starting to look into the Nexus as a way of Scaling Scrum.
Start with Scrum
Having some working knowledge of Scrum and having read the current Scrum guide will be helpful in order to explore the Nexus scaled Scrum framework.
Scrum.org created the Nexus to help identify and minimise dependencies, which become increasingly more abundant and critical at scale. Their guiding principle when creating the Nexus, is that scaled Scrum is still Scrum.
When a single team works on a single product, we only need to use Scrum — This is exactly what Scrum was intended for.
Adding it a second team not become a scaling situation. As the two Scrum teams can coordinate easily enough throughout the day handling any dependencies, duplications or other issues that might arise when those one or two teams are working on multiple products.
It can be painful, but common in many organisations that have more products than they do teams. Increasing the number of teams working on these multiple products, this becomes portfolio management.
This is where management spends their time selecting and optimising the people in the teams for these various product development efforts. This still is not scaling. When we have three or more Scrum teams working on a single product. This is scaled Scrum, It brings about a unique set of problems, which is what the next scaled Scrum framework addresses.
Working from a single product backlog. Working in a single domain, things are complex, but still manageable. When we talk about domain, it really means a swamp, which is how most teams would describe their code base their tests or lack thereof, their tools, their automation, or lack thereof, etc, etc.
When scaling, there is inevitably a cloud of general inefficiency or waste due to handoffs, coordination, integration, rework, and even undone work and technical debt.
It means that every sprint the team will need to spend a portion of its time managing and organising work, resolving dependencies and working around this gunk, which is time not spent innovating with three Scrum teams still working from a single product backlog and in the similar swamp, the inefficiency in waste due to dependencies growth and an alarming nonlinear rate.
In other words, a lot less time is available for product innovation. With nine Scrum teams Still working from a single product backlog and in a similar swamp. The inefficiency in waste due to the dependencies is almost suffocating without deliberate action.
These teams with their 40 to 80 individuals will spend most of their time each sprint just staying out of each other’s way, product innovation will suffer quality issues and technical debt will skyrocket. Before management decides to add another team, they really need to ask how much more value will be gained by doing so that the goal of the next scaled Scrum framework is to scale the delivery of measurable business value as uniformly as possible. So those your costs go up by adding more people productivity should rise as close to the same rate as possible.
The Nexus is a framework for developing and sustaining scaled product and software delivery initiatives. It uses Scrum as its building block. Much like Scrum. The framework consists of roles, events and artefacts as well as the rules that bind them all together.
If you’re familiar with the scrum diagram, then you can’t help but notice the similarities here. All the roles, events and artefacts are the same, but you probably noticed some additions as well.
Backlog Refinement
In Scrum product backlog refinement is optional, but in the Nexus it becomes an event which means it’s required the number frequency, duration and attendance of the product backlog refinement is based on the dependencies and uncertainty inherent in the product backlog.
Sprint Planning
The purpose of Nexus sprint planning is to coordinate the activities of all Scrum teams in a Nexus for the current sprint. The product owner provides domain knowledge and guide selection and priority decisions.
The Product Backlog should be adequately refined with dependencies identified and remove or minimise prior to this event. During Nexus sprint planning the appropriate representatives of each of the scrum teams validate and make adjustments to the ordering of the work as created during those prior refinement events.
Next sprint planning is complete when each scrum team has finished their individual sprint planning events. A next sprint backlog is simply the composite of all the product backlog items from all the individual Scrum teams sprint backlogs. It’s used to highlight dependencies and flow of work during the sprint. It’s updated at least daily, often as part of the Nexus daily Scrum.
Nexus Daily Scrum
This is an event where the appropriate representatives from the individual development teams inspect the current state of the integrated increment and identify any integration issues or newly discovered cross team dependencies or impacts the development teams use the Nexus daily Scrum to inspect progress towards the next sprint goal. The individual Scrum teams then take back those issues and then he worked with identified during the Nexus daily Scrum to their individual Scrum teams for planning inside their individual daily Scrum events.
Sprint Review
The nexus sprint review is held at the end of the sprint to provide feedback on the integrated increment that the Nexus has built over that sprint and to adapt the product backlog is needed. The next sprint review replaces individual scrum team sprint reviews because the entire integrated increment is the focus for capturing feedback from stakeholders.
Retrospective(s)
The Nexus Sprint Retrospective is a formal opportunity for a Nexus to inspect and adapt itself and create a plan for improvements to be enacted during the next sprint. This ensures continuous improvement. The Nexus Sprint Retrospective consists of three parts. The first part is an opportunity for appropriate representatives from each scrum team to meet and make issues transparent to other teams. The second part consists of each scrum team holding their own Sprint Retrospective as describing the scrum framework. The individual Scrum teams should form any actions to address the shared issues.
The third part is an opportunity for Team representatives to come together again and agree on how to visualise and track the identified actions. This allows the next as a whole to adapt and improve. Now let’s take a look at a new role in the Nexus While the scrum team is responsible for delivering done incremental potentially releasable products. It’s the Nexus integration team that’s accountable for ensuring that a done integrated increment is produced at least once every sprint.
So What does that mean? Well, integration includes resolving any technical or non technical cross team constraints that may impede the Nexus his ability to deliver a constantly integrated increment. Now that doesn’t mean that the next integration team does the work. It’s similar to the way a scrum master should coach and mentor and facilitate a scrum team to resolve their own impediments rather than doing the work for them.
We’ve defined what scaling is and what it isn’t. Hopefully This helps you understand whether or not you are in a scaling situation in your organisation. As more teams and individuals are added, dependencies and integration issues become more abundant and can lead to waste if not managed, Nexus was created to raise the transparency of these dependencies and offer additional roles, events and artefacts to mitigate them. And next this is still Scrum. So don’t cast aside anything you’ve learned about Scrum through experience or reading the scrum guide, because it all still applies.
So If you find yourself in an organisation struggling to sequence the work across teams, suffering dependencies and suffering integration issues, considered the scaling First, remove the complexity and cost of the additional individuals and teams until you can maximise the business value being delivered. If you still need to scale consider the Nexus framework. I hope this lesson has helped explain to you what the Nexus framework is, why we created it and how it can help the organisation deliver business value in the form of working software.
