One of the trending buzz-words within agile software development is “scaling”. This has been discovered by the gurus within agile processes and we currently see heaps of frameworks popping up. Each of these frameworks pose a solution to scaling work across several teams. But what does scaling actually mean and how can we use a framework like Nexus to handle dependencies?

A key effect from agile transformations is that organizations start focusing on having stable teams that are high performing and works off an independent backlog. They strive to do Scrum “by the book” to take a step into being more agile.

This effect is vital, and we should work on persisting it even en scenarios with multiple teams working together to deliver working software. As such it is crucial to find a framework that does not introduce to much overhead and administration. The feasible price for the overhead is very much depending on context. The larger you scale, the more overhead is accepted. However, as you add overhead you also potentially reduce the empowerment of each individual Scrum team and thus break with the original idea of Scrum.

Nexus exoskeleton

Looking into frameworks for scaling agile – we stumble upon Nexus as one of the up and coming solutions for handling cross team dependencies. The word “nexus” originates from latin and means “the action of binding”. The Nexus exoskeleton for scaled Scum consists of a set of roles, events and artefacts that comes in play when 3-9 teams work together on the same backlog to deliver software striving for a joint goal.

Nexus is in many ways similar to Scrum; it’s easy to learn but hard to master.

Roles

The roles in a Nexus is organized in a so-called Nexus Integration Team. The team is responsible for ensuring that the outcome of the teams is an increment of integrated potential releasable software. Each role has its own responsibility:

• Nexus Product Owner is responsible for maximizing the value of the product and work across all Scrum teams. The role is permanent and full-time for the whole duration.
• Nexus Scrum Master is responsible for ensuring that Nexus is understood and enacted and that the Scrum teams follow the principles of Scrum. The role is permanent and full-time for the whole duration.
• Nexus Integration Team Member is responsible for coaching and guiding teams to discover and handle dependencies. The team members come from the involved Scrum teams and they only participate in the Nexus Integration Team when they have a role in discovering and handling dependencies.

Artefacts

Artefacts are here to ensure transparancy across the involved Scrum team. Combined they ensure that potential releaseable integrated software is created in each increment. The software is developed in a way that focuses on discovering dependencies as early as possible. This is done to reduce the amount of technical debt created in the Scrum teams. To help ensure this a central Definition of Done is created and enforced in all Scrum teams.

There are three main artefacts:

• Nexus Product Backlog is a shared comon backlog covering backlog items for all involved Scrum teams. The content is refined and broken down to a level where dependencies can be discovered and reduced.
• Nexus Goal is a shared comon goal for the coming increment. All backlog items developed by the Scrum teams help to implement the goal – just like a Sprint Goal in Scrum.
• Nexus Integrated Increment is an integrated potential releaseable piece of software from the involved Scrum teams.

Events

Seeing how Nexus builds on top of Scrum there are many similarities in the events. The primary focus in all events is to discover and handle dependencies. This happens through Nexus Sprint Planning, Nexus Daily Scrum, Nexus Sprint Review, Nexus Sprint Retrospective and Nexus Refinement.

• Nexus Sprint Planning a joint planning and coordination event with team members from all Scrum teams. Priority is given to work to enable the delivery of an integrated potential releaseable piece of software after the increment.
• Nexus Daily Scrum is a coordination and follow-up event involving relevant Scrum team members who focus  on handling dependencies.
• Nexus Sprint Review is held to obtain feedback for the collective delivery of software across the Scrum teams.
• Nexus Sprint Retrospective is focusing on both joint and team wise inspection of the Scrum teams and planning of improvements to be executed.
• Nexus Refinement covers the break down of overall themes into epics and stories with as few dependencies as possible. The break down must be detailed enough to that the Scrum teams are able to pull backlog items from the Nexus Product Backlog and into the team.

You can find more information about Nexus on this link: https://www.scrum.org/resources/online-nexus-guide.