Scaling Scrum without crushing its soul

Recently I attended training on Nexus at Scrum.org’s Boston headquarters. Nexus is based on the core principles and values of Scrum and allows companies to apply Scrum at scale while retaining the bottom-up intelligence of self-organization. This post outlines my experience with Nexus and why I feel it is an important consideration for organizations scaling agile without compromising its principles, values, and benefits.

The concept of “scaling agile” has created a significant debate in the agile community. In particular, the introduction of the Scaled Agile Framework (SAFe) has been controversial. Many agilists feel SAFe runs counter to the core values of agile (in particular “Individual and Interactions over Processes and Tools”) by promoting hierarchy and top-down control, suppressing the power of self-organizing teams to mere delivery units, aka Taylorism. However, it is not the intention of this post to further this argument.

Nexus takes a different view of the world. It is non-prescriptive, Nexus has been described well by others (here and in the Nexus Guide) so I won’t regurgitate that. Instead, I will discuss the salient learning points:

1. Nexus helps organizations build software at scale without compromising the bottom-up intelligence of self-organizing teams. Like Scrum, it is minimalistic, with a small yet clear set of rules. The brilliance of self-organization remains intact – autonomy, engagement, shared ownership and continuous improvement. Teams continuously improve and using the core principle of emergence they adapt to develop a model that best suits the organization.
2. At scale, dependencies (technology, tools, architecture and people) become challenging. Transparency is a critical tool in resolving this.
3. At scale, integration is challenging yet essential. Delaying integration to the end, or dealing with it in a “hardening” or “integration” Sprint reduces agility and introduces technical debt. In Nexus the approach is the same as Scrum – an integrated, done increment is delivered at least every Sprint.

One of the first things we covered was to pause and ask yourself “why scale?” What are you trying to achieve? Are you thinking that because single team Scrum worked, doing more of that will deliver even more benefits?  Are you expecting that adding more teams will yield more results? What is your goal? Increased productivity? More value? Increased engagement? Don’t forget Brooks law – adding more people to a late project makes it later. Think before you act.

The second thing to ask yourself is “how can do more with the teams we already have?” If you had money to spend on solving this without adding more people, what would you spend it on? There are significant gains to be had from automation, training, coaching, increasing transparency, removing organisational impediments and increasing the focus on value (i.e. outcomes over outputs). Scrum.org call this Professional Scrum and make it clear that Nexus is built on Professional Scrum. Another way of looking at this is what hurts in single team Scrum is excruciating at scale. Don’t scale crap.

So, assuming you have at least considered these questions, then let’s look into the framework.

Nexus introduces one new role, two new artifacts, and four new events:

1. One new role – the Nexus Integration Team
2. Two new artifacts:  Nexus Sprint Backlog – the work the various teams are pulling into the Sprint, and the Nexus Goal – the guiding objective of the Sprint.
3. Some Nexus level events – Nexus Sprint Planning, Nexus Daily Scrum, Nexus Sprint Review and Nexus Retrospective. Unlike Scrum, Nexus makes Refinement mandatory. More on this below.\

The Nexus Integration Team

The NIT is accountable for ensuring that an integrated increment is produced at least every Sprint. The keyword here is accountable. That doesn’t mean they do the integration work on behalf of the Scrum teams. It means they remind those teams that they need to work together to deliver one integrated and done increment. It is additional accountability alongside their normal work in their Scrum team.

The NIT is comprised of the Product Owner (note there is only one PO of a Nexus), a Scrum Master and one or more people from the various Scrum teams. Membership is dynamic – it includes who it needs to include in order to achieve its objective. The NIT is responsible for coaching and guiding Scrum teams to create an integrated increment.

It is important to note that this is different to SAFe’s System Team. The NIT does not build development infrastructure, perform integration and system testing for the teams. They simply help bring an integration perspective to remind and coach the individual Scrum teams that integration is a key part of everyone’s work at scale.

This is a fundamentally different perspective to SAFe. Doing the integration work for them is relay race thinking (Taylorism) and totally misses the point. We are looking for shared ownership and group accountability. Having another team integrate the teams work for them feels like a hierarchy and is an epic fail in my book. I am really pleased to see how true to agile values Nexus is in this regard.

Refinement

