Recently, I hear some people familiar with Scrum compare it with Kanban by saying that “Kanban is also a framework” or that “Kanban offers an alternative framework.”
I know several leaders in the Scrum community promote Scrum as a framework, and while I might debate that appraisal I’m happy to accept it for the purposes of this post.
I do, however, want to take issue with those who propose that “Kanban is a framework.” Kanban is not a framework! It is a process to catalyze evolutionary change! It is a change management process. Arguably, it is currently the _only_ Agile change management process.
Definition of “Framework”
Here is one definition: A structure for supporting or enclosing something else, especially a skeletal support used as the basis for something being constructed. FreeDictionary.com
If Kanban were a framework it would suggest that it gives you the skeleton of a process framework and that you have to enhance and embellish that skeleton in order to have a specific process for a given context. This is clearly not how the Kanban Method works.
Definition of the Kanban Method
The Kanban Method is a change management method. It describes a process for driving change in an organization and that process has sufficient detail as to be repeatable. The context for which the process could be applied started specifically as software maintenance, then expanded to be general software development, and has grown to cover IT operations, IT services and some other areas of knowledge work. There is some belief and hope that Kanban will develop as a general purpose change management approach for knowledge worker industries.
The Kanban Method has three basic principles:
you start with what you do now - regardless of how ugly it is;
you agree to pursue an evolutionary approach to change;
and you initially respect current roles, responsibilities and job titles.
I then identified five core practices that were common to organizations that had success through Kanban. These were:
Visualize - make the invisible work and its workflow visible;
Limit WIP - implement a virtual kanban system;
Manage Flow;
Make management policies explicit;
and Improve Collaboratively - using models and the scientific method to implement a “guided” approach to evolution. There are no random mutations of the target process with Kanban.
As such Kanban is an orthogonal process to the target workflow process. If you are doing software development, the Kanban Method acts upon that process. It is not part of the process - though to be fair implementing a virtual kanban system will require changes to the target process.
Summary
The Kanban Method is a change management process. It is not a software development, project management or IT operations process or framework for such a process. The Kanban Method is a change management process and not a framework for a change management process. The Kanban Method is a specific formula for driving evolutionary and cultural change in an organization. It is designed to be followed and has shown some level or reliability and that outcomes from its use can be predicted within some spectrum of possible outcomes.
Kanban represents pragmatic, actionable advice for leading lasting, effective change in knowledge worker organizations. It is not an abstraction, or a skeleton. Take it, use it, let it help you evolve your existing processes for the better!
This week, we look at new templates available for both personal and organization wide use. We re-examine the value of certain types of estimation and look at how to improve standups. And, be sure to check out the two short videos!
Here is a detailed post on how to improve standups. I like how Neel Lakshminarayan suggests changing facilitators to encourage different team members to take on more ownership and advocate for improvements. http://neelnarayan.blogspot.com/2012/02/daily-kanban-stand-up.html
Microsoft launches Kanban Guidance for TFS. Per David Anderson, “The template doesn’t really deliver the spirit of kaizen nor easily enable a sequence of changes and improvements, but it is a big start. It will go a long way toward encouraging adoption of kanban systems and a service-oriented, service-delivery model for software development.” http://vsarkanbanguide.codeplex.com/
There’s been a flurry of activity in South America and on the kanbandev yahoo group this week and some are noted below.
It’s been challenging to get to all the Kanban articles and discussions popping up everywhere.
If you should come across something worthy of this forum, please call my attention to it.
Using the Mutual Learning Model to achieve Double Loop Learning
by Benjamin Mitchell (@benjaminm) (50 min)
An entertaining video on learning. I like the part about, “The gap is greatest under conditions
of embarrassment or threat.”, where the gap in this case is the difference between what you say and what you do. http://vimeo.com/30599611
An older post by Karen Greaves, Kanban Evolution, resurfaced on twitter this week. While some of the terminology
has since changed (ex: “Balance demand against throughput, has been replaced with “Balance demand against capability”),
it’s still a nice concise overview of the Kanban Method. http://scrumcoaching.wordpress.com/2010/02/13/kanban-evolution/#more-20
Apologies for missing last week’s post. I was completely immersed working with a team in NYC helping them design their first kanban board. Hopefully the extra content will make up for the delay.
An article titled, “Scrum and Kanban: Both the same only different”, by Liz Keogh includes an especially interesting section, “Kanban visualizes what’s happening; Scrum visualizes an ideal.” It points out that with Kanban, a key ingredient is making process policies explicit, so they can be addressed and improved upon. http://lizkeogh.com/2011/11/20/scrum-and-kanban-both-the-same-only-different/
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.
