Scaling Scrum with Nexus and Kanban

So you have a couple of Scrum Teams that are working in adjacent areas and you’re starting to face some challenges in delivering value in a coordinated integrative way. This is more or less the time you started searching for “scaling agile” “scaling scrum” and exploring your options. Generally, one approach will be to add some scaling principles and practices. Another approach would be to try and refactor your organization/group so the teams actually don’t need each other that much which will reduce even the need for scaling.

Pragmatically, what I generally work out with my clients is a happy middle: refactor somewhat in order to reduce dependencies, Add the right level of Scaling support based on the number of dependencies you have.

Today I want to talk about an approach that fits well into this approach (at least in my experience). Nexus is Scrum.org’s framework for scaled product/software delivery. It uses Scrum as its building block and adds the minimum viable set of roles, events, artifacts, and rules that weave together the work of a set of teams. If you haven’t heard of Nexus before now would be a great time to go read the Nexus Guide. Don’t worry its a great short read. I won’t try to repeat it here.

As you might be aware, Scrum.org now recommends Scrum practitioners leverage Flow thinking by using Kanban practices and flow metrics as part of their Scrum. We talk about that in the Kanban Guide for Scrum Teams and the Professional Scrum w/ Kanban class (full disclosure: I’m a co-author of the guide and co-creator and steward of the class so care deeply about both…).

What we haven’t talked about much until now in the Scrum.org world is how Flow/Kanban can help organizations use Scrum at Scale more effectively, and specifically how would Nexus look like when leveraging Flow/Kanban.

I’ve been using Kanban as a scaling mechanism on top of Scrum since around 2008 or so and it has been the approach I reach out to most often. ( here’s a case study from the LSSC2010 conference about one such implementation, here’s another early talk)

The basis of this approach is to use a Kanban system tracking the work at a integrative higher level than the individual team (Think Features/Epics) and making sure to include upstream and downstream activities that transcend what’s going on inside a specific Scrum Team or Scrum Sprint. This brings transparency and attention to the Flow (or more typically lack thereof) at a larger scale and can help Scrum Practitioners educate/coach their organization about the value of achieving flow and how empericism is very limited if only applied at a level of a Scrum Team stuck within a waterfall system.

With this premise in mind, Let’s take the approach we follow in the Kanban Guide for Scrum Teams and the PSK and explore what might be the impact of applying Kanban/Flow to the Nexus Roles, Events, Artifacts and rules.

In Nexus, all Scrum teams use the same, single Product Backlog. Kanban can be used to visualize the workflow and flow of work on this Product Backlog. This will include all stages of work in the Nexus: ranging from Value discovery, prioritization, refinement, Sprinting, Integrated Increment, Deploying/Releasing, and Learning/Tweaking. The items that would flow on this board would typically be somewhat bigger rocks that are meaningful to the stakeholders.

A new artifact: the Nexus Sprint Backlog helps with transparency across teams during the Sprint and is in addition to the individual Sprint Backlogs the teams maintain. The Nexus Sprint Backlog would essentially be a stage in the Product Backlog definition of workflow. And in this area the Nexus would typically visualize work that hasn’t started in any team yet, has started in at least some of the teams, and is Done meaning integrated increment is ready and no teams have any work left.

The example below (from 2013 or so) shows one such structure. The interesting aspect here is in how this group chose to visualize what’s going on while work is happening at the Team level. You can see that for each small PBI (yellow square) there’s a set of initially empty squares drawn in the Team-level PBI column. These reflect teams that are involved in this PBI and would need to complete their work before an integrated increment can be achieved. They then visualized what team-level PBI was in progress by half-filling the relevant square, and filling it completely when that team was ready to integrate and complete their work. While Kanban doesn’t have a direct impact on the Integrated Increment, it can bring much more transparency into process of creating such an increment and using it even beyond the Sprint Review all the way to real users and real feedback (which is how many enterprise-level teams still work: its still rare to see integrated increments being deployed/released throughout the Sprint).

Refining the Product Backlog is an explicit event in Nexus. Kanban can be used to help the Product Owner and Nexus teams achieve a good flow of refinement: making sure there’s a solid amount of ready work for the Sprint but not too much. Applying WIP limits to the refinement stages can help ensure this healthy flow. Nexus-level Throughput based on PBIs in the single Product Backlog can help forecast how many items are needed for the next Sprint and drive a focused refinement event.

Nexus Sprint Planning can be informed by flow metrics at both the individual and Nexus level. Throughput for each team can be used to help create realistic plans without too much time spent on detailed estimations: freeing up time to focus on the integration challenges. Teams can use their Service Level Expectations (SLEs) to create a realistic predictable plan. Challenging integration paths can be identified and can be tagged as special classes of service the teams address appropriately. Teams should also start planning their Nexus-level WIP: how will they avoid opening too many PBIs and actually apply “stop starting start finishing” across the Nexus. Practically this means that a Scrum Team might avoid starting an integrative PBI when they know other teams are only available to work on it later on in the Sprint.

Nexus Daily Scrum can be held in front of the big picture Kanban board and the focus should be on making sure the overall WIP at the Nexus level is reasonable. Again, Stop Starting Start Finishing applied at the Nexus level. PBIs that are aging too much without being integrated and closed can be identified by visualizing Work Item Aging either directly on the board or using a separate chart. This way, there’s no need to review all the work across teams, just the overall flow/bottlenecks and specific stalled items.

Nexus-level forecasts can be used in the Nexus Sprint Review to help the Product Owner make transparent what’s possible when and what the options are.

Team level and Nexus level flow metrics can inform the Nexus Sprint Retrospective. The Nexus-level definition of Workflow should be inspected and adapted as part of the Nexus Sprint Retrospective.

There’s only one new role in Nexus: the Nexus Integration Team (a.k.a NIT). The NIT is accountable for ensuring a Done Integrated Increment is produced at least once every Sprint. In other words: they’re responsible for the healthy flow of work in the Nexus! So obviously Kanban and flow metrics will be invaluable tools they can use to help the Nexus get transparency on its end to end flow upstream, throughout the Nexus Sprint and downstream. The NIT would typically be the role responsible for creating the big picture Nexus-wide definition of Workflow and making it as well as flow metrics transparent as part of their role of coaching/consulting/highlighting flow issues for the entire Nexus. Kanban and the flow metrics provide a place for the bottom-up intelligence from the Nexus to be used to help achieve flow.

The Product Owner in a Nexus will appreciate having the Nexus-level Kanban Board based on the Product Backlog and the aggregated view of flow across the Nexus. This “altitude” provides the right level of transparency they’re typically looking for. Flow metrics applied at this level can help the Product Owner understand the capabilities of the Nexus and assist them in forecasting.

The Scrum Master of the Nexus Integration Team will have a key role of educating the NIT and the Nexus about Flow/Kanban and applying the practices and metrics appropriately.

In a Nexus the NIT is responsible for a definition of “Done” that can be applied to the Integrated Increment developed each Sprint. Similarly, the NIT would be responsible for the Nexus-level definition of Workflow. Individual Scrum teams will work within this overall big picture definition of Workflow.

When it comes to the definition of Workflow for each Scrum Team, they are responsible for it and will self-organize to define, inspect and adapt such a definition that will help them achieve great flow. Having said that, there’s great potential for cross-pollination across the Nexus and the NIT would do well to facilitate sharing of ideas and insights about team-level definition of Workflow, maybe during the Sprint Retrospective.

Scrum and Nexus are based on Transparency. Kanban is an excellent complementary tool to help achieve complete transparency of the flow of work at the Nexus and support process-level empiricism. Fast feedback loops created by achieving flow through a reduction of Work in Process helps accelerate transparency as to whether correct assumptions have been made in selecting the work and developing the Increment.

In this way, Flow and Kanban help minimize risk and maximize value both at the Scrum Team level as well at scale at the Nexus.

In this article, I’ve gone through the exercise of thinking about how the ideas of Kanban and Flow can be used to complement Nexus and create a lightweight scaling framework.

The Scrum.org Scaled Professional Scrum class is the best place for a deeper dive into the lightweight perspective on scaling Scrum. When I teach it, I also incorporate flow thinking.