By: Ivsen Platcheck, MSC. ENG.

Scrum is one of the most adopted frameworks for agile management processes. Even though, I started to use Scrum techniques and definitions, before taking formal contact with the framework itself, I used much of the principles, pillars, artifacts, and philosophy, when leading project teams. This text is based on my previous experience, rethought under the Scrum lens.

The original Scrum definition deals with a scenery where there is one product and one Scrum team. At small to mid-sized organizations this may be the scenery. One project at a time, small teams. But when dealing with larger organizations, the projects may grow in complexity and require more people to execute. Using the Scrum theory and definitions, a Scrum team is best If it has no more than 10 members.

Then, the Scrum Master has to split the group in more than one team, respecting the size limit, and guarantee that the resulting teams will have all the skills needed to create values, along the sprints.

This mechanic, more than one group, one Product Backlog, and one Product Owner. Most likely to have one Scrum Master. The process has some changes, and this is what we’ll talk about in this text.

I will not write about Scrum theory and practices, for a single group, on a single product. I will focus only on the cycles for the case which there are more than on group, and a single product. A complex product that needs to be dealt by more than one only group, or the timeframe may be too long, and all the project effort be useless, or obsolete.

This approach is called Nexus Scrum, or Scrum@Scale Nexus. Nexus is a framework for developing and sustaining scaled product initiatives. It uses Scrum as its building block.

By definition, Nexus is a framework consisting, basically, with Scrum events, artifacts, and rules, and rules, plus some new ones that bind and weave together the work of approximately three to nine Scrum Teams, working on a single Product Backlog, and with the goal of building integrated increments that meet a goal. [Sk01]

As stated above, Nexus preserves and enhance the Scrum theory, intelligence, and empiricism, while enabling for a group of teams to deliver more value, that can be achieved by a single team. The main goal is to scale the value that the group of Scrum Teams, working on a single product, may be delivered, by reducing the complexity, with the teams collaborating to deliver an integrated, valuable, useful product increment, ideally at least in every Sprint. [SO01]

Due for the fact that more than one team will work on the same Product Backlog, aiming for the same value to be delivered, some difficulties may arise, and the process will change, too, to accommodate them. The most challenge difficulties will rise over the team communication, collocation, dependencies, the necessity to integrate and test their work into a single increment.

The many dependencies that arise between the work of multiple teams, when they are working collaboratively to create an increment that meets the Definition of Done, settled by the whole group, at least once every Sprint.

Most of those dependencies are related to:

1. Requirements: The scope of the requirements may overlap, and the manner in which they are implemented may also affect each other. That knowledge should be considered when prioritizing, ordering, and selecting the Product Backlog items.
2. Domain knowledge: The knowledge should be distributed across the teams, ensuring that each team have all that is needed to perform their work, minimizing interruptions, impediments, and other problems that can delay the work.
3. Software and test artifacts: The requirement should be instantiated in the product.

Nexus provides means and opportunities to change the process, the product structure, and the communication to minimize the dependencies among the teams.

The framework

Nexus is a framework for managing multiple Scrum Teams working together to create an integrated increment. As said before, Nexus brings all the Scrum structures as the Scrum Guide [SS01] states. The difference is that more attention is dedicated to dependencies and interoperation between Scrum Team, in order to deliver at least one done integrated increment, every sprint.

Figure 1 – Nexus® Framework for Scaling Scrum [Sk01]

As showed on Figure 1, Nexus extends Scrum by:

• Accountabilities: The Nexus Integration Team is a new role introduced with the Nexus framework. Its accountability is to coordinate, coach, and supervise the application of Nexus and operation of Scrum, so the best results may be achieved. The Nexus Integration Team consists of the Product Owner, the Scrum Master, and the Nexus Integration Team members.
• Events: New events are appended to, placed around, or replaced regular Scrum events to adapt them. Even when modified, they serve either the individual teams or all Scrum Teams in the Nexus. The Nexus Sprint Goal becomes the objective for the whole Sprint.
• Artifacts: All the Scrum Teams use the same Product Backlog, once it is referred to the project of one product. When the Product Backlog items are ready to be worked, the indicators of which team will mostly like do the work along the Sprint are transparent. There is a Nexus Sprint Backlog to assist with the transparency at the Sprint. The integrated increment is the sum of all integrated work completed by a Nexus.

Accountabilities

