Software-Kanban im Einsatz

Inhaltsverzeichnis

Wer die Softwareentwicklung verbessern möchte und nicht gleich eine unternehmensweite Revolution mit agilen Methoden starten will, findet in Software-Kanban eine gute Alternative. Der Artikel liefert eine Vorgehensweise für eine mögliche Implementierung.

Kanban wurde mit dem Toyota-Produktionssystem (TPS) [1] bekannt, das die Autoproduktion revolutionierte. Das Wort Kanban ist japanisch und bedeutet Signalkarte, und im TPS signalisiert eine Kanban-Karte dem jeweils vorgelagerten Produktionsbereich, was in welchen Mengen produziert werden soll. Das führt zu einer Just-in-time-Produktion, die nur das herstellt, was wirklich gebraucht wird.

David J. Anderson überarbeitete die Grundidee von Kanban wesentlich und passte sie den spezifischen Bedürfnissen der Softwareentwicklung an [2]. Das Resultat ist ein evolutionärer Ansatz zur Verbesserung der Softwareentwicklung. Evolutionär bedeutet in diesem Kontext, dass sich bei der initialen Einführung von Kanban wenig an der gewohnten Arbeitsweise ändert: Etablierte Prozesse sowie die Rollen im Unternehmen beziehungsweise im Team bleiben bestehen, und es werden auch keine neuen Job-Titel erfunden. Das Kanban-Team einigt sich jedoch darauf, permanent kleine Verbesserungen der Arbeitsweise vorzunehmen. Ausgangspunkt der Überarbeitungen ist immer die gegenwärtige Situation und nicht ein definierter Zustand, den man erreichen will; demnach gibt es nicht "den" Kanban-Sollzustand. Vielmehr halten sich Kanban-Teams an folgende grundlegenden Prinzipien [3]:

1. Visualisierung des Arbeitsflusses und der Arbeit
2. Limitierung des WIP (WIP = Work In Progress, in Ausführung befindliche Arbeit)
3. Steuerung und Messung des Arbeitsflusses
4. Prozess-Regeln explizit machen
5. Verbesserung durch bewährte Modelle und wissenschaftliche Methoden

Unter Einhaltung dieser Prinzipien haben sich Vorgehensweisen etabliert, die viele Kanban-Teams teilen und aus denen dieser Artikel eine mögliche Implementierung von Kanban in einem IT-Team ableitet.

Arbeitsfluss und Arbeit im Blick

Alle Schritte, die Arbeiten bis zu ihrer Fertigstellung durchlaufen, visualisiert ein Kanban-Team auf einem Whiteboard – dem Kanban-Board. Ein exemplarischer Arbeitsfluss der Softwareentwicklung könnte aus den Arbeitsschritten Design, Entwicklung und Test bestehen. Bei jedem Schritt werden die Kriterien der Fertigstellung ("definition of done") explizit vermerkt, damit alle Teammitglieder das gleiche Verständnis darüber haben, wann eine Arbeit abgeschlossen ist. Arbeitsaufträge werden auf Tickets erfasst und in die Spalte am Board bewegt, in der sich die Arbeit im Moment befindet. Zusätzlich erhält jedes Ticket einen Avatar der zuständigen Person, damit auf einen Blick ersichtlich ist, wer derzeit welches Ticket behandelt.

Wenn die Arbeit an einem Ticket unterbrochen ist, markiert man das Ticket mit einem roten Sticker als blockiert. Arbeitsblockaden können zum Beispiel durch fehlende Informationen, fehlende Infrastruktur oder Ähnliches verursacht werden. Ein stetiger Arbeitsfluss ist eines der Hauptziele in Kanban und demnach hat das Beheben von Blockaden, die den Arbeitsfluss unterbrechen, hohe Priorität.

In Kanban werden erledigte Arbeiten nicht in den nächsten Arbeitsschritt geschoben (push), sondern der Bearbeiter dieses Arbeitsschritts holt sich die Arbeit (pull) vom Vorgänger, wenn er bereit dafür ist. Erledigte Arbeiten markiert man mit einem grünen Sticker oder durch eine Zweiteilung des Arbeitsschritts in "Do" und "Done".

Wider den Engpass

Kanban beschränkt die Anzahl der gleichzeitigen Arbeiten in jedem Arbeitsschritt (WIP-Limit). Diese Begrenzung geht unter anderem auf die einfache Überlegung zurück, dass es sinnvoller ist, eine Arbeit zu 100 Prozent fertig zu haben als zehn Arbeiten zu 10 Prozent. Je größer die Anzahl der aktiven Arbeiten im System ist, desto höher sind die Durchlaufzeiten.

Die Abbildung 3 zeigt, wie sich drei Arbeiten sequenziell und quasi-parallel abarbeiten lassen. Letzteres bedeutet, dass ein permanenter Aufgabenwechsel zwischen den Arbeiten stattfindet, da Menschen nicht fähig sind, aktive Aufgaben gleichzeitig durchzuführen. Man sieht, dass die sequenziellen Aufgaben in jeweils fünf Zeiteinheiten abgearbeitet werden – die Durchlaufzeit beträgt demnach fünf Zeiteinheiten pro Aufgabe. Bei quasi-paralleler Abarbeitung erhöhen sich die Durchlaufzeiten auf 16, 17 und 18 Zeiteinheiten für die rote, gelbe und blaue Aufgabe. Der ständige Aufgabenwechsel fordert einen zusätzlichen Aufwand, da das Projektmitglied sich andauernd in die Aufgaben wieder einarbeiten muss. Der Zusatzaufwand ist in diesem vereinfachten Beispiel mit einer Zeiteinheit pro Aufgabe quantifiziert.

Zusätzlich werden in einem WIP-limitierten Pull-System Engpässe sichtbar: Der in den Engpass Involvierte kann keine Arbeit vom Vorgänger abholen, weil er noch mit der aktuellen Aufgabe beschäftigt ist. Und da der Vorgänger durch ein WIP-Limit beschränkt ist, kann er sich auch keine Arbeit von seinem Vorgänger abholen. Die Konsequenz ist die Blockade des Arbeitsflusses und Kollegen, die am Weiterarbeiten gehindert werden.

Die WIP-Limits werden durch die Zahlen im jeweiligen Arbeitsschritt gekennzeichnet. Am Board oben hat der Schritt Entwicklung ein WIP-Limit von 2, demnach dürfen sich maximal zwei Tickets in dieser Spalte befinden. Das Board zeigt einen Zustand, in dem ein Entwickler mit der Bearbeitung beider Tickets fertig wurde – er hängt sie in die Spalte Done bei Entwicklung. Im Arbeitsschritt Design steht ein Ticket auf Done. Der Entwickler kann sich dieses Ticket jedoch nicht holen, da er das WIP-Limit von 2 überschreiten würde, wenn er es in die Spalte Entwicklung zieht. In diesem Fall unterstützt der Entwickler den Tester bei seiner Aufgabe, damit das Test-Ticket schneller beendet wird und der Arbeitsfluss wieder hergestellt ist.