Why Scale Scrum with Nexus?

Scrum is a simple framework for delivering products using an empirical approach in which teams deliver value in small increments, inspect the results, and adapt their approach as needed based on feedback. It consists of a small set of events, accountabilities, and artifacts, bound together by practices, and enlivened by values that are the key to making it work.

Nexus builds upon Scrum’s foundation, and its parts will be familiar to those who have used Scrum. It minimally extends the Scrum framework only where absolutely necessary to enable multiple teams to work from a single Product Backlog to build an Integrated Increment that meets a goal.

A Nexus is a group of approximately three to nine Scrum Teams that work together to deliver a single product; it is a connection between people and things. Nexus seeks to preserve and enhance Scrum’s foundational bottom-up intelligence and empiricism while enabling a group of Scrum Teams to deliver more value than can be achieved by a single team. It does this by helping these teams to reduce the complexity created by cross-team dependencies that they encounter as they collaborate to deliver an integrated, valuable, useful product Increment at least once every Sprint.

Scaled Professional Scrum – Nexus

Nexus is an Agile framework that is used in a scaled agile project where there are approximately three to nine Scrum development teams, each made up of five to nine members, and there is one common product backlog used by all of the teams. The Nexus framework is in addition to, and overlays, the existing Scrum Agile framework. It is the “eco-skeleton of Scrum”.

Integration Team

The core of the Nexus framework is the integration team which consists of a Product Owner, ScrumMaster, and one or more members from each team. The purpose of the integration team is to coordinate the work of all the Scrum teams to be sure their completed work intermeshes together and is in harmony and not conflict. The need for an integration team becomes even more essential the larger the number of Scrum teams all working on the same project using the same product backlog.

Process Flow

With Nexus there is a standard product backlog which is refined as best as possible with the goal of finding work a given team can do on its own without dependence on other teams. At the Nexus sprint planning meeting, each team picks out from the product backlog the items they plan to work on during the next sprint. This is done in communication with the other teams. This is again done in order to reduce dependencies. By the meeting’s end a shared product backlog emerges and the overall Nexus goal the teams want to accomplish in the next sprint is determined. There also is an output of a single sprint backlog where all the tasks are tagged to indicate which team is responsible for what.

Once a sprint is underway there are multiple integrations daily in order to immediately identify and resolve coding conflicts. For this to work properly all teams regardless of their physical locations, must integrate at least once daily their completed product into the code base.

Each team, like in Scrum, has a Daily Scrum meeting but in addition, there is a Daily Nexus Scrum meeting (a Scrum of Scrums). Here progress is reported, along with problems, by each team’s representative. The information gleaned from the meeting is then taken back by each representative to his or her team.

There also is a Nexus sprint retrospective meeting after the completion of a sprint where there is a discussion of what needs to change for individual teams, and what is affecting all of the teams that needs to change. If there are no changes to be made the wary assumption is that the project is moving along on time with 100% integration for all code written to date.

Nexus is designed to handle projects with up to 100 people. A new framework called Nexus plus is used for projects that call for over 100 people, perhaps thousands. For very large projects Nexus plus is used where there are multiple 100 person Nexus teams. Nexus plus, which is still in its development stage, is designed to handle the integration of multiple 100 person Nexus teams without creating dependencies.

Conclusion

In summary, being able to produce integrated work is key to the success of Nexus. The state of integration as the work progresses is checked at least once daily, and the data gained serves as input for the Scrum teams re-planning meetings that are held daily. It is the responsibility of the Nexus integration team is to provide all of the Scrum teams with all of the tools, guidelines, support, or anything else they may need in order for them to accomplish successful software integration.