Nexus is the exoskeleton of
scaled Scrum

What is Nexus?

Nexus is a framework that drives to the heart of scaling: cross-team dependencies and integration issues.

It is an exoskeleton that rests on top of multiple Scrum Teams who work together to create an Integrated Increment. It builds on the Scrum framework and values.

The result can be an effective development group of up to 100 people. For larger initiatives, there is Nexus+, a unification of more than one Nexus. 

Download The Nexus Guide

https://www.scrum.org/Resources/The-Nexus-Guide/Downloads

-------------------------------------------------------------------------------------------------------------

9 keys to understand the Nexus Integration Team.  By  Jerónimo Palacios 

It’s all about solving dependencies

Nexus is focused is solving the primary source of issues and problems when scaling beyond two Scrum Teams: dependencies. No matter how nvolved your corporate culture is or how well your retrospectives are facilitated, if you join more and more teams working in the same product, you’ll face integration issues. Remember that the goal is deliver a Done Increment, integrated, at the end of the sprint. Thus, is important that someone remains accountable and responsible to deal with integration issues.

The Nexus Integration Team is a role, performed by several people

The Nexus Integration Team is compound by the Scrum Master, the Product Owner and whomever needs to be there to make sure that Integration actually happens to deliver a Done Increment at the end of everyNexus Sprint. That may be proper representatives from the team, a DevOps guy or one member from each Scrum Team.

And still, is a Scrum Team

The Nexus Integration Team behaves as another Scrum Team within the Nexus. While its main focus isIntegration that facilitates a Done Increment that may be inspected during the Sprint Review, it may pull and work other Product Backlog Items that are relevant for producing the Increment.

And yet, its composition may change

Dependencies and integration may vary from Sprint to Sprint. While Scrum Teams are relatively stable, the NIT will change to reflect challenges. Because at the beginning of a Scrum project the focus will be on a DevOps tooling infrastructure and later may be on End-to-end testing, the NIT will inspect and adapt its membership to show those challenges. What will remain stable is the Product Owner and Scrum Master membership.

While being responsible for Integration does not mean that it has to perform integration itself

Imagine having to integrate the work from seven Scrum Teams every sprint. Crazy, huh? The way theNexus Integration Team achieves its goals is not by doing actual work but rather facilitating that integration exists across the different Scrum Teams on the Nexus.

Tooling, tooling, tooling

And the best way to achieve Integration resulting on a Done Increment is tooling. Rather than spending infinite hours figuring out where a problem resides, a smart Nexus Integration Team works on setting up a tooling infrastructure that supports Continuous Integration, Deployment and Delivery, ensure the cohesion of tools across teams the closer the end of the pipeline is.

And Teaching. And Coaching. And Patience

The job of the Nexus Integration Team may be exhausting. Because achieving a Done Increment by doing integration itself is out of the question, the work of the NIT requires prodigious amounts of teaching, coaching and patience, using those core practices already present in Scrum to facilitate Scrum Team’s proper delivery.

This sounds a lot like the Scrum of Scrums

Well, no. There is a lot of common sense on the Scrum of Scrums. It is just a meeting. The Nexus Integration Team addresses the flaws of the Scrum of Scrums creating a role that remains accountable for integration. Have you ever heard that complain: “We don’t have time for DevOps infrastructure”. Well, your NIT does.

And if you think you still haven’t got it

Remember the first time you heard of the Scrum Master? It took a long time until people started to understand what a Scrum Master is. Nowadays, nobody argues the existence and benefit of having aScrum Master managing the Scrum process within the Scrum Teams. Yet it is difficult to explain. Well, in a few years no-one will question the existence of the NIT.

Product Owner

The Product Owner role in LeSS is conceptually the same as in one-team Scrum. However, at scale the focus changes slightly toward keeping an overview and ensuring the maximum return on investment (ROI) in the product.

Scaled Product Owner

It’s common in large-scale product development for different people to pull in different directions and for subgroups to focus on local sub-optimizations. Maintaining one Product Owner with one Product Backlog supports whole-product focus.

In traditional large-scale product groups, there’s a group (often product managers) that focuses outward and a group (usually developers) that focuses inward — and never the twain shall meet. In LeSS, the one Product Owner has lots of free time to focus outward on customers and their priorities while also being able to spend some time looking inwards to the teams. He acts as a connector, bringing teams and customers/users together so the teams become more customer focused.

In contrast with other scaled Scrum approaches, it’s possible in LeSS to effectively scale the Product Owner role with just one person because there are fewer roles and positions, and less complexity.

Prioritization over Clarification

There are two key information flows in Scrum related to the Product Owner: (1) prioritizing (ordering) items in the Product Backlog and (2) clarifying items in the Product Backlog. In the first flow (prioritization), information related to profit drivers, strategic customers, business risks, and other business concerns is sought and analyzed. In the second flow (clarification), information is sought to detail the behavior and qualities of items, the user experience, and other feature design concerns.

A LeSS Product Owner focuses on thinking hard about prioritization but collaborates with the teams on clarification. Further, he encourages and helps the teams enter into a direct conversation with true users and customers for clarification. He acts as a connector, not an intermediary.

Why emphasize direct interaction between teams and customers/users? Reasons include: (1) avoiding information loss from handoffs, (2) fostering co-creation of solutions to real customer problems, and (3) improving motivation and empathy for customers by having developers collaborate with them directly.

It’s worth noting that when the teams do most of the clarification work the Product Owner has more time and energy to focus on the big picture, continuously prioritizing and exploring new and strategic opportunities.