Search
Close this search box.
Search
Close this search box.
Search
Close this search box.

Scaling Scrum with Nexus and Kanban

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

Everybody wants to Scale Scrum

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.

Scaling Scrum w/ Nexus

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.

Nexus Framework
The Nexus Framework – Scrum.org

If you haven’t heard of Nexus before now would be a great time to go read the Nexus Guide. Don’t worry it’s a great short read. I won’t try to repeat it here.

Scaling Scrum w/ Flow and Kanban

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 an 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 empiricism is very limited if only applied at a level of a Scrum Team stuck within a waterfall system.

Combining Nexus and Kanban

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.

Kanban applied to the Nexus Artifacts

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 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 the 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 much enterprise-level teams still work – its still rare to see integrated increments being deployed/released throughout the Sprint).

Kanban Applied to the Nexus Events

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 levels. 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 really 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 is 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.

Kanban’s impact on Nexus Roles

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 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 in educating the NIT and the Nexus about Flow/Kanban and applying the practices and metrics appropriately.

Definition of Done and Definition of Workflow at the Nexus

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 the team-level definition of Workflow, maybe during the Sprint Retrospective.

Artifact Transparency

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 the Process help 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.

Nexus and Kanban – Achieving empiricism and flow at scale

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

SPS scaled professional scrum

The Scrum.org Scaled Professional Scrum class is the best place for a deeper dive into the lightweight perspective on how to scale Scrum. When I’m teaching the class I’m bringing flow thinking into it as well.

Subscribe for Email Updates:

Categories:

Tags:

Agile Community
EOS®
Sprint Retrospectives
Scrum
Systems Thinking
Acceptance Test-Driven Development
Spotify
System Team
Advanced Roadmaps
ALM Tools
Scrum With Kanban
The Agile Coach
ART Success
NIT
Program Increment
Professional Scrum Product Owner
Reading List
Scrum.org
Scrum Master
Release Train Engineer
agileisrael
ScrumMaster Tales
SAFe
Implementing SAFe
PI Planning
Nexus vs SAFe
Agile Marketing
Agile Testing Practices
Lean Software Development
Lean Budgeting
Agile Israel
Scrum Primer
Lean Risk Management
Agile Contracts Best Practices
Agile Outsourcing
Webinar
Daily Scrum
Kanban 101
Development Value Streams
Planning
WIP
Jira
The Kanban Method
Test Driven Development
Software Development
Nexus
ARTs
ROI
Agile Product Ownership
Managing Projects
RTE
Enterprise DevOps
ATDD
Scrum Guide
Certified SAFe
Agile Release Management
Agile Assembly Architecture
GanttBan
Limiting Work in Progress
User stories
AI Artificial Intelligence
Agile and DevOps Journey
Large Scale Scrum
Kaizen
Atlaassian
BDD
Atlassian
Tips
DevOps
Jira Cloud
Risk Management in Kanban
Games and Exercises
Agile Games
Lean Agile
Agile Techniques
AI
Kanban
LAB
Lean Agile Leadership
Scrum Master Role
AgileSparks
ATDD vs. BDD
SAFe DevOps
Iterative Incremental Development
Agile
Presentation
Video
Lean-Agile Software Development
chatgpt
Coaching Agile Teams
Nexus and Kanban
Lean Startup
An Appreciative Retrospective
LPM
Hybrid Work
Lean and Agile Principles and Practices
Certification
Jira admin
A Kanban System for Software Engineering
Agile India
Tools
Portfolio for Jira
Process Improvement
predictability
speed at scale
Product Management
Manage Budget Creation
Elastic Leadership
Story Slicing
Risk Management on Agile Projects
Amdocs
Scaled Agile Framework
Nexus Integration Team
PI Objectives
Lean Agile Organization
Business Agility
Lean Agile Management
Agile Basics
Lean-Agile Budgeting
SAFe Release Planning
Continuous Improvement
Kanban Kickstart Example
Continuous Delivery
SA
Sprint Planning
Introduction to Test Driven Development
Agile Exercises
RSA
Frameworks
Operational Value Stream
Principles of Lean-Agile Leadership
QA
Artificial Intelligence
Kanban Basics
Entrepreneurial Operating System®
Slides
Rapid RTC
Implementation of Lean and Agile
Accelerate Value Delivery At Scale
Continuous Integration
Covid19
Introduction to ATDD
Nexus and SAFe
Professional Scrum with Kanban
Agile Games and Exercises
Lean and Agile Techniques
Self-organization
Agile Israel Events
Agile Project Management
SPC
LeSS
Engineering Practices
Change Management
Agile Program
IT Operations
Legacy Code
Professional Scrum Master
Sprint Iteration
System Integration Environments
Built-In Quality
System Archetypes
Legacy Enterprise
speed @ scale
Agile in the Enterprise
Quality Assurance
Software Development Estimation
Kaizen Workshop
Continuous Planning
Scrum and XP
Effective Agile Retrospectives
Agile Project
RTE Role
Agile Mindset
What Is Kanban
Product Ownership
Applying Agile Methodology
Agility
TDD
Scrum Values
Agile Risk Management
Jira Plans
Agile Development
Agile Release Planning
Lean Agile Basics
POPM
Pomodoro Technique
Perfection Game
Achieve Business Agility
Risk-aware Product Development
Releases Using Lean
Code
lean agile change management
Managing Risk on Agile Projects
Continuous Deployment
Agile for Embedded Systems
Kanban Game
Agile Product Development
Value Streams
AgileSparks
Logo
Enable registration in settings - general

Contact Us

Request for additional information and prices

AgileSparks Newsletter

Subscribe to our newsletter, and stay updated on the latest Agile news and events

This website uses Cookies to provide a better experience
Shopping cart