Scaling the scrum framework to build complex applications using the Nexus Framework.

Introduction

The scrum framework is a great approach for rapid application development especially when your team is distributed and remote. The framework compounds the speed and efficiency you get from working remotely. When building large complex applications the framework can be scaled in a way that enables you to address cross-team dependencies and integration issues. There are several scaled agile frameworks but in this blog, we will focus on the nexus framework from scrum.org.

When scaling it’s good to maintain simplicity so that you can focus on addressing all the issues that arise from working with multiple teams and a complex product structure. According to the Nexus guide, minimal adjustments are made to the scrum framework to enable multiple teams to collaborate and build an integrated, usable increment.

Team Size and Dynamics

The recommended team size is a group of three to nine scrum teams working together to deliver a single product. There should be a single Product Owner working from a single product backlog, the Product Owner has the final say on the product backlog, and therefore it’s very important to maintain just one per product for clear direction. Each scrum team may have its own scrum master. Each scrum team should have ten or fewer members as guided by the scrum guide. From my experience working with smaller teams enhances speed and efficiency. Over and above the three to nine scrum teams, a core team is usually drawn from the scrum teams known as the Nexus integration team. The purpose of the Nexus integration team is to address cross-team dependencies and ensure that an integrated, done, useful, and valuable increment is released by the end of the sprint.

Roles in the Nexus Integration Team

• Product Owner –  Has the final say on the product backlog. They are accountable for effective backlog management and maximizing the value of the product and work performed.
• Scrum Master – Accountable for ensuring that the nexus framework is understood and implemented as described in the nexus guide, they could also be Scrum Master for one of the teams.
• Nexus integration team members – these could be team members who assist the scrum teams in adopting tools and practices that contribute to the team’s ability to deliver a valuable useful integrated increment that meets the Definition Of Done.

The nexus guide emphasizes that membership in the nexus integration team takes priority over individual scrum team membership to ensure that resolving issues affecting multiple teams takes priority.

Nexus Events

Sprint – as defined in the scrum framework, a minimum of one week to four weeks sprints, one and two-week sprints may not make sense when multiple teams are involved as more time may be needed for cross-team collaboration. An integrated shippable increment is expected at the end of the sprint.

Cross-team backlog refinement – The Product backlog must be decomposed so that dependencies become transparent. It is important to determine which team will deliver which product backlog items during these sessions. Clear indicators or labels should be used to make it transparent which team owns which items to avoid duplication of work. Dependencies should also be identified as much as possible and a plan to resolve them put in place. Items that have dependencies should be clearly labeled. A clear Definition Of Ready can be beneficial here.

The Product Owner should carefully select the relevant team members to participate in the refinement from the scrum teams depending on which items need refining.

Where needed each scrum team continues refining their items to be ready for selection in a nexus sprint planning.

Nexus Sprint planning – Appropriate representatives from each scrum team and the product owner meet to plan the sprint. The outcome of the event is as follows;

• A Nexus Sprint Goal that describes the purpose that the Nexus will achieve 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.

Sprint planning for individual teams – While the nexus guide does not mention it, I would recommend that individual scrum teams have their sprint planning to ensure every member understands the team’s goal for that sprint. Discuss their sprint backlog items and organize themselves as a team.

Nexus daily scrum – The Nexus integration team inspects the current state of the integrated Increment, and identifies integration issues and newly discovered cross-team dependencies.

Daily scrum: Each team’s daily scrum creates a plan for the day where priority is set on fixing any integration issues raised in the nexus daily.

Nexus Sprint review – The Nexus Sprint Review is held at the end of the Sprint to provide feedback on the Integrated Increment and determine what adjustments need to be made.

Nexus Sprint Retrospective – The Nexus inspects how the last Sprint went with regards to individuals, teams, interactions, processes, tools, and its Definition of Done and comes up with recommendations to improve quality and efficiency across the teams. I may add here from my own experience that the Definition Of Ready should be reviewed too since it plays a critical role on how smoothly a sprint runs.

Sprint Retrospective – During the individual scrum teams’ retrospectives the scrum team needs to inspect how their sprint went in addition to taking in feedback from the nexus retrospective.

Nexus Artifacts

Product Backlog – There is a single Product Backlog for all Scrum Teams. The Product Owner is accountable for the Product Backlog.

Nexus Sprint Backlog – consists of the Nexus Sprint Goal and items from the Sprint Backlogs of the individual Scrum Teams. It makes dependencies transparent and it is updated throughout the Sprint as more is learned.

Integrated Increment – The Integrated Increment must meet the Definition of Done, it should be usable and should be released within the sprint.

Conclusion

The essence of the Nexus framework is to reduce cross-team dependencies while preserving the scrum framework benefits. It makes it possible to scale the value that the group of scrum teams working on a single product can deliver by reducing the complexity encountered by the teams as they collaborate. There is power in working with smaller teams in terms of speed and efficiency. For events such as cross-team backlog refinement and any events owned by the integration team, the participants should change based on the purpose they serve and their expertise.

A clear Definition Of Ready is critical in ensuring that no time is lost during the sprint and a clear Definition Of Done ensures that a usable integrated increment is produced successfully. In a setup such as this, ensuring robust quality assurance processes is critical for successful delivery.