My thoughts on how Kanban and TOC Critical Chain relate

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.

Kanban’s view of Specialists

Kanban and Lean/Agile in general recognize specialization as a root cause for lack of flexibility and an impediment on the way to business-driven agility. We advocate generalizing specialists and the use of healthy engineering practices to make sure more of the work can be done by more of our people. While this is a worthy vision / desired state, many organizations cannot economically achieve that goal, not in the near term, maybe not ever.

So we need to optimize how we involve our Specialists while we are aiming to reduce our dependency on them, where it makes economic sense.

We start by recognizing that each person, including Specialists has a certain capacity for spreading his attention as well as for actual delivery. Once we overburden this capacity we are abusing our scarcest resource. When we limit the work in the workflow we align the workload with the capacity in the line. But specialists that hover above the work like busy bees flying between flowers require a separate approach. One way is to limit the number of cards a specialist can be involved in. Once that limit is reached, he cannot be asked to be involved in a new card. So either manage without him, or wait with starting that work. Visualizing this involvement will already drive some realizations and maybe some investment in reducing the dependency somehow by knowledge sharing, offloading, 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.

 

🔔 Before You Go, Subscribe To Blog Updates

Did you like this article? Subscribe now to get notified when new articles, resources, and events are published.

We don’t spam!

3 thoughts on “My thoughts on how Kanban and TOC Critical Chain relate”

  1. Hi Yuval

    Many good points. I see more value in combining (Kanban+TOC+IFM), rather than (Kanban+TOC) alone.

    IFM gives the broad scope scheduling based on NPV prioritization of MMFs.

    Please note that MMFs, in this context, are *sets* of features rather than single features.

    When a particular MMF is released to work, then CC is *not* used.

    CC is a relic of the past (As Mary Poppendieck would say), that should be shelved together with CP. Mostly, it is waste.

    Instead, what should be saved from the TOC, is how TOC uses buffer management *during* the due course of the project. Hence, I use buffer management as taught by while implementing the MMFs. (This can also be used on the whole project, i.e. the sum of MMFs too; but only if there is a fixed deadline for the whole project).

    I consider every MMF implementation cycle as a (mini) project in its own right. Therein, feature prioritization is done with whatever preferred method the team uses; typically, if Kanban is in place, pull policies will determine when and which work items get released into the work flow.

    CC can have a place when dealing with multiple projects or project portfolios; but then only in the case where those projects share resources. A multitude of concurrent projects that don’t share resources can be managed without CC.

    As soon as resources are shared, you get the bottlenecks and the interlacing networks that CC can manage.

    However, even in this instance, I prefer to use Lean approaches and limit WIP at the multi-project level too. IOW slash down the number of concurrent projects AMAP, and let the (limited) resources focus on finishing as few projects as possible ASAP. Use a “multi-project” Kanban board, where the “work items” are the single projects. Even better, use IFM at the multi-project level, and stream line the whole organisation to focus. IFM is a great complement to TOC.

    Multi-tasking is always the common enemy, even at the multi-project level.

    Create smaller, multi-functional team, including all role specialization. Then swarm the smaller team, as a whole, at the single MMF at hand. Consider the MMF as the single piece with which you can achieve single piece flow — and yet apply TOC buffer management to manage risk… but I probably need to write a blog post to explain my approach in more detail.

    Take care

    The Chronologist
    http://chronologist.com

    • Thanks for your comment!
      I wholeheartedly agree. IFM is a key part of my work, maybe I should have elaborated a bit more about it in the post, but your comment does a great job
      Indeed each MMF is a mini-project and we like to slice it to smaller pieces that hopefully create at most an ordered backlog, so a very simple dependency map, so CC not required.

      I would agree that the CC effect on multi-projects is provided by doing using Portfolio Kanban, and is a simpler more streamlined approach to getting the same behavior.

      To try and re-emphasize the place I see the CC provide some unique value – it is when the portfolio has a complex dependency network between deliveries of different groups required to deliver one single MMF. Yes, ideally create a cross-functional team that can do whatever needs to be done to deliver that MMF. Realistically though, at scale, you won’t be able to always do that, and you need some way of managing the network of deliveries between Product Lines / Components. a light-weight CC-inspired visualization showing the dependency network can probably help here.

      Waiting for your blog post!

Comments are closed.