Offene Tickets, noch nicht bearbeitete Bug Reports, oder Pull Requests, die auf eine Sichtung warten – dies alles sind Beispiele für Work in Process (WIP). Im Projektgeschäft verwalten wir diese halbfertige Arbeit mit schönen Tools, wie Issue Tracker, Trello oder GitHub. Das ist bequem, verstellt aber oft den Blick auf die Folgekosten:

• Die (durchschnittlich) lange Verweildauer verzögert das Feedback.
• Aufgaben werden im Laufe der Zeit weniger wertvoll (z.B. weil die Spezifikation veraltet), oder sogar obsolet.
• Die nächste Aufgabe auszuwählen wird mühsam, wenn mehr als, sagen wir mal, 20 zur Wahl stehen.
• Wir können keine verlässlichen Zusagen mehr machen, wann etwas abgearbeitet sein wird.
• Wenn dauerhaft mehr Aufgaben hereinkommen, als abgearbeitet werden, bleiben einige für immer liegen.
• Irgendwann geht es nur noch über Express-Bearbeitung (mit den Prioritäten Dringend, ganz Dringend und super Dringend).

Die Maxime aus dem Lean Thinking lautet daher: WIP begrenzen, um die Durchlaufzeiten zu verringern und die o.g. Folgekosten zu vermeiden.

Für die Beobachtung von WIP bzw. allgemein Warteschlangen hat sich ein einfaches Diagramm bewährt: Das Cumulative Flow Diagram. Hier ist ein schönes Beispiel aus einem Open Source Projekt (cucumber-jvm):

Das Diagramm zeigt, wie sich die Zahl der offenen Github-Issues (=Bug Reports, Wünsche, Pull Requests u.ä.) und die Zahl der abgearbeiteten Issues (Status “closed”) verändern. Es heißt “kumulativ”, weil beide Anzahlen übereinander gestapelt werden, d.h. der obere Rand der blauen Fläche zeigt die insgesamt vorhandenen Issues (offene + fertige). Die Höhe des blauen Bereiches zeigt, wieviele Issues noch offen sind, das ist also die Länge der Warteschlange. Ende 2017 haben wir insgesamt 1228 Issues, davon sind noch 46 offen.

Ich sehe in diesem Diagramm drei Phasen:

• Phase A bis etwa 1.4. 2012: Die Zahl der Issues wächst schnell, die Abarbeitung hält ungefähr Schritt.
• Phase B von April 2012 bis Mitte 2017: Neue Issues kommen jetzt langsamer (Anstieg der obersten Linie verringert sich). Dennoch: Die Warteschlange wird immer länger, zum Ende von Phase B im Mai 2017 waren es ungefähr 220 offene Issues.
• Phase C von Juni bis Anfang November 2017: Es wird aktiv gegengesteuert. Neue Issues entstehen mit unverminderter Geschwindigkeit, aber die Abarbeitungsrate (Anstieg der Grenze der grünen Fläche) erhöht sich stark. Der sehr steile Anstieg am Anfang von Phase C (Mai-Juni) und der noch steilere Anstieg ganz am Ende (Oktober) lässt vermuten, dass hier veraltete Issues en masse geschlossen wurden.

Etliche Projekte stecken in einer Situation, die Phase B ähnelt: Warteschlangen und folglich Durchlaufzeiten wachsen einfach immer weiter. Da rauszukommen, macht natürlich Arbeit. Cumulative Flow Diagrams können dabei helfen, Problembewusstsein zu schaffen und die Motivation zur Verbesserung hoch zu halten.

Die Zusammenfassung für alle Cucumber-Teilprojekte (Stand: Ende 2017) gibt’s bei Cucumber Issue Stats, ebenso den Code, um ähnliche Diagramme für eigene Github-Projekte zu erstellen.

Matthias Berth