Friday, March 12, 2010

2010 Kanban Conference

For those who haven’t noticed, and perhaps we didn’t make it obvious, this year’s Kanban conference is the Lean Software & Systems Conference in Atlanta next month. Hurry! You only have two weeks to sign up at the regular price of $995 before the punitive last minute pricing of $1250 kicks in.

This year’s event features 10 specific Kanban presentations and as many as 10 more case studies and field reports, as well as sessions on more general Lean application for software and systems engineering. It’s probably the best value conference you can attend this year. Packed with high quality content.

So don’t be misled by the lack of Kanban in the title. This is it! This is the 2010 Kanban Conference! Hope to see you in Atlanta!

Why do we use Kanban?

During my week in Argentina, I’ve been thinking hard about the correct motivations for adopting the Kanban Approach to change management and organizational culture. I’ve been asking myself hard questions about my own original motivations and why someone coming to it now would want to adopt the approach. I’ve concluded that I (and people I advise and coach) use Kanban for three main
reasons.

(1) Evolutionary, incremental change with minimal resistance
(2) Achieve sustainable pace by balance throughput against demand
(3) Quantitative Management and emergence of high maturity behavior in alignment
with senior management desire to have a highly predictable business
(4) Better risk management (the emerging theme in the Kanban community)

(1) & (2) are where I started in 2004. They are the focus of the forthcoming Kanban book. (3) represents a
staging area to (4). You need quantitative management to really
encourage a kaizen culture and to achieve better incremental improvements. (3)
is also a pre-requisite for some elements of risk management.

We do not use Kanban because

(1a) we want to decouple cadence (planning, lead time, delivery)

- such a decoupling could be achieved without limiting WIP or visualizing work

(1b) we want to dispense with iterations

- we can remove iterations without limiting WIP or visualizing work. You do not
need a pull system to disperse with the iteration framework

(2) we want to manage and optimize flow

- we can achieve flow management with an unconstrained system. I demonstrated
this between 2002 and 2004 with the case studies and examples from Motorola’s
PCS division - the era I refer to as “managing WIP with Cumulative Flow
Diagrams” and is also a large focus of my Agile Management book

(3) we want to abandon estimation or use of the velocity metric

- there can be a relationship between making estimates and limiting WIP. In some
case studies, estimation has been a source of variability and a contributing
factor to customer dissatisfaction. Limiting WIP can control (or remove) sources
of variability. However, there is no direct general relationship that says
introducing a WIP limited pull system will replace estimation.

(4) we want to introduce a forced workflow, handoffs or incentivize
specialization

- Kanban (capital “K”) as a change management method will work with any WIP
limited pull system. This would include DBR, CONWIP or a CapWIP (CONWIP/DBR
hybrid) and not just a kanban system. A simple CONWIP solution need not involve
any workflow, handoffs or specialization but it will still have the effect of
catalyzing change.

The 4 items in my “don’t do Kanban because” list represent elements that are
coincidental to Kanban but have tended to exist with most implementations. So
the casual observer making an empirical judgment without a deeper understanding
of the motivations, principles and science might draw these conclusions. I
believe such conclusions are a source of much of the misinformation and
criticism.

While adopting a limited WIP pull system solution is an answer to these problems it is not the only answer nor do these problems represent a solid motivation for adopting the Kanban approach.

The 4 items on my “do Kanban because” list represent the focus of my Kanban
Coaching Workshops. Only the first two - incremental change and sustainable pace - were drivers for
me in 2004 and 2006. The others - quantitative management leading to accelerated
high maturity and better risk management - were emergent properties that we (the community)
discovered in the most recent 3 years. Perhaps the list will get longer? Perhaps
we’ll discover other reasons to use Kanban. However I am confident that the
4 items I list as poor motivations for adopting Kanban will continue to remain poor
motivations