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

Understanding the Kanban for Scrum Teams Guide

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

It’s been so exciting to hear so much positive feedback and interest in the new Scrum.org Kanban for Scrum Teams guide and the accompanying Professional Scrum with Kanban class. Creating the class and guide together with Daniel (Vacanti) & Steve (Porter) and then working on getting it to market in a professional way (how else? ) with the Scrum.org staff has been a great experience and a major focus area for me in the last couple of months.

As you might imagine, together with the interest come some questions about some choices we made in the design of the guide and the class. Several are emerging as the frequently asked ones. I wanted to tackle a couple of those in this post.

Where are some of the core Kanban practices?

The major one we’re getting comes from people who have experienced Kanban practitioners who notice that how we describe Kanban in the Kanban Guide for Scrum Teams is different than the definition they’re familiar with. (Including my Kanban Primer for Scrum Teams blog post for example…) This isn’t an oversight. It’s by design. When we set out to create the Kanban Guide for Scrum Teams/approach we had a specific context in mind. That context is teams using Scrum according to the Scrum guide, ideally professionally.

In the Kanban Guide for Scrum Teams, we focus on helping in this context. These teams already have a collaborative inspect and adapt experimentation process together with a set of explicit feedback loops they’re using. So, we set out to define the minimal simplest set of Kanban practices that these Scrum teams would need to add in order to achieve steadier, healthier, more sustainable flow (I like to say it is like moving from a sprint that looks like a swamp to one that looks like a river).

After some discussion we decided that these practices actually complement what a professional Scrum team is already doing :

·    Visualization of the workflow

·    Limiting WIP

·    Active management of work items in progress

·    Inspecting and adapting their definition of “Workflow”

While we agree with the importance of “Improve Collaboratively (Using models and the scientific method” and “Implement feedback loops” we think they are redundant in a professional Scrum context.

Where are some advanced Kanban concepts like Classes of Service, Cost of Delay, and Flow Efficiency?

They’re not part of the guide because we don’t consider them part of the “Minimally viable set of practices” a Scrum team should focus on when trying to improve their flow. Having said that, our guide, and especially the PSK class provides people with some pointers towards advanced complementary Kanban/flow practices/metrics that at least some can use to continue their learning and improvement journey.

Beyond that – Some of them might be useful in some Scrum contexts, some less so.

Is this an application of the Kanban Method or not?

In my personal view, it is pretty close, as long as you assume professional scrum is your starting point. (see a blog post I wrote back in 2012 about this context). You are starting with the way the team uses Scrum and with respecting their current Scrum process & roles. You are obviously interested in pursuing an incremental evolutionary change to improve your performance and satisfaction with your process beyond what you’re currently achieving with Scrum. There is an argument that limiting your work in process is far from being an evolutionary change but rather a disruptive revolution. My personal take on it is that yes, limiting your work in process and moving to a disciplined pull mode is far from being easy, but it’s still evolutionary compared to changing team structures, roles, and process flows. And in any case, this is an argument about the Kanban Method outside of a Scrum context as well. A professional Scrum team should actually have an easier time limiting WIP than most.

Is this ScrumBan?

Depends on who you ask. Some people’s definition of ScrumBan is “A way to help teams transition from Scrum to Kanban”. This isn’t what we’re talking about here.

Another definition (that I subscribe to) is to see ScrumBan as a way to introduce Lean/Kanban flow into a Scrum context – while keeping the core Scrum process intact. This is pretty similar to our take on the process Scrum teams will typically take to get to an effective combination of Scrum and Kanban.

Finally, a variant of this definition is to see ScrumBan as simply the Scrum+Kanban combination itself, without worrying about your starting point and journey. This, in my view, is indeed what the Kanban Guide for Scrum Teams describes.

Why/When should you add Kanban to Scrum?

The last question I want to tackle is one of the first you might want to think about. Essentially the question is “Why bother? Isn’t Scrum great as is?”

Most of the teams I’ve worked with since 2010 or so find Scrum+Kanban to be the ideal mix. I’ve helped Scrum teams achieve an even healthier smoother flow by adding Kanban to their process. I’ve helped Kanban teams accelerate their pace of improvement by adding cadence/rhythm and clarity. I’ve helped teams look beyond their Sprint at the end-to-end flow all the way from idea to outcomes using a Kanban system. I’ve helped organizations manage the flow across several Scrum teams using a Kanban system.

When a Scrum team wants my opinion on whether adding Kanban would be a good idea I typically ask them to think about how hard it is for them to Sprint and whether they feel like they have a good flow during the Sprint. (And like I mentioned above – do they feel like their process is a swamp or a river). It’s as simple as that. I find most Scrum teams struggle to achieve good sustainable healthy flow and Kanban tends to help them with that.

When is Kanban with Scrum a bad idea?

Some Professional Scrum Trainers asked “When would it be a bad idea to introduce Kanban to your Scrum? What are some indicators that you should stop using Kanban as part of your Scrum?” I can’t think of any team where I thought they should stop using Kanban. If they understand Kanban and do it well, there’s really little that can go wrong. The problems start when they don’t understand Kanban or use it as an escape from the challenges of Scrum. Yes, Kanban can help you make your Scrum more sustainable and healthy, but please don’t add Kanban if you’re looking for an escape from the difficulties. Kanban done well adds discipline to your Scrum. Another bad time to introduce Kanban is when the team isn’t looking to improve. If things are working well or more importantly if the team perceives things as working well, they won’t have the energy needed to successfully add Kanban to their process. So make sure you agree on pains/motivations before you move forward to implementing something like Kanban.

Kanban – A way back to Scrum!

To finish with scenarios where introducing Kanban IS a great idea – It pains me every time I see a team/company using Scrum as a new variant of “project management command and control” focusing more on tasks, story points, velocity, and burndown than on empiricism leveraging Done Increments of potentially releasable product.

What I’ve noticed is that introducing Kanban ideas helps these teams/companies finally understand what Scrum really is about and shed a lot of the unnecessary and even harmful baggage and instead refocus on the transparency, inspection, and adaptation brought to life by the core Scrum events, roles, and artifacts. Pretty amazing isn’t it?

This blog was originally posted on Scrum.org

Subscribe for Email Updates:

Categories:

Tags:

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