Der Kern: Pull und WIP

Das Herzstück von Kanban ist ein sogenanntes Pull-Verfahren, in dem die verschiedenen Arbeitsstationen ihre freien Kapazitäten ohne externe Einflussnahme selbst auffüllen. Zu diesem Zweck wurden bei Toyota Signalkarten (daher der Name "Kanban") eingesetzt, die der jeweils vorangehenden Station anzeigten, dass ihr wieder Kapazität zur Weiterbearbeitung des Produkts zur Verfügung steht. Die Anzahl der zur Verfügung stehenden Karten war jeweils an die Kapazität der Station angepasst, sodass ihre Überlastung von vornherein vermieden wurde. Das auf diese Weise eingeführte Work-In-Progress-Limit (kurz: WIP Limit) ist der entscheidende Aspekt für den Erfolg des Kanban-Prinzips.

Ein anschauliches Beispiel für ein Pull-Verfahren kommt heute in den Kaiserlichen Gärten in Tokyo zum Einsatz. Jeder Besucher erhält am Eingang eine Karte, auf der die Bitte aufgedruckt ist, sie beim Verlassen der Gärten wieder abzugeben. Nun ist der Zutritt zu den Gärten zwar kostenlos, aber er wird nur so lange gewährt, wie noch freie Karten zur Verfügung stehen. Und weil deren Gesamtzahl sinnvoll begrenzt ist, spazieren immer nur so viele Besucher durch die Gärten, dass jedem ein angenehmer Aufenthalt gesichert bleibt.

Als Organisationsmethode im IT-Umfeld wurde Kanban vor allem durch David J. Anderson und dessen Buch "Kanban: Successful Evolutionary Change for Your Technology Business" bekannt. Anderson nennt folgende Kerneigenschaften, die die Kanban-Methode ausmachen:

1. Visualisierung: Die Einzelaufträge eines Projekts werden für alle Beteiligten sichtbar mit den Prozess-Schritten, die sie aktuell durchlaufen, in Beziehung gesetzt.

2. Begrenzte Anzahl angefangener Aufgaben: Wie schon beschrieben, verhindert das Pull-Prinzip in Kombination mit der Einschränkung gleichzeitiger Aufträge eine Überlastung der jeweiligen Station, im IT-Kontext zum Beispiel des QS-Teams.

3. Steuerung des Auftragsflusses: Auf Basis wichtiger Metriken, zum Beispiel der Durchlaufzeit eines Auftrags, der Länge der Auftragsliste einer Station oder der Verweildauer eines Auftrags an einer Station können fundierte Entscheidungen und Voraussagen getroffen werden.

4. Explizite Definition der Regeln: Die Aufgaben jeder Station werden ebenso vereinbart wie die Kriterien, nach denen sie einen Auftrag als fertig betrachten darf, und wie der Übergang zwischen den Stationen konkret geregelt ist.

5. Aufbau von Feedback-Schleifen: Tägliche Standup Meetings auf Team- und Mitarbeiterebene sowie Team-übergreifende Operations Reviews stellen sicher, dass alle Beteiligten innerhalb der Organisation Einfluss auf die Weiterentwicklung der Prozesse erhalten.

6. Kooperative Verbesserung, Evolution durch Experimente: Mithilfe wissenschaftlicher Modelle, beispielsweise aus der sogenannten "Theory of Constraints", und gezielter Experimente können aus den erhobenen Daten Maßnahmen zur gezielten Verbesserung der Abläufe abgeleitet werden.

Kanban in der Praxis

Das Schöne am Kanban-Prinzip ist, dass nur sehr wenig notwendig ist, um es in der Praxis anzuwenden. Im Grunde sind es nur zwei Dinge: Die explizite Erlaubnis WIP-Limits einzuführen und eine Wand.

Die Wand, egal, ob Whiteboard, Pinwand oder virtuell in Form einer Kanban-Applikation, dient der Visualisierung des Auftragsflusses. Auf dem Kanban-Board wird jeder Prozessschritt als eine Spalte dargestellt. Abbildung 1 zeigt ein sehr einfaches Beispiel für ein solches Kanban Board. Ein klassisches Entwicklungsprojekt könnte durch die Spalten "Backlog", "Analyse", "Entwicklung", "Test", "Change-Vorbereitung", "Produktion" und "Fertig" modelliert werden. Im anderen Extrem nutzen Großprojekte unter Umständen sogar mehrere, hierarchisch gestaffelte Boards, wobei eines den Gesamtstatus wiedergibt und weitere Boards zur Verwaltung der einzelnen Teilprojekte zum Einsatz kommen.

Abbildung 1: Das Kanban-Board stellt jeden Prozessschritt in einer eigenen Spalte dar. Die Projekte wandern von links nach rechts.