Refinement is a mandatory event in Nexus and I feel this makes sense. At scale, coordinating work across teams and across Sprints adds significant complexity. Reducing these dependencies for the next few Sprints helps. Rather than view Scrum teams as software delivery factories that need to be fed work that is broken down into digestible pieces, Nexus uses a dynamic network structure , continually adjusting to the work at hand. Based on this, it approaches refinement by adjusting three key areas:

1. The work – we can restructure Product Backlog items to minimize dependencies.
2. Teams – we can adjust the composition of the teams to fit the work.
3. Architecture – we can intelligently architect for scale, allowing teams to work with fewer dependencies.

The key focus is the alignment of these three areas.

I really like the fact that Nexus has introduced this concept. Scaling isn’t about industrializing our existing model to feed fixed delivery teams regardless of the nature of the work. That feels like a production line. Instead, Nexus seems to have adopted concepts from Sociocracy and Holacracy and is comfortable adapting teams to the work. Nice move. Note this is quite a change from the mantra of stable teams.

Scaling via architecture is also important. Spotify take this approach using Chromium Embedded Framework, freeing each team to deploy their part of the product without impacting the other teams.

Refinement is all about transparency of the possible next few Sprints worth of work. If we think intelligently then we can minimize the problems often encountered at scale.

Nexus Sprint Planning

Nexus Sprint Planning creates a plan for the Sprint. All Scrum Team members have the option of being involved but Nexus doesn’t mandate who attends. Again, you have to decide based on your situation. Does everyone attend or just representatives of each team?

The key outcome is a transparent plan (forecast) for the Sprint, including what items depend on others. The level this is done at is product backlog item level – we don’t need to know the task level detail from each team. A Nexus Sprint Backlog might look something like this with dependencies highlighted:

There are many approaches for conduct large scale Sprint Planning described elsewhere so I am not going to delve into that here. The key takeaway is the importance of strong facilitation skills.  Time spent designing the flow of Sprint Planning is time well spent. Think Lyssa Adkins POWER starts.

There is a good white paper on the Nexus Sprint Backlog here.

Nexus Daily Scrum

The key focus of the Nexus Daily Scrum is to make integration issues transparent and actively manage dependencies. The outcome of the meeting becomes a key input into each teams’ individual daily Scrum. For example, if there are integration issues then these should take priority as they could be blocking other teams.

The Nexus Daily Scrum is attended by whoever needs to be there. It is NOT a meeting for the Nexus Integration Team. It is designed to allow the Nexus to optimize daily, therefore attendance reflects this. This took me a while to get my head around but I realized it was a remnant of hierarchical management stuck in my head. I still had the concept of the NIT being “in charge” or “above” the Scrum Teams. It isn’t. The NIT is simply an additional accountability on individual Scrum Team members with a separate focus – integration. A good example given in the class was the concept of fire wardens at your workplace. They take additional responsibility for different scenario – a fire. It doesn’t make them “higher up” in the organization.

Nexus Sprint Review

There isn’t a lot of change to the core concept here.  The purpose is to inspect the increment and progress and adapt our next move. The challenge is doing this at scale. Again, preparation is the key. Typically, integration issues become evident for new teams.

Nexus Retrospective

From the Nexus Framework graphic, you will notice that the Nexus Retrospective happens in two parts, sandwiching the normal team retrospective. The Nexus parts are attended by representatives of the Scrum Teams – whoever makes sense.

The first part looks at issues that are occurring across multiple teams in the Nexus. What issues are common and impacting us all?  Often these are things like integration issues, environment issues, dependencies, etc. These common trends are included in the teams standard Scrum retrospective. The second part determines how to visualize and address the identified issues. It allows the entire Nexus to adapt based on the findings of individual teams.

I really like this model as it provides a feedback loop for all teams to improve the Nexus – i.e. bottom-up intelligence.

Summary

In summary, I am pleased I invested the time to learn Nexus and feel relieved that there is a scaling approach available that embraces agile principles.  Scaled Scrum is still Scrum. In Nexus’ heart is the self-organizing team and the unwavering faith in bottom-up intelligence. In its soul is the belief that autonomy, shared ownership, continuous improvement, and professionalism do not need to be compromised just because we are working at scale. I feel Nexus makes an important contribution to the agile world.

A special thanks to Rob Maher who did an outstanding job delivering the course and has been a key contributor to Nexus.

Disclaimer: I am a Professional Trainer with Scrum.org