Wir hatten 735 offene Tickets. Das Ticketing-System hatten wir vor Jahren eingeführt, um zwischen Bug-Reports, Feature-Requests und etlichen Ideen nicht den Überblick zu verlieren. Aber bei 735 Einträgen kann man nicht mehr wirklich von Überblick sprechen. Es ließen sich auch Prioritäten zuordnen, Low - Medium - High, mit der Zeit sammelte sich immer mehr in der Priorität “High” an. Schließlich hatten wir die neue Priorität “Release-Stopper” eingeführt, um diejenigen Tickets zu kennzeichnen, die unbedngt vor dem nächsten Release noch abgearbeitet werden mussten. In der heißen Phase vor einem Release gab es dann ein ziemliches Auf und Ab der Release-Stopper: die Entwickler arbeiten etwas ab, parallel dazu kommen neue Bug-Reports als Release-Stopper aus dem Test herein. Irgendwann war der letzte Release-Stopper gelöst, und wir konnten endlich eine neue Version herausbringen.

Nicht alle offenen Tickets waren Release-Stopper, ein neues Release fing vielleicht mit 30 davon an. Etliche Tickets waren auch schon älter – Dinge, die wir bei einem der letzten Releases nicht geschafft hatten, Feature-Ideen zu denen wir noch nicht gekommen waren, nicht reproduzierbare oder weniger gravierende Bugs u.ä.

Tickets sind geduldig, besonders, wenn man sie elektronisch verwaltet. Was macht es schon, ob es 20, 50 oder 735 offene Tickets sind? Sie liegen alle in einer Datenbank, aus der man mit ein paar Klicks eine Liste mit so ziemlich jeder gewünschten Filterung und Sortierung hervorzaubern kann. Trotzdem hatten wir unterschwellig das Gefühl, dass diese Verwaltung doch einiges an Zeit kostete: immer wieder neu priorisieren, doppelte Fehlermeldungen und Wünsche herausfiltern, Tickets gruppieren usw.

Wieviel Entwicklungs-Arbeit steckt eigentlich in 735 Tickets? Bei uns wurden im Durchschnitt ungefähr 30 Tickets pro Monat abgeschlossen, das ließ sich schnell aus der Datenbank ermitteln. Im Ticketsystem steckte also Arbeit für 735 / 30 = 24,5 Monate oder zwei Jahre. Wenn wir ab heute nichts neues mehr reinlassen würden, keine Feature-Wünsche, keine Bug-Reports, würden wir noch zwei Jahre mit der Abarbeitung aller offenen Tickets beschäftigt sein. Ich fand das ein bisschen deprimierend.

Dieselbe Überlegung kann man auch verwenden, um herauszufinden, wie lange ein Ticket auf seine Erledigung warten muss. In der Warteschlangentheorie gibt es das fundamentale Gesetz von Little, das besagt

Länge der Warteschlange / Abarbeitungsrate = Verweildauer

Alle diese Zahlen sind als Durchschnittswerte gemeint, und es gäbe noch ein paar Fußnoten, auf die ich hier verzichte. Wenn man unsere Zahlen einsetzt bekommt man wieder

735 Tickets / 30 Tickets/Monat = 24,5 Monate

Ein neues Ticket, das heute erstellt wird, wartet im Durchschnitt 2 Jahre auf seine Erledigung. Wenn einfach nach der Reihenfolge des Auftragseingangs (first in first out - FIFO) abgearbeitet wird, ist die Formel leicht einzusehen. Das neue Ticket stellt sich hinten an, es wird erst fertig, wenn alle seine Vorgänger abgearbeitet sind – eben nach 24,5 Monaten.

Sicher, wir hatten vieles erheblich schneller erledigt. Little’s Law gilt aber unabhängig davon, wie kompliziert oder einfach gestrickt die Prioritäten verwaltet werden. Der Zeitgewinn für die höheren Prioritäten (Release-Stopper) wird mit zusätzlicher Wartezeit für die niedrigeren Prioritäten erkauft. Wer vordrängelt, verlängert andern die Wartezeit und macht sich damit unbeliebt. Unsere schnelle Erledigung der Release-Stopper verzögerte entsprechend alles andere, so dass im Durchschnitt die 24,5 Monate Wartezeit herauskamen. Ziemlich demotivierend.

Nicht nur, dass wir in jedem Release-Zyklus die Tickets wieder neu anfassen mussten, man konnte auch kaum einem Kunden guten Gewissens einen Zeitrahmen für irgendeine Versprechung geben. Es sei denn, man machte das Feature bzw. den Wunsch sofort auch zum Release-Stopper. Und so wurde dann auch vieles gehandhabt: einfach ein Ticket schreiben genügt nicht, damit es in absehbarer Zeit erledigt ist. Man muss es begleiten, in den entsprechenden Sitzungen dafür sorgen, dass es die richtige Priorität bekommt bzw. nicht wieder heruntergestuft wird usw. Expressbearbeitung wird zum Normalzustand.

Damals haben wir die ernüchternde Erkenntnis hingenommen: das durchschnittliche Ticket braucht 2 Jahre bis es abgearbeitet wird. Heute würde ich einiges anders machen.

Matthias Berth