A recent discussion on the kanbandev list interested me because it really brought a focus on what we mean when we say “kanban”.
First, David Anderson posted:
On Fri, Sep 4, 2009 at 2:35 PM, netherby_uk wrote:
(#1) kanban (small k) - meaning signal card – original literal meaning is closer to "shingle" (in American), usage "to hang out your shingle". Signal cards (kanban) are used to facilitate self-organization on a shop floor. With the correct policies they can be used to enable a pull system.
(#2) virtual kanban pull system (small k), generally shortened to "kanban" for convenience – the tool, mechanism of method of using kanban (signal cards) to implement a full pull system in a value-stream. In most of the Taiichi Ohno quotes he is using "kanban" in this sense. Note this includes visualization. Generally speaking the visualizations are not the kanban(#1) but representations of the actual work as knowledge work is invisible.
(#3) Kanban (large k), a method for change management (in software engineering and knowledge work), an enabler of a Kaizen (continuous improvement) culture and process. To do continuous improvement there is a need to incorporate a number of bodies of knowledge including the full suite of Lean thinking, Theory of Constraints, Deming’s Theory of Profound Knowledge, Risk Management / Option Theory, and more will doubtless be added to this list.
After some discussion, Joakim Sundén added:
On Sat, Sep 5, 2009 at 7:27 AM, Joakim Sundén wrote:
1. Kanban (or Kanban Boards) as visualization of project status that helps teams to make work self-directing. This seems to have been Kenji Hiranabes and Poppendiecks early application/understanding of kanban, see e.g. Hiranabes 2007 InfoQ article "Visualizing Agile Projects using Kanban Boards" or Poppendiecks "Implementing Lean Software Development". It is all about visualization and there is no notion of limiting WIP etc. Speaking to Hiranabe and other agile japanese developers on a study tour in Japan this spring most of them referred to kanban in this meaning although some, e.g. Hiranabe, were aware of the other meanings as well.
2. Kanban as a tool. Includes the definition above and extends it with mechanisms as pull and limiting WIP. It can be used with agile methods as well as with waterfall approaches. People who use this definition seem to think of kanban as a tool particularly (and sometimes _only_) useful in software maintenance departments, e.g., where Scrum doesn’t cut it because the constant emergencies ruins the sprint planning.
3. Kanban as an application of lean thinking to software development that is somewhat different to, but not necessarily in opposition to, Poppendiecks flavor of Lean Software Development.
Echoing what David wrote in a later post on this thread, I don’t recognize Joakim’s #1 at all. In fact, when I speak I generally recognize it explicitly as an antipattern because of the pain and chaos it caused the team at Inkubook (as compared to both Scrum and WIP limited pull based systems).
David and Joakim somewhat share the same perspective for their respective #2 and #3’s, so i won’t distinguish between them from here forward. I have seen these 3-level splits before and I find them not working for me because I feel that they miss an important progression. Dividing them into explicit steps loses the important aspect of transitioning between them. I responded with a ShuHaRi perspective that I feel fits the real situation better.
I don’t see what we’re calling kanban as having any real Shu level components at the process level. I suppose working as a member on one of these teams could be considered a Shu level behavior as you learn and copy what your team is doing. A team attempting a kanban system on a Shu-level understanding will degenerate into cargo cult and likely failure. It certainly misses the opportunity to improve itself.
Ha is the entry point for most teams. You read a bunch of different people’s approaches to how kanban is being done, and you take a shot at it based on the set of practices you know. You put up the visual control board, throw some WIP limits on it, and start managing your work that way. You find some success, and you try different practices that sound useful as they are discussed on the boards. Your level of success goes up and down as you try them, and you learn.
Ri behaviors emerge when you start feeling the need for changes and see the appropriate places to make the changes. This is very similar to David’s original #3 at the top of the discussion, but without the explicit statement of the bodies of knowledge involved. I do pull from all of those areas David lists, but I also pull from adult education, hospital management (a special flavour of lean), NLP, software architecture, design & patterns, physical architecture, science fiction, military history, a study of politics, and anything else that inspires me to a better solution at the time. Thus, I argue with David’s #3 on semantics, not on intent. The core goal is to "achieve continuous improvement through continual application of approaches and techniques from a variety of sources".
Ha->Ri is a process of continual improvement itself, and I suspect this is why I don’t see #2 and #3 as different things… I see it as an axis of progression and learning on which #2 is the starting point and #3 is one of many possible futures.