Kanban: Konstanter Arbeitsfluss

Kanban wurde bereits Mitte des 20. Jahrhunderts erfunden, die Wurzeln liegen in der Automobilproduktion. Das japanische Unternehmen Toyota entwickelte Kanban als System, um Prozesse dezen­tral zu steuern und effizienter zu werden. Produziert wird in der sogenannten Lean Production nur, was gerade nachgefragt wird (Pull-Prinzip). Wenn von Kanban in der Entwicklung die Rede ist, handelt es sich um die von David Anderson angepasste Version, die Ideen der Lean Production an Produktentwicklung, Services und andere Wissensarbeit anpasst. Anderson selbst beschrieb Kanban als Änderungsmanagement-Methode.

Auch Software-Kanban basiert auf einem Pull-System, das die parallel stattfindende Arbeit begrenzt. Diese sogenannten WIP-Limits (WIP steht für Work in Progress) sorgen dafür, dass sich nur die Menge an Aufgaben im System befindet, die auch abgearbeitet werden kann – nicht mehr. Ziel ist ein möglichst konstanter Arbeitsfluss (Flow) ohne Leerlauf oder Engpässe und somit eine schnellere Auslieferung an den Kunden. Zusätzlich stehen – ähnlich wie bei Scrum – auch bei Kanban der Kunde mit seinen Bedürfnissen sowie der eigentliche Wert der gelieferten Ergebnisse im Mittelpunkt des Handelns.

Kanban verfolgt einen evolutionären Ansatz für Veränderungen. Das heisst: Der Entwickler startet da, wo er sich gerade befindet (etwa mit einer Abbildung des aktuellen Arbeitsprozesses via Board), behält die aktuellen Rollen, Jobtitel und Verantwortlichkeiten bei und nimmt Änderungen erst im weiteren Verlauf vor, wenn diese nötig sind. In diesem Punkt ist Kanban einfacher in der Einführung und Handhabung als Scrum: Eine Umstellung auf neue Verhaltensweisen und Abläufe erfolgt erst nach und nach, sodass sich Teams und auch ihre Umwelt nach und nach daran gewöhnen können.

Wichtig zu betonen ist in diesem Zusammenhang auch, dass die Veränderungen durch die in Kanban angestrebte Visualisierung von Arbeit und Prozess auf Basis gemeinsam festgestellter Schwierigkeiten vorgenommen werden und aufgrund dessen eine höhere Chance auf Akzeptanz auf­weisen. Dies ist bei Scrum zwar prinzipiell auch der Fall, zunächst müssen jedoch die Implementierung der neuen Arbeitsweise und die Verinnerlichung der Prinzipien glücken.

Auch das weitere Vorgehen beim Umsetzen der in Kanban bekannten sieben Feedback-Schleifen (Kadenzen) und zwei Rollen ist in der Praxis weniger strikt als bei Scrum. Auf den ersten Blick könnte man annehmen, dass Kanban mit seinen teils sperrig klingenden Kadenzen mehr Overhead mit sich bringt. In der Praxis müssen aber keine sieben Terminserien eingeführt, sondern vielmehr die dahinterliegenden Ziele erfüllt werden – egal, ob im laufenden Prozess oder in gesonderten Meetings. Diese können bei Bedarf stattfinden und müssen keinen festen Rhythmus haben. Beim Kanban-Meeting (täglich), Replenishment zur Planung der Arbeit und Retro­spektiven hat sich jedoch Regelmässigkeit bewährt, um die Personen, die zusammenarbeiten, an das stetige Kommunizieren, Koordinieren und Reflektieren zu gewöhnen.

Die in der Kanban-Theorie formulierten Rollen Service Request Manager (ähnliches Aufgabengebiet wie ein Product Owner) und Service Delivery Manager (unter anderem zuständig für einen guten Arbeitsfluss) werden von Anderson explizit als nicht erforderlich, sondern eher als «Hüte» gekennzeichnet, die dabei helfen können, in der Praxis auch an die Kundenerwartungen und reibungslose Arbeitsabläufe zu denken.

Wer in einem Kanban-Prozess zusammenarbeiten sollte, ist in der Theorie nicht vorgegeben. Vielmehr ergibt sich eine Teamkonstellation von selbst – anfangs durch den Ist-Zustand und später durch eine unter Umständen sichtbar gewordene Notwendigkeit von Optimierung.