Nexus consists of Scrum Teams working together, towards a common Product Goal. The Scrum Guide [SS01] define the three accountability roles, for a Scrum Team: Developers, Product Owner, and Scrum Master. As stated before, Nexus introduces a new accountability, the Nexus Integration Team.

The Nexus Integration Team is responsible for ensuring that an integrated increment, that fulfill the Definition of Done is produced, at least once a Sprint. While the Scrum Teams focus on integration issues within the Nexus, the Nexus Integration Team actually manage the integration for the Nexus.

Integration includes addressing technical and non-technical cross-functional team constraints that can impact the ability to deliver constantly integrated increments.

Product Owner, Scrum Master, and appropriate members from the Scrum Teams integrate the Nexus Integration Team. By appropriate members, it is clear that It refers to those with necessary skills and knowledge to enroll the team and help resolve the issues faced by Nexus, along the process.

The composition of the Nexus Integration Team may change over time to reflect the actual needs. The activities might perform include coaching, consulting, and highlighting dependencies and cross-team issues.

The Nexus Integration Team:

• Product Owner: Nexus works on a single Product Backlog, and following the Scrum Guide rules, there is only one Product Owner accountable for its content. This is the role responsible for maximizing the value and the work performed by the Scrum Team in Nexus. The same as on the Scrum Guide, the Product Owner is the owner of the Product Backlog and should manage it. Even that the Product Owner must only one, some responsibilities may be attributed to other members, but the main accountability will reside on the Product Owner shoulders.
• Scrum Master: This role is responsible for ensuring the Nexus framework is well understood and adopted by the team. The Scrum Master may also be a Scrum Master in one or more Scrum Teams in the Nexus. The practice showed me that one only Scrum Master should be necessary for the whole Nexus. More than one may bring some complexities and impact on the integration process.
• Nexus Integration Team Members: The should be selected Scrum Team members with abilities for helping the Scrum Teams to adopt tools and practices that may lead to achieve the delivery of valuable and useful integrated increments that meet the Definition of Done.

The Nexus integration Team should coach and guide the Scrum Team to acquire, implement, and learn everything that may improve their ability to produce the valuable increment. The integration tasks take precedence over the Scrum Sprint tasks.

Events

Nexus adds or extend the Scrum events. The Nexus events timeboxes follow the same rules as the ones for the Scrum events.

On a Scale or Nexus, it is not the ideal if all the Nexus members to participate and share information or seek for an agreement. Except when there are any special issues, Nexus events should be attended the members needed to achieve the right results.

Sprint

The Sprint in Nexus is exactly the same as it is defined by the Scrum Guide. The Scrum Teams in a Nexus produce integrated increments.

Cross-Team Refinement

The Product Backlog items refinement should be worked by cross-team members. This will allow to reduce or even eliminate the dependencies. The Product Backlog decomposition should turn those dependencies transparent, identified, and removed or minimized.

This process of cross-team refinement helps to:

• It helps the Scrum Teams to forecast which team will work on which items.
• It identifies the dependencies across those teams.

The refinement process is a continuous process, and it occurs as often with the cross-team refinement, in order to optimize the above statements.

Nexus Sprint Planning

The main purpose for this meeting is to coordinate all the Scrum Teams work, within a Nexus, for a single Sprint. Selected Scrum teams members and the Product Owner meet to plan the next Sprint. It is recommended that the Scrum Master participate on the meeting, in order ta facilitate and guarantee that the Nexus will be properly conducted.

As outgoings from the Nexus Sprint Planning: [SO01]

• a Nexus Sprint Goal that aligns with the Product Goal and describes the purpose that will be achieved by the Nexus during the Sprint
• a Sprint Goal for each Scrum Team that aligns with the Nexus Sprint Goal
• a single Nexus Sprint Backlog that represents the work of the Nexus toward the Nexus Sprint Goal and makes cross-team dependencies transparent
• A Sprint Backlog for each Scrum Team, which makes transparent the work they will do in support of the Nexus Sprint Goal

Nexus Daily Scrum

With focus on its purpose, selected Scrum Teams members participate at the Nexus Daily Scrum in order to inspect the current state of the integrated increment, identify issues and newly learned dependencies or impacts. The Scrum Team’s Daily Scrum takes from the Nexus Daily Scrum, to plan their working day, with focus on the integration issues learned.

Nexus Sprint Review

As the Sprint Review, the Nexus Sprint Review happens at the end of the Sprint, to provide feedback on the done increment. In this case, it is the integrated increment that is going to be analyzed to determine future adaptations.

The Nexus Sprint Review replaces the individual Scrum Team Sprint Review, once ion the Nexus, the focus is the entire integrated increment. All the outcomes from the Sprint Review are held by the Nexus Sprint Review.

Nexus Sprint Retrospective

This meeting has the same purpose as the Scrum Sprint Retrospective, to increase the quality, and improve the working process, members interaction, processes, tools, and the Definition of Done. For individual teams improvement, the internal teams, Sprint Retrospective complement this Nexus Sprint Retrospective.

Artifacts and Commitments

Following the Scrum Guide, the artifacts represent work or value, and the ensure maximum transparency.

Beyond the Scrum artifacts already known, Nexus extends them, and each artifact contains a commitment, to reinforce empiricism and the Scrum value for the Nexus and its stakeholders.

Product Backlog

One only Product Backlog holds the list of what is needed to improve the product. At scale, and in this case, Nexus, the Product Backlog should be taken as it is the place where the dependencies can be detected and minimized.

It’s main commitment is the Product Goal, which describes the future state pretended for the product and it is the long-term goal of the Nexus.

Nexus Sprint Backlog

A Nexus Sprint Backlog is the composite of the Nexus Sprint Goal and Product Backlog items from the Sprint Backlogs of the individual Scrum Teams. It highlights dependencies and the Sprint workflow. The Nexus Sprint Backlog is updated throughout the Sprint as more is learned.

Nexus Sprint Goal is the commitment for the Nexus Sprint Backlog. The Nexus Sprint Backlog joins all the teams work and the Sprint Goal. It brings coherence, focus motivating the Scrum Team to work together, in one common initiative.

Integrated Increment

It is the current sum of all integrated work completed by Nexus towards the Product Goal. Even though the integrated increment is inspected and demonstrated at the Nexus Sprint Review, it may be delivered to the stakeholders at the end of the Sprint. The integrated increment must meet the Definition of Done.

The Definition of Done defines the state of the integrated work, when it meets the quality and features required for the product at some point at the development cycle. The increment must be integrates, valuable, and usable, to be declared Done.

The Definition of Done is accounted to the Nexus Integration Team responsibility, and it should be applied to the integrated increment developed along each Sprint cycle. All Scrum Teams must adhere to this Definition of Done. Individual Scrum Teams can, however they feel the need, to apply a more stringent Definition of Done within their own team, but can’t be less rigorous than the Definition of Done stated bye the Nexus Integration Team.

Personal End Notes

The Nexus brings a new perspective for using Scrum at organizations, where the initiatives lead to complex projects, and the need of a tight timeframe to have them ready to the market.

In this text I bring some of my own experiences on projects. The ones I led, and the others I was a team member. I Always tried to find better ways, frameworks, or workflows to increase quality, reduce cost, and deliver products at the right time to fulfill the market and the clients’ needs or wishes.

I didn’t get into more details, in text, about the Scrum theory itself, once, in my point-of-view, if the organization is getting ready to adopt Nexus, its project teams must already have studies and used Scrum. I didn’t feel the need to bring I here, and I just focus on the Nexus differences and extensions.

As I stated above, describing the roles and accountabilities for Nexus, I truly believe, and experienced, that as much as one Product Owner is allowed, once we have one product and one backlog, the Scrum Master should be one.

There may be some delegations of Scrum Master roles to members in individual Scrum Teams, but the accountability should rely on the servant lead Scrum Master.

One Product Owner and one Scrum Master can bring mor coherence, collaboration once they have all the teams under their lead and have all the information required for taking the right decisions among the process.

As I always write, in my posts or articles, I encourage anyone who feels like it, to send comments, positive or negative critiques. Everything I receive, I will analyze and, if I decide to incorporate to this post, I will identify who sends.

I am also available as a contractor to perform the Scrum Master role, in any organization. Mostly remote, preferably.

References

BITTNER, Kurt, KONG< Patricia, and WEST, Dave, “The Nexus® Framework for Scaling Scrum”, Prentice Hall, USA, 2018.

MM01 – “Curso Gestão Ágil 2.0”, Mind Master, 2022.

Sk01 – SHWABER, Ken, “Nexus® Guide – The Definitive Guide to scaling Scrum with Nexus: The Rules of the Game”, Scrum.Org, January 2018.

SO01 – “The Definitive Guide to Scaling Scrum with Nexus”, Scrum.Org, January 2021.

SS01 – SCHWABER, Ken & SUTHERLAND, Jeff, “The Scrum Guide”, Scrum Org, 2020.