Nexus was developed by the legendary Ken Schwaber and Scrum.org.
It represents a process framework for organizations that want to scale Scrum across multiple Scrum Teams working toward shippable releases— integrated product increments.
Its main components closely correspond to Scrum roles, events, and artifacts. The main difference, however, is that Nexus emphasizes areas where team dependencies and interoperation arise.
Nexus allows three to nine Scrum Teams to seamlessly integrate their work into increments without adding more complexity than needed.
Above and Beyond Scrum
The Nexus framework is geared toward scaled product and software delivery projects, sometimes even full-fledged agile product management. It aims to merge various moving parts into a well-oiled machine and produce working software on a regular basis. Along the way, Nexus addresses challenges and difficulties that plague complex business environments.
The first thing to note is Scrum forms the foundation level of Nexus. You could say Nexus upholds everything Scrum proclaims, but also goes the extra mile and fine-tunes the parent framework.
The purpose is to facilitate team coordination and integrate their work into increments during each Sprint. There’s a whole range of activities and artifacts that need to fall together in order to meet the Definition of Done (DOD).
Moreover, modern Agile organizations are under pressure to solve cross-team dependencies. These dependencies can relate to requirements, domain knowledge, and software and test artifacts.
For instance, knowledge of tech and business aspects should be shared across the board. This company-wide distribution minimizes the likelihood of bottlenecks and interruptions. On the other hand, requirements may sometimes overlap and cause implementation difficulties.
The main takeaway is that what one team does can affect all other teams. Open and structured communication is of paramount importance here. It prevents productivity-sapping problems like wasted or double work.
Nexus Integration Team
There are a few major changes Nexus introduces.
First off, we have a completely new role, the Nexus Integration Team. It consists of a Scrum Master, Product Owner, and dedicated team members. They are in charge of supervising Nexus implementation, as well as coordination, consulting, and coaching tasks.
The Integration Team addresses any technical and non-technical cross-team constraints and impediments. It coaches all stakeholders on how to grasp and implement various practices, standards, and tools. This process encapsulates both the Nexus application and proper use of Scrum.
Regular Scrum Teams remain self-organizing and have their Product Owners and Scrum Masters. They can decide on the fly to assign their members to specific tasks and activities. The ultimate goal is well-known: to produce market-ready increments of products according to DOD.
Teams strive to do this at least once every Sprint.
The order of priority of items in a Product Backlog changes over time and it becomes clearer which teams should tackle which slice of work. Teams delegate representatives to discuss refinement and appoint items on a granular basis.
The Product Owner has the final say in matters of Product Backlog’s content. This individual is also tasked with maximizing the value of the product.
The main addition is the Nexus Sprint Backlog. Its purpose is to promote more transparency in terms of items and dependencies and spur better collaboration. Ultimately, separate Sprint Goals must match the overarching Nexus Sprint goals.
Secondly, Nexus sees Refinement as an event (Scrum doesn’t). Namely, this is an ongoing process that gradually converts vague guidelines and general requests into actionable tips and concrete tasks. At one point, Refinement should yield sufficiently independent items, which can be worked on by a single team.
This event reduces conflicts, dependencies, and uncertainties.
Furthermore, Scrum events are modified or replaced with new events to better support the scaling endeavor. They entail work of individual teams and alignment of different teams. Their duration is similar to the one defined in the Scrum Guide.
Take the example of Nexus Daily Scrums. During these events, participants inspect current progress and try to discover integration issues. If they succeed at this, they provide each Scrum Team with insights. This leads to additional planning on the part of Teams, which revolves around detected issues.
Moving on, Nexus Sprint Planning harmonizes all activities and sequences of work for a single Sprint. Product Owner presents domain knowledge and talks about Nexus Sprint Goal (the sum of individual Sprint Goals), while team members validate refinement decisions. The Sprint planning continues as long as Scrum Teams need to plan their individual events.
Next off, the Nexus Sprint Review takes place at the end of each Sprint. Scrum Teams and stakeholders analyze feedback on work performed so far and deliberate about possible adjustments. These adjustments can include changes to the Product Backlog.
Finally, the Nexus Sprint Retrospective gathers team representatives in order to weed out remaining shared challenges. After that, all that is left is for teams to hold individual Retrospectives and generate valuable, bottom-up intelligence. This knowledge should set the stage for the following Sprints and ensure continuous improvement.
The event matrix requires utmost transparency as the mainstay of monitoring and optimization. This value has to be anchored in organizational culture, artifacts, and practices. No team or individual should have to work with inaccurate or partial information.
Master the Art of Scaling
Nexus builds on the solid groundwork laid by Scrum methodology.
It’s a highly practical and battle-hardened approach that formalizes dependency removal.
To make it work for your organization, do your homework. Get familiar with the new roles, events, artifacts, and rules. Find a way to bind them together into one functioning framework: foster necessary values and define efficient practices.
This kind of operational overhaul will help you synchronize your teams and decrease the number of dependencies in a common environment. Remember you have to continuously learn, inspect, and adapt in order to solve integration issues.
Let nothing stand in the way of delivering valuable increments.