Skip to main content

Scaling Scrum with Nexus and Scrum Studio

January 17, 2018

According to Forrester Research, 90% of Agile teams use Scrum.[1] One reason for this popularity is that Scrum is a simple framework that promotes transparency and empiricism. It is based on a set of principles and values, and consists of three roles (Product Owner, Scrum Master, and Development Team), five events, (the Sprint, Sprint Planning, the Daily Scrum, the Sprint Review, and the Sprint Retrospective), and three artifacts (the Product Backlog, the Sprint Backlog, and the Product Increment), making it highly adaptable to different situations. Scrum is documented in the Scrum Guide, and is free for anyone to use.

When one team works on a single Product, they simply use Scrum. In cases where one team works on multiple Products, they may still benefit from using Scrum if they work on one Product in one Sprint, then another in the next Sprint. This is simply a kind of multi-tasking (see Figure 1).

Using Scrum across Multiple Teams

Scrum is targeted at a single Product being produced by a single Scrum Team. Two teams, and sometimes three, can use Scrum to develop a single product, but as more teams are added, the teams need a bit more than Scrum to manage their cross-team dependencies to ensure that they are able to deliver working Product Increments. We call this “something more” the Nexus Framework, which adds minimally to Scrum.

Figure 1 When to use Scrum and Nexus, at a glance


Sometimes, the need for Nexus sneaks up on an organization. They start with one team, working on one Product, but as the Product’s complexity grows, they start adding people to that team until they have too many to effectively work as one team. With two teams, they can still use Scrum but they need to spend some extra time collaborating informally across teams. This might even work if they grow to three teams, but they often find they need a little something extra to help the teams collaborate. Nexus provides minimally intrusive mechanisms to help them continue to scale without “breaking” Scrum.

Nexus is based on decades of experience working with organizations who are scaling their use of Scrum. Nexus is documented in the Nexus Guide, and is also free for anyone to use. There are several pieces of updated and new Nexus content now available. A new version of the Nexus Guide has just been released. In addition to the guide updates, Patricia Kong, Dave West, and I, from, have also recently written a book on Nexus, The Nexus™ Framework for Scaling Scrum, published by Addison-Wesley Professional.

If you have questions regarding Nexus and the updates to the Guide, register for our upcoming webinar, What is Nexus? An Introduction to the Framework for Scaling Scrum. If you’d like help beyond those resources, you can take a Scaled Professional Scrum with Nexus course.

Many teams working on many independent or semi-independent Products is really a different kind of problem. Each Product may use Scrum or Nexus, some kind of product portfolio management and/or program management approach is usually needed to coordinate their work Scrum and Nexus can be used in conjunction with these practices, without modification.

But what about organizational change and culture?

Adopting Scrum and Nexus often mean changing the way people in an organization, beyond the Scrum Teams, work. It requires creating a supportive environment in which the cultural changes that support Scrum can take hold. While the Scrum Master helps a Scrum Team to change the way they work, Scrum teams need support, nurturing, and protection to help the new behaviors stick. That’s where Scrum Studio helps to create the right management and cultural environment in which empiricism can survive and thrive. We recently published a white paper describing Scrum Studio, and an organization who is using it was recently featured in an article.

Links to Resources



Scrum Studio

[1] 2013

What did you think about this post?