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

Understanding the relationship between Kanban and the Theory of Constraints Critical Chain Project Management Approach

Facebook
Twitter
LinkedIn
Pinterest
WhatsApp

Background

I recently had a short twitter chat with Catherine Swetel and Steven Holt about the relation between TOC Critical Chain and Kanban. This post will try to sum up my thoughts in a way that is a little bit more persistent, as well as add a bit more color and depth that is not possible in 140 characters. To start with, lets just make clear – I’m no expert at TOC or Critical Chain. I’ve done my share of reading over the years and have seen organizations using CC and helped them explore the Agile/Kanban world. I’ve read Critical Chain for the first time back in 1996 or so and also familiarized myself with the MPCC S&T tree in the last couple of years. With that disclaimer, here are my thoughts, for what they’re worth:

Multi-Project / Program Level

If you start at the project/portfolio level, I see the Multi-Project Critical-Chain and especially its Strategy and Tactics tree as very similar to the Kanban System for driving improvement. Both approaches start with Limiting Work in Progress at the Projects level as key to reducing unhealthy multi-tasking and improving predictability and effectiveness. With time, excess capacity can be used to shape demand and create new exciting business models. I think the CC world is more advanced in its view on this aspect, but the Kanban world is certainly going there. We would be wise to learn from Viable Vision and other great thinking in the TOC world.

The Feature Design Factory

Once inside a project, kanban advocates a feature driven approach to development. The understanding that product development is a knowledge discovery process where units of inventory start as options and end up being working tested validated features is at the core of the Agile approach. The assumption is that we are operating in an uncertain environment. Both the requirements/problem as well as the technology/solution has considerable elements of uncertainty. We welcome this uncertainty as it comes together with the opportunity for great returns. We also recognize that Integration activities hide a lot of the risk in our projects, and so we drive for early and continuous integration to minimize that risk.

The way to operate effectively in this environment is to have a continuous process of focusing on a few features, seeking feedback along the development process all the way to customer/field feedback, orienting ourselves based on it iterating thru the same or earlier stage of the process depending on the feedback, and at the end having a marketable/viable feature that doesn’t hid any more work behind it. Only then do we pull another option/feature and drive it thru the process.
Kanban realizes that we have a certain capacity of features we can effectively process at any point in time. Overburdening this capacity will mean the knowledge discovery for each feature will take longer and the feedback will be handled later at a higher cost. I’m guessing this will resonate with any TOC practitioner. And indeed, the realization that features can be handled as inventory opens the door to applying a lot of the pure TOC thinking.

This approach can be used for handling an ongoing product development context where there is always plenty of options that can provide business value, and we are a factory/studio choosing the best option to develop and deliver.

Managing Projects with Kanban

When the context is a major project comprised of many different capabilities/features, this approach works as well. There might be a stronger need to manage the overall project health, but the basic principles still apply. There was an interesting discussion about this lately in the kanbandev user group. I also covered this in my recent talk about Commitments in a Kanban world. In this area, I believe CC provides us with good practices and tools – Release Burnup/CFD charts can evolve to Fever charts for each project, and an overall Fever chart managing the overall projects portfolio.

Typically, breaking projects to features will result in quite a simple dependency graph/pert chart. This is because the network is comprised of self-sufficient features. Sometimes though, Features do have dependencies on each other, or dependencies on external groups, as well as need to be delivered independently before the major delivery. When this list of dependencies grows larger and larger, maintaining a Critical-Chain view of the project/program together with relevant feeding buffers might make more and more sense. This view should only care about Features with dependencies, so it is typically quite simple, ideally managed as a Big Visible Chart on a project wall, a Look-Ahead plan, etc.

The Feature Design Factory

Once inside a project, kanban advocates a feature-driven approach to development. The understanding that product development is a knowledge discovery process where units of inventory start as options and end up being working tested validated features is at the core of the Agile approach. The assumption is that we are operating in an uncertain environment. Both the requirements/problem, as well as the technology/solution, have considerable elements of uncertainty. We welcome this uncertainty as it comes together with the opportunity for great returns. We also recognize that Integration activities hide a lot of the risk in our projects, and so we drive for early and continuous integration to minimize that risk.

The way to operate effectively in this environment is to have a continuous process of focusing on a few features, seeking feedback along the development process all the way to customer/field feedback, orienting ourselves based on it iterating thru the same or earlier stage of the process depending on the feedback, and at the end having a marketable/viable feature that doesn’t hide any more work behind it. Only then do we pull another option/feature and drive it thru the process.
Kanban realizes that we have a certain capacity of features we can effectively process at any point in time. Overburdening this capacity will mean the knowledge discovery for each feature will take longer and the feedback will be handled later at a higher cost. I’m guessing this will resonate with any TOC practitioner. And indeed, the realization that features can be handled as inventory opens the door to applying a lot of pure TOC thinking.

This approach can be used for handling an ongoing product development context where there is always plenty of options that can provide business value, and we are a factory/studio choosing the best option to develop and deliver.

Managing Projects with Kanban

When the context is a major project comprised of many different capabilities/features, this approach works as well. There might be a stronger need to manage the overall project health, but the basic principles still apply. There was an interesting discussion about this lately in the KanbanDev user group. I also covered this in my recent talk about Commitments in a Kanban world. In this area, I believe CC provides us with good practices and tools – Release Burnup/CFD charts can evolve into Fever charts for each project, and an overall Fever chart manages the overall project portfolio.

Typically, breaking projects into features will result in quite a simple dependency graph/pert chart. This is because the network is comprised of self-sufficient features. Sometimes though, Features do have dependencies on each other, or dependencies on external groups, as well as needing to be delivered independently before the major delivery. When this list of dependencies grows larger and larger, maintaining a Critical-Chain view of the project/program together with relevant feeding buffers might make more and more sense. This view should only care about Features with dependencies, so it is typically quite simple, ideally managed as a Big Visible Chart on a project wall, a Look-Ahead plan, etc.

Another approach I touch on elsewhere (including the commitment talk mentioned above) is to classify the work based on need for shared resource and affecting routing decisions based on that. So if a specialist or any other type of shared resource is currently congested, consider pulling work that doesn’t require much of his involvement. Or even better, pull work that will reduce your dependency on him in the future.

Summary

Well, These are just some thoughts, an invitation for future discussion. I believe there is potential for a lot of synergy between Kanban and CC, especially in the world of complex programs/portfolios. I especially urge the TOC/CC practitioners out there to explore the “Feedback Oriented” view of Agile. What we all need to remember is that the main thing about the Kanban method is that it is aimed at catalyzing evolutionary improvement. It is similar to the aim of the TOC S&T trees trying to drive towards a Viable Vision. Don’t get confused by the mechanics. The key is to use the conversations that happen when it is painful to follow an explicit process policy, like maintaining a WIP limit, to learn something and improve.

And if you are currently using Critical Chain and would like to explore what Kanban or Agile might mean or how they can help you, I’d love to help.

Subscribe for Email Updates:

Categories:

Tags:

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