Tuesday, October 11, 2011

Why “Capability”?

The eagle-eyed observer of Kanban will have spotted that recently, I and my team have subtly changed some of our messaging. We’ve adopted the word “capability” where previously the term “throughput” was typically used. Why the change?

Those familiar with my Recipe for Success in its various forms published here and in my Kanban book, will know that one of the steps has gone through several changes. Originally, “Balance Demand against Capacity” was replaced in 2007 with “Balance Demand against Throughput.” Why this original change?

Well the original wording was ambiguous and if you follow Eli Goldratt then you will know that he had previously pointed out the folly in such thinking. “Capacity” he pointed out was a volume not a flow. So “capacity” in a kanban system would be the number of (virtual) kanban in circulation (or the total WIP limit of the system.) You don’t balance demand against this. You balance demand against the rate of work being delivered, so the correct term was “throughput,” where throughput means the rate (or quantity over time) of completed work being delivered out of the kanban system.

Throughput

So, why the recent change to “capability” moving away from “throughput”? This change will be reflected in the 2nd edition of the Kanban book (no planned publication date) and in all of our materials going forward. The Recipe for Success will now read “Balance demand against capability.” Why?

I came to realize that using throughput as the metric for success or of determining customer satisfaction is not always appropriate. The customer demands are seldom for more throughput. The demands are often expressed in other ways. There are many contexts where better due date performance or shorter lead times would be more desirable. “Capability” is in this sense an abstract term. Capability can be expressed in many ways. Throughput is just one way of expressing capability. Lead time, its mean, and spread of variation would be another, and due date performance (or on-time delivery performance) would be another. I think these three - throughput, lead time and due date performance - represent the three most likely choices for expressing capability when using Kanban. However, I’d like to leave the definition abstract and encourage other interpretations.

So in future look for us to be communicating that the system level problem is one of a lack of balance between demand and capability. We are pursuing improvements in order to better balance demand against capability. We are assuming that greater customer satisfaction will come from this improved balance. We will therefore design the kanban system solution from the outside, in. Well seek to understand demand and capability and to examine the reasons why capability is impaired and look at how it might be improved. Part of the solution may involve the use of a kanban system and the adoption of an evolutionary approach to future improvements. This is the Kanban Method in action.

Some readers will recognize that this new articulation of getting started with a Kanban initiative by understanding capability and demand and by seeking to identify system effects that affect capability are inspired by the work of John Seddon. This is correct. John has provided me with a better way of expressing what we are doing. Those familiar with the XIT story from MIcrosoft will also recognize that this understanding of capability and demand is exactly what Dragos Dumitriu did before we acted to implement a kanban system solution for his department. Hence, this isn’t new to Kanban but I and my team are constantly learning how to better articulate our work in order to facilitate faster and better understanding amongst those leading change in their organizations through the use of Kanban.

So “thoughput” isn’t out of fashion, it has been relegated to a context specific choice!

Deming and CMMI

There is another reason I love the word “capability”. It is a term that Deming would recognize. It is also the “C” in CMMI for the same reason. CMM (as was) was inspired by the work of Crosby (the Manufacturing Maturity Model) and Deming (the Theory of Profound Knowledge). The “C” in Capability Maturity Model is intended to be interpreted as Deming would have used it. By adopting the use of the term “capability” in Kanban, we are providing clear links to the work of Deming, which we find foundational to much of our teaching and coaching advice. Identifying sources of variability that adversely affect capability and eliminating them through kanban system design, management policy and improved capability, are at the core of Kanban and how we teach it. Further by adopting the term “capability” and providing the guidance that it should be interpreted as throughput (aka “velocity”), or lead time, or due date performance, we are providing clear hooks into CMMI and showing how Kanban can be used as part of a CMMI initiative or how it can be compatible with maintaining or improving a CMMI appraisal rating.

Complexity & Cynefin

In his key note at Lean Kanban Benelux Dave Snowden state that in the complex domain we seek to use an evolutionary approach to change that probes (or experiments) with ideas and then amplifies the successful ones (attractors). He went on to explain that unlike a typical managed change initiative (typical of the 20th Century but sadly still all to common in the Agile community) where a there is a defined destination designed to offer a particular capability - think of “We will adopt Scrum for our next project” or “We will be CMMI ML3 by end of calendar 2012” - a complex space solution must not define a destination but simply allow evolutionary steps to happen. This is exactly how Kanban is designed to operate. However, it creates a problem. How do we know if things are improving? How do we justify encouraging and promoting change? Dave explained that in the complex domain we must measure the impact of a change to know if it is an improvement. This can only be measured retrospectively.

Capability gives us the means with which to measure impact in an emergent reaction to a complex domain problem. By showing improvements in terms of throughput, lead time, or due date performance (as measures of capability), we provide a direct means to assess impact.

Summary

Adopting the term “capability” is more general than “throughput” and reflects the general application of kanban systems and use of the Kanban Method across a range of software development projects, maintenance and IT work. “Capability” is better aligned with the ideas of Deming and modern systems thinkers like John Seddon. It provides a clean way to explain from the outside, in, why Kanban makes sense and the value it is adding - allowing us to better balance demand against capability. “Capability” also better aligns with CMMI and enables those in regulated environments to communicate the value and purpose of Kanban as well as cleanly map Kanban practices such as Cumulative Flow Diagrams to required elements for an appraisal. And finally, “capability” gives us a way to measure the impact of emergent behavior when considering Kanban within a complexity science model such as Cynefin.

We’ve been making some other nomenclature changes.  What out for more blog posts explaining the emergence of other new terms in the lexicon of Kanban.