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