Use the Nexus Framework to Scale Scrum with Positive Impacts to your Team and Work

Scrum is unarguably the best agile way to improve and bring better performance to your team. In order to oversee new procedures to scale Scrum in project management, Scrum[dot]org has brought the Nexus Framework to sustain products on the scale.

In this article, you will understand what is the Nexus Framework and how you can manage it through Scrum in your team’s projects.

What is Nexus Framework?

Nexus is a simple framework that implements scrum at scale across multiple teams to deliver a single integrated product.

You can use Nexus Framework between 3 to 9 scrum teams that are working in a common development environment and are producing a combination increment every sprint with minimal dependencies.

There’s one product owner who oversees all the teams. Additionally, there’s a Nexus Scrum integration team that consists of a product owner and roles that represent each involved team, regardless of their project.

According to scrum.org, it can be, “whoever needs to be there to make sure that integration actually happens.”

The Nexus is made up of roles, events, artifacts, and rules. In this sense, its intention is to consolidate a kind of “exoskeleton”, which supports the work of approximately three to nine Scrum Teams in a single Product Backlog.

In other words, the ultimate goal is to build an integrated, superior increment that delivers value continuously and incrementally.

The Framework is consistent with Scrum and therefore it will be very natural for those who already work with Scrum to adopt it. Therefore there are many familiarities in its application.

Furthermore, the biggest differences are the multiple teams as well as the integration of jobs to deliver a single integrated product increment.

Roles of the Nexus Framework

The Integration Team

From now on, the Nexus Integration Team is responsible for ensuring that at least one properly Integrated and “ready” increment is produced each Sprint.

Surely members can also work on Scrum teams of the same product, however, priority needs to be given to the work of the Integration Team.
The Integration Team is analogous to that of Scrum composed of:

Product Owner

The Product Owner is very similar to Scrum, in this sense Nexus determines the use of only one Product Product Backlog. Following this path, there will be only one Product Owner who is part of the integration team and who is responsible for the Product Backlog.

Scrum Master

The role of the Scrum Master on the Nexus Integration Team is very similar to that of Scrum. In addition to his original responsibilities, it is up to him to ensure that the framework is understood and applied.

Nexus Integration Team Members

The Nexus Integration Team generally consists of software engineers who specialize in integration. They are responsible for defining the application’s integration architecture.

Moreover, they are also responsible for mentoring and guiding the Scrum Teams on the Nexus so that they acquire, implement and learn these practices and tools.

Nexus Artifacts

Artifacts represent the work or value that provides transparency and opportunities for inspection and adaptation, I briefly present the definition of Nexus artifacts.

Product Backlog

The Product Backlog is very similar to Scrum. The main difference is that dependencies between backlog items in this model must be very clear to allow integration challenges to be overcome.

Nexus Goal

Very similar to the Sprint Goal, the Nexus Goal is formulated during the Sprint planning meeting and it should convey the goal that all teams must envision when completing the Sprint.

Nexus Sprint Backlog

Similar to the Scrum model, the Nexus Sprint Backlog includes all Product Backlog items that each team understood to be feasible to meet within a Sprint. Also, there are dependencies between items from other Sprints Backlogs.

Nexus Events

Nexus events are based on Scrum, and because of that their timeboxes are the same for each corresponding event. Let’s see what the scalable framework presents us with news in the ceremonies.

The Nexus Planning Meeting

The planning meeting is an alignment meeting between teams to coordinate the activities of all Teams for a single Sprint.

In this ceremony, the definition of the goal of the Sprint Nexus is carried out. After this definition, the teams individually hold their Sprint Planning events.

The Nexus Planning Meeting ends when all activities are sequenced and flagged with their respective dependencies and selected for each of the Sprint Backlogs.

Scrum Daily Meeting

In order to self-organize the teams, the daily meeting on Nexus is held only with the participants responsible for integration. In fact, during the meeting, the focus is on the impact of each team on the Integrated Increment.

Consequently, there are three important questions in the daily Scrum meeting:

First, did the team integrate the previous day’s work successfully? If not, why?
Second, what new dependencies did they identify?

Finally, what information do Nexus need to share among teams?
They should share new dependencies or new information in each team’s daily meetings.

Nexus Sprint Review

Sprint Review is similar to Sprint review. At the same time it is a feedback meeting held at the end of the Sprint.

At this meeting, the Nexus present the entire increment they integrated and built throughout the Sprint. In this sense, individual teams’ Sprint revisions end up being unnecessary.

Sprint Retrospective

The Nexus Sprint Retrospective is the opportunity for the team to focus on inspection and adaptation. Firstly, this ceremony aims to identify possible improvements for the team as a whole. Therefore, the second step is the traditional team-segment approach.

General perception of the Nexus

Nexus is a Framework highly compatible with Scrum, very understandable. Nonetheless, Nexus has an intrinsic complexity for its implementation, which is integration management. Therefore, this is one of the main challenges of agile scaling and the Nexus proposal presents itself as a great alternative. Certainly, the market advocates for this, as it is one of the frameworks for agile scaling that is rapidly gaining adherence.

Nexus’s pros and cons

Perhaps you might find Nexus a perfect way to deal with Scrum teams. But do you know if it fits your project? Here are some pros and cons to using Nexus Framework and check out if it is necessary to you:

Nexus PROS:

Nexus is an extension very similar to Scrum. It’s easy to understand and adapt to existing scrum teams and practitioners.
Nexus adds a layer of oversight and guidance, but that layer functions practically identically to a regular scrum – arguably, Nexus is just an extra round of meetings each sprint that must take place before their regular counterparts (e.g. Nexus sprint planning happens before scrum sprint planning).
As framework processes go, not only is Nexus familiar, it’s also lightweight, and flexible. A Nexus project can easily implement the spirit of Nexus oversight while adjusting the practical details to suit its specific needs.

Nexus CONS:

Nexus doesn’t necessarily encompass the whole organization, just those people and teams working on the extended Nexus project. Collaboration or coordination with the wider organization may run into difficulties if not everyone is working on scrum or agile principles.
The Nexus approach limits to a maximum of nine scrum teams, or 100 practitioners per product. I one company, there can be many Nexuses – each for one digital product.
You may have a scrum in your organization but if your scrum teams are not ‘mature’ there is a greater risk of a lack of coordination (if people are still learning or less than comfortable with scrum, Nexus can be a big leap).

Get the best results with GitScrum Scrums!

GitScrum has many Scrum features that will support all your project necessities. Increase your productivity and get instant and efficient results with our Scrums!