Kanban (japanisch für „Karte“ oder „Signaltafel“) bezeichnet zwei verwandte Dinge. Ursprünglich ist es ein Signalsystem im Produktionssystem von Toyota, das der Ingenieur Taiichi Ohno ab den 1950er-Jahren mitentwickelte: Eine Karte meldet, dass an einer Station Material nachgeliefert werden soll, produziert wird also erst bei Bedarf der nachfolgenden Stufe.
In der Wissensarbeit meint Kanban meist die Methode, die David J. Anderson aus diesem Gedanken für Softwareteams entwickelte und 2010 in Kanban: Successful Evolutionary Change for Your Technology Business beschrieb. Ihr Kern ist, die Arbeit auf einem Board sichtbar zu machen, die Zahl gleichzeitig bearbeiteter Aufgaben zu begrenzen (Work in Progress, WIP) und den Fluss der Arbeit zu messen und schrittweise zu verbessern. Anders als Scrum kennt Kanban keine festen Zeitabschnitte und keine vorgeschriebenen Rollen; es beginnt bei dem, was ein Team ohnehin tut.
Im Artikel zum agilen Arbeiten steht Kanban für Support, Betrieb und Serviceteams, im Artikel zu ITIL 4 für den Servicebetrieb, in dem Arbeit eher als Strom eintrifft denn als Projekt.
Eine Grenze: Ein Board allein ändert wenig. Wo die WIP-Grenzen nicht eingehalten werden, zeigt es nur den Stau. Systematische Wirkungsstudien sind mir nicht bekannt.
Quellen
- Anderson, D. J. (2010): Kanban: Successful Evolutionary Change for Your Technology Business. Blue Hole Press.
- Ohno, T. (1988): Toyota Production System: Beyond Large-Scale Production. Productivity Press.