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.

Saturday, October 24, 2009

SEPG NA 2009 - Achieving High Maturity and Agility with Kanban

This presentation from the Software Engineering Institute’s SEPG 2009 conference in San Jose was voted one of the top 10 best at the event. In it I synthesize experience from team with Kanban and the CMMI model. I make the observation that some teams using Kanban to drive change towards improved agility have also exhibited accelerated achievement of model level 4 behaviors.

[Download the slides 7MB PDF]

Kanban Drives Culture and Organizational Maturity Changes

David Joyce has posted a quite remarkable blog summarizing the results at BBC Worldwide since they introduced the use of Kanban, to drive process improvements, one year ago.

Improved Predictability as well as Business Agility

Many people will review this post and look only at the data. As David himself summarizes, the average lead time fell by 8 days from 22 to 14. This does demonstrate improved business agility, a 33% drop in lead time is not to be sneazed at. However, the more careful viewer will observe the dramatic drop in the spread of variation. The upper control limit drops from 70+ to well under 40, almost a 50% drop in spread. What this means is that the team is much more predictable in delivery of new functionality. David is also verifiying that the newer data shows genuine special cause variations outside the limits. While he isn’t stating categorically that the system is stable, in an SPC sense, as there may be some special cause variations hiding inside the limits, the performance shows a dramatic improvement in stability since Kanban was introduce. This is further evidence that the team is performing in a much more predictable fashion. It also implies that the team ought to be experiencing a much smoother working environment with far fewer events that randomize their schedule and distract their attention away from immediate customer-valued work.

Evidence of Little’s Law Cause and Effect

The chart for development cycle time shows direct evidence that Little’s Law is true and that the quantity of WIP has a direct causal relationship with cycle time. The mean drops from 9 days to 3 days but again the spread of variation drops even more dramtically from 31 days to 7 days. Again this is evidence that the team has much greater predictability. Reducing WIP not only reduces cycle time but it dramatically reduces variability too.

The Engineering cycle time chart simply reflects more of the same. Reducing WIP and the policies of Kanban and its expectation that blocking issues will be escalated and resolved quickly has a dramatic effect on both lead time and variability and shows significant measurable gains in both business agility and predictability as a result.

Improved Configuration Management Discipline and Reduced Deployment Transaction Costs

The Throughput chart doesn’t tell us how much value is being delivered but it does show a dramatic increase in the number of releases to production. This rises from one every one or two weeks before Kanban to one almost every working day since Kanban was introduced. To make this possible there must have been an improvement in configuration management discipline and capability and an equal reduction in the transaction and coordination costs associated with a release. This is all indicative of an organization that is maturing and improving in capability as well as an organization that is considerably more “Lean” than it was a year ago, as waste associated with making a release has dramatically reduced.

Bugs decrease with less WIP and Improved Organizational Maturity

The final chart showing defects per week shows that quality did not suffer as a result of introducing Kanban and limiting WIP and that after some time for changes to kick-in that might be associated with an organization growing in maturity and capability the variability in the defect rate dropped dramatically with a small decrease in the mean number of bugs per week. Again this indicative of an organization that is much more predictable.

Conclusions

David is using the SPC charts as report cards. In Donald Wheeler’s scale of adoption of SPC, this is the lowest level of maturity, and SPC as report cards doesn’t fully qualify as quantitative management associated with level 4 in the CMMI model. However, we can conclude that this team exhibits significantly improved performance. They exhibit significantly lower variability and greater predictability and any use of SPC indicates a leadership that is determined to drive process improvement in a quantitative fashion. There is significant evidence of behaviors associated with CMMI model level 4 and this growth in maturity has been achieved in only 12 months.

This seems to be further evidence to back up my claims from my SEPG North America 2009 presentation that Kanban is proving to be a method that leads to accelerated organizational maturity and catalyst of organizational process improvement. We’ve now seen two teams at two significant companies in London adopt statistical process control and show significant progress towards higher maturity behaviors and performance. Perhaps it isn’t a coincidence? Hopefully we’ll see more like this emerge from the Kanban community over the next 12 months.

Wednesday, June 17, 2009

Changes @ AgileManagement.net

I’ve been making some changes at AgileManagement.Net to make it easier for readers to find information and follow new posts. I’ve created separate blog pages with separate RSS feeds for Lean, specifically Kanban, and Agile+CMMI.

For now the existing Agile Management blog will continue to aggregate all the content. Later I will reduce it to Management topics only. However, I will maintain the existing RSS feed for both the home page and the Agile Management blog. The RSS feed will continue to aggregate everything that is posted to this site. The new RSS feeds should enable aggregators to be more focused. Kanban sites can pull the Channel Kanban RSS feed while CMMI sites can pull the Channel CMMI RSS feed.

As a result of these changes, some content in the site has disappeared the navigation or the archive search. The articles specifically about the Agile Management book are no longer available through the site navigation. However, they are still in the content management system and still available on the Internet via direct links. Older news articles that do not appear on the front page will also not be navigable but again they have not been deleted and are still accessible via direct links.

I hope that these changes provide a genuine improvement in utility for users of the site and those who value its content. There are yet more changes to come as I prepare my web presence for the next decade and modify it to accommodate my newer interests in Kanban, CMMI, and other newer areas like Real Option Theory, Management, Decision Making, Decision Bias, Neuro-psychology and Risk Management.

Wednesday, June 10, 2009

Agile+CMMI Conference Anyone?

In a similar vein to the Lean & Kanban 2009 conference I am thinking of pulling together an Agile & CMMI event. I really feel that a small focused event is needed to kickstart the Agile CMMI community and energize potential adopters.

After some initial market research via my Agile Management Yahoo! group and Hillel Glazer’s Agile CMMI LinkedIn group and Twitter, it looks like we are targeting early December or mid-January somewhere in Florida.

Please leave comments indicating which dates you would prefer, which location (a) Tampa, (b) Orlando, (c) Miami, and please recommend anyone you feel should be an invited speaker at such an event. Would you like 1.5 days or 2.5 days and how much of that time should be dedicated to open space?

[Current voting as of 6/17 - will try to update this daily for a while]

1. Tampa 60%
2. Orlando 20%
3. Miami 20%

Your comments and commitments to attend are vital if this event is to go ahead. Without sufficient interest we won’t run the event. Technorati tag: David+Anderson, Agile, CMMI, SEI, Hillel+Glazer