Nexus Scrum - a framework to scale your scrum development team
Digital product scaling – further developing it to cope with a larger market or environment – is one thing, but what do you do when you need to scale up the software development process itself. What happens when you’re juggling multiple connected projects? How do you ensure that the benefits of Scrum – fast, focused, flexible product development that balances user and business needs – still apply? This article is an introduction to the Nexus Scrum framework, which does exactly that.
Table of contents
Here at Boldare, we are dedicated Scrum fans, and most importantly - Scrum practitioners. We’ve been working agile for years and have 270+ products delivered (many of them award-winning) to show for it. Through 16 years of experience we have come across many products for which the development process had to be speeded up in order to scale the product faster and with a high level of integrity. Other types of projects we encountered were too complex for a single Scrum team, or formed part of a larger connected whole, such as a suite of linked products.
Those kinds of products are hard to maintain and develop, even for skilled and experienced Scrum teams. So how to deal with them, if there’s such a need? For certain specific products we’ve created with our clients, we use so-called Nexus Scrum. The Nexus framework applies Scrum principles on a larger scale, with small but important adjustments to the usual Scrum roles and processes.
If you are:
- Using multiple Scrum teams,
- Building a family of products,
- Need to synchronize your efforts,
- Or speed up development process, keeping its integrity at a high level,
…then the Nexus framework might be a solution you are looking for.
What is Nexus Scrum?
When running multiple connected development teams, you face difficulties. For a start, there’s the product backlog, the to-do list of work and tasks to be carried out to achieve the project’s objectives. Each product has an agreed backlog that has to be executed during upcoming sprints. But what about the overlaps between connected products under development? Multiple teams working from the same backlog sounds like a recipe for chaos. Likewise, different dev teams working in the same codebase. Problems of communication and integration arise.
This is why, according to scrum.org, the goal of Nexus is
“minimizing cross-team dependencies and integration issues.”
Nexus is a framework approach that can be used to align up to nine Scrum teams working on the same product or connected products. 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, “whomever needs to be there to make sure that integration actually happens.”
Nexus agile framework terminology
If you’re already familiar with Scrum (and if you’re not, we recommend our article, “Building successful apps using Scrum development”) you won’t find any surprises in Nexus; it uses the principles and terminology you’re used to. But some obvious differences are applicable:
Nexus Scrum backlog – In Nexus, a single product backlog is used for the whole operation, covering everything being done by all teams. As in Scrum, there is a product owner responsible for the backlog. The keys to a Nexus backlog are the connections, the dependencies between each team’s work.
In the ‘regular’ Scrum process, the team agrees during the sprint planning meeting which items will be tackled in the coming sprint, thus creating a sprint backlog. In Nexus, items from the product backlog are usually only chosen for a sprint when the dependencies with other items are minimal or non-existent; thus cutting down the chances of teams overlapping or doing work that will be wasted later in the project. The Nexus sprint backlog is a detailed plan for every Scrum team for delivering an integrated increment during the sprint. the progress during an integrated increment is monitored and updated during daily Scrums.
Nexus daily Scrum – The usual daily Scrum is a short meeting of the development team with the goal of reviewing and checking that day’s planned activity (any changes being recorded in the sprint backlog) and the progress towards the sprint goal. The key focus is integration:
- Was the work of each Scrum team successfully integrated?
- Have any new dependencies been identified?
- What information or insights must be shared with all teams?
Like Nexus sprint planning, the Nexus daily Scrum acts as a higher-level ‘oversight’. The meeting can be used to discuss issues regarding integration and dependencies between the teams.
Definition of Done (DoD) – Just like a Scrum increment, an integrated increment has an agreed definition of done: a statement of what the teams must achieve in order to call the increment a success. As scrum.org puts it:
“the Increment is ‘done’ only when integrated, usable and potentially releasable by the Product Owner.”
There is only one definition of done and it defines when a task or user story is complete - coded, tested, integrated and ready to be released. Additionally, individual Scrum teams can use acceptance criteria that describe unique conditions for each user’s story that the team has to deliver to satisfy users or stakeholders.
Nexus sprint planning – In the Nexus framework, the sprint planning process basically adds an additional, preliminary planning meeting at which the Nexus integration team discusses and agrees which backlog items will be tackled in the next sprint and by which teams; agreeing an overall sprint goal linked to the definition of done. As dependencies between the work of different Scrum teams are identified, they should be communicated to all (transparency!) and minimized. Each individual Scrum team then plans its sprint, based on their slice of the Nexus sprint backlog.
Nexus sprint review – At the end of each sprint, the Nexus sprint review replaces the individual Scrum team sprint reviews. The meeting is a chance to share feedback on the integrated increment, the combined product iteration that the individual Scrum teams have contributed to, and make any necessary updates to the backlog.
Nexus sprint retrospective – After each sprint (and before the planning of the next sprint) the Scrum teams review the Scrum process itself in a sprint retrospective meeting. The Nexus integration team does likewise for the Nexus work as a whole, identifying shared challenges that impact more than a single team, and agree on any necessary action or changes necessary.
The Nexus integration team
What’s clear from the above information is the need for a specific role to ensure the coordination of the wider Nexus project. That role is fulfilled by the Nexus integration team that provides high-level oversight, guidance and coordination to the connected projects and Scrum teams; agreeing the backlog and DoD, coaching, highlighting dependencies and cross-team issues, and even sometimes carrying out work from the backlog.
The integration team includes a product owner and Scrum master, mirroring the composition of the individual teams.
The team is a central point for integration issues, and is accountable for resolving any technical and non-technical cross-team issues that might impact on delivery of the integrated increment; including coaching the Scrum teams on requirements, procedures or standards relating to the broader project goals.
Members’ integration responsibilities take precedence over their duties as members of an individual Scrum team.
The pros & cons of Nexus
So far, so good. If you’re already familiar with Scrum and have a collection of connected products to build, the choice of Nexus seems a no-brainer. But is it right for you and your specific projects and goals?
Nexus PROS:
- As mentioned already, 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 is done 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 may be ‘widescreen’ Scrum but it 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 – as laid out by scrum.org – is limited to a maximum of nine Scrum teams, or 100 practitioners per product. In one company there can be many Nexuses implemented - each for one digital product.
- You may have 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).
Nexus Scrum - a scaling tool
Nexus is Scrum on a larger scale: more teams, more products or features, more complexity. For an agile organization with a mature Scrum culture (even if that culture is restricted to its software development team) it’s an ideal and easy choice for more involved initiatives with multiple interconnected projects. In essence, Nexus adds an additional layer of coordination to the project structure and while that makes the timetable more complicated, it’s also more efficient and results in higher quality outcomes.
For ‘non-Scrum’, ‘non-agile’ organizations, they may need to look outside for the necessary expertise and experience; similar to outsourcing the development of a single product but looking for a provider with the scope, skills and experience to handle a more extensive role.
Share this article:
