Kolumne: A² - alles Agile

Scrum vs. Kanban – Teil 2: Kanban
Kommentare

Um den Arbeitsfluss in Kanban sichtbar zu machen, kommt das Entwicklungsteam um das Cumulative-Flow-Diagramm nicht herum. Das Diagramm zeigt den Fluss im System auf und macht so Blockaden sichtbar.

Die x-Achse spiegelt die Zeit wider und die y-Achse die Anzahl der Tickets, die sich auf dem Board befinden. Die Ticketanzahl wird kumuliert und entsprechend ihrem Status (zum Beispiel To-do, Entwicklung, Test, Fertig) auf der y-Achse vermerkt (Abb. 1).

Um ein möglichst genaues Bild zu bekommen, sollte das täglich manuell oder automatisiert durch entsprechende Tools geschehen. Auch empfiehlt es sich, besondere Ereignisse entsprechend auf der x-Achse zu vermerken, um sie in späteren Betrachtungen gezielt reflektieren zu können. Ein gut fließendes System erkennt man daran, dass sich sämtliche Kurven über die Zeit konstant nach oben bewegen.

Das Gleiche gilt für die Flächen zwischen den Kurven: Fließt das System, wachsen die Flächen gleichmäßig, relativ zueinander. Bei einem System, das nicht im Fluss ist, können unsymmetrisch wachsende Flächen beobachtet werden: Zum Beispiel wächst die Fläche des „Fertig“-Graphen weit weniger als die Fläche des „Entwicklung“-Graphen (Abb. 1). Durch diese Visualisierung kann das Team nun zielgerichtet eingreifen und Verbesserungen etablieren, die das System wieder fließen lassen.

Abb. 3: Cumulative-Flow-Diagramm

Abb. 1: Cumulative-Flow-Diagramm

Ein guter Weg, um das optimale WIP-Limit zu finden, ist das Cumulative-Flow-Diagramm. Wird die „Entwicklung“-Fläche schneller größer als die „Fertig“-Fläche, ist das WIP-Limit für die Spalte Entwicklung zu gering. Es werden also zu viele Tickets angefangen, ohne sie zu beenden. Auf der Vertikalen lässt sich zu jeder Zeit der Work-in-Progress ablesen: Wie viele Tickets befinden sich zum definierten Zeitpunkt in einem bestimmten Arbeitsschritt? Die Durchlaufzeit lässt sich in der Horizontalen ablesen. Man sieht hier, dass ein nicht lineares Ansteigen der Flächen bedeutet, dass das WIP-Limit für einen Arbeitsschritt zu gering gehalten ist.

Bereits erwähnt wurde, wie ein ideales WIP-Limit aussehen kann – zum Beispiel pro Person, pro Arbeitsschritt gleich eins. Besitzt ein System die Arbeitsschritte To-do, Entwicklung, Test und Fertig sowie gleichzeitig vier Entwickler und einen Tester, wäre es konsequent, der Entwicklung das WIP-Limit vier und Test das WIP-Limit eins zu geben. Durch diese ungleiche Verteilung kann es dazu kommen, dass die Flächen ungleichmäßig wachsen.

Die Schlussfolgerung, dass das WIP-Limit für Entwicklung zu groß ist, muss dennoch nicht zwingend richtig sein. Es könnte eine Überlastung der Testabteilung vorliegen, da diese die Tickets der vier Entwickler nicht schnell genug bearbeiten kann. Ein Absenken des WIP-Limits im Schritt Entwicklung würde die Blockade zwar lösen, aber den Gesamtdurchfluss verringern und die Auslastung auf Entwicklungsseite ebenso. Hier muss eine zweite Schlussfolgerung gezogen werden: Bei einer Absenkung des WIP-Limits müssen die Entwickler den Tester unterstützen, oder die Testabteilung muss generell entsprechend unterstützt werden.

Kanban: Durchlaufzeit

Im Cumulative-Flow-Diagramm konnte die Durchlaufzeit unabhängig von Art und Serviceklasse der Aufgaben vereinfacht abgelesen werden. In vielen Fällen reicht diese unscharfe Betrachtung aber nicht aus, und eine detaillierte Auswertung ist notwendig. Hierfür kann ein Diagramm pro Servicelevel oder ein Diagramm unabhängig vom Servicelevel erstellt werden. Auf der x-Achse wird hierbei die Zeit abgetragen, auf der y-Achse die Durchlaufzeit der Tickets in Tagen. Das kann händisch geschehen oder unterstützt durch entsprechende Tools.

Letzterer Vorgehensweise sollte bei der Durchlaufzeit klar der Vorzug gegeben werden, um verlässliche Aussagen treffen zu können. Insbesondere um definierte Service Level Agreements abgeben zu können, müssen diese Daten verlässlich aufgezeichnet werden. Müssen Service Level Agreements abgegeben werden, ist es ratsam, im Vorfeld eine Spektralanalyse der Durchlaufzeiten durchzuführen. Auf der x-Achse wird hierbei die Durchlaufzeit in Tagen abgetragen und auf der y-Achse die Anzahl der Tickets in der jeweiligen Durchlaufzeit.

PHP Magazin

Entwickler MagazinDieser Artikel ist im PHP Magazin erschienen. Das PHP Magazin deckt ein breites Spektrum an Themen ab, die für die erfolgreiche Webentwicklung unerlässlich sind.

Natürlich können Sie das PHP Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Abbildung 2 zeigt eine beispielhafte Analyse der Durchlaufzeiten auf. Zwei Tickets sind als positive und negative Ausreißer zu werten. 85 Prozent der Tickets konnten dagegen innerhalb von acht Tagen bearbeitet werden. Diese Zuverlässigkeit können wir entsprechend im Service Level Agreement vereinbaren. Wird die Durchlaufzeit gemessen, ergibt sich automatisch daraus der Durchsatz an Tickets pro definiertem Zeitraum (zum Beispiel pro Monat). Der Durchsatz kann nun im Weiteren für spätere Releaseplanungen herangezogen werden.

 

Abb. 4: Beispielhafte Analyse der Durchlaufzeiten

Abb. 2: Beispielhafte Analyse der Durchlaufzeiten

Fazit

Die eigenverantwortliche Erfassung und Reflexion der Daten für die Metriken durch die Teams hilft diesen, den Daten zu vertrauen und sie als Anreiz zur kontinuierlichen Verbesserung zu sehen. Klassische Managementmetriken, die in der Regel von außen kommen und nicht selbst erfasst werden, helfen den Teams kaum, da die Akzeptanz und die zeitnahe Auswertung im Team fehlen. Die Teams verbessern ihre Leistung, weil sie es wollen und nicht, weil sie von außen dazu gezwungen werden.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -