Scaling Scrum with Nexus

Scaling Scrum with Nexus

 

Scrum is primarily defined for one team, with a maximum of 9 members. When more than one team is required, the system is called Scaled Scrum.

There are different ways of scaling Scrum. Unfortunately, most of them are focused on generic advice, not clearly defined, or are just too complex.

Scrum.org has recently released their own framework for scaling Scrum, called Nexus. It’s explained in a short 11 page guide. In my opinion, it’s the best option, because:

  1. It’s simple, and straightforward. It seems like many forget that Scrum is supposed to be simple. I sometimes even suspect they make it too complex to impress the audience.
  2. It’s practical, and the defining guide is really a definition rather than a set of generic advice. This is, unfortunately, very common nowadays for authors to just provide vogue, generic advice when they are talking about Agile. Many even believe that Agile is nothing but that; while its core should be a framework/methodology. Scrum.org supports this basic need in a great way.

Let’s take a quick look at Nexus.

Development Teams

There can be 3 to 9 teams in this framework. Each team consists of 3 to 9 developers, and therefore, the maximum number of developers supported here is about 80.

Note: the term “developer” refers not only to programmers, but also anyone else who has a part in the production of the solution, including, but not limited to designers, analysts, and testers.

Each team still needs a Scrum Master, and since this role is not necessarily full-time, one person can be the Scrum Master for more than one team. However, not more than one Scrum Master would be assigned to one team.

Product Owners? No, there’s no Product Owners in each team. One project has only one Product Backlog and one Product Owner, to minimize complexity, and ensure that prioritization is done properly.

Integrated Increment

Each team produces its own “Done” output during each Sprint. The outputs create one “Integrated Increment” for the whole project, and this is what the supplier demonstrates to the customer for feedback and adaptation.

The Nexus Integration Team

There’s a new “integration” layer added to the framework to ensure that an Integrated Increment is created at the end of each Sprint.

There’s a “Nexus Integration Team” in this layer to:

  • Coordinate,
  • Coach, and
  • Supervise.

This team consists of one or more ream members, who can be dedicated to this job, or also be a developer in a development team. There’s a Scrum Master assigned to this team, who’s expected to be expert enough in Scaled Scrum.

This is also where the Product Owner is placed. Remember, there’s only one Product Owner in this framework.

Events

This is how events are handled in this framework:

  • Sprint – all teams start and finish their Sprints in the same time.
  • Sprint Planning – it is done in two steps:
    • Nexus Sprint Planning – teams coordinate to select items from the Product Backlog and assign them to their teams. The items will be captured on a Nexus Sprint Backlog.
    • Local Sprint Planning – then members of each team get together to create their own Sprint Backlog based on the selected items.
  • Daily Scrum – it is done in two steps:
    • Nexus Daily Scrum – first representatives from all teams get together to discuss the dependencies and impediments related to the scaled way of working.
    • Local Daily Scrum – then the representatives go back to their teams, bringing the information from the integrated daily standup, and conduct their own Daily Scrum.
  • Sprint Review – there’s no local Sprint Reviews; only an integrated Nexus Sprint Review, which demonstrates the Integrated Increment to the customer, and receives feedback.
  • Sprint Retrospective – there are three steps here:
    • First, representatives from all teams get together to discuss what happened during the Sprint, with a focus on integration and improvements related to the scaled way of working.
    • Then, they go back to their teams and discuss the information from the integrated meeting, along with their inside issues and ideas for improvement. They come up with plans for improvement.
    • Finally, the representatives go back to the integrated meeting to share their improvement plans.

Is that all?!

Almost. Remember that it’s a framework: the minimum structure you need to increase your chances of success. You have to add tools and techniques to apply it to your projects.

This is not everything you need, but is the most important part of it.

Scrum Awareness, One Step a Day (free)

Start learning Scrum by spending less than 2 minutes per day. Lessons will be emailed to you. [more info]

 

5 Responses to Scaling Scrum with Nexus

  1. aiggroup August 10, 2017 at 11:26 #

    Wow! Very Nice, Happy to know about this courses, Nice define, well written.

    Thanks

  2. Sebastian Schneider November 20, 2015 at 11:11 #

    Thank you for the short summary & introduction!

    • René Gysenbergs August 4, 2016 at 13:35 #

      Hello Nader,

      Thanks for the short summary.
      After obtaining PSM I and PSPO I (bye the way, thanks for the help with that), I went and obtained also the SPS certification by Scrum.org.
      I’ve been using it with only 2 teams instead of the minimum 3 teams because 1 team is stationed a few countries further than my other team and it’s a great framework to help even two teams to adapt to eachother…and now, that a 3rd team has been added to the project at my far-away location, all the preparation is really paying off.

      • Nader K. Rad August 5, 2016 at 09:56 #

        Hi Rene,
        That’s great; good luck with your scaled project.

    • Vikram Bhagavan June 17, 2017 at 01:31 #

      Hi Rene ,
      Greetings ,great to know about your experience about the SPS certification can you share what you did for preparation I plan
      to do the same
      Regards
      Vikram Bhagavan

Leave a Reply