Gestern hatte ich beschrieben, wie wir genug Arbeit für zwei ganze Jahre in unserem Ticket-System angesammelt hatten. Warum ist es nicht egal, wieviele offene Tickets es gibt? Zum Einen steigt der Overhead für das Verwalten all der Tickets, z.B. Priorisieren, Dopplungen vermeiden usw. Zum Anderen können wir keine guten Zusagen über die Durchlaufzeit mehr machen: Alles was in vertretbarer Zeit fertig werden soll, muss in der Priorität hochgestuft werden (“Release-Stopper”) und braucht eine Art Expressbearbeitung.
Das ironische an unserer damaligen Situation war: wir haben ca. 30 Tickets pro Monat abgearbeitet, und neue Tickets sind auch mit einer Rate von ungefähr 30 pro Monat reingekommen. Wenn wir durch irgendeinen Zaubertrick die Warteschlange auf Null reduzieren könnten, dann würden wir einfach 30 neue Tickets pro Monat abarbeiten, und hätten fast keine Warteschlange mehr. (Jetzt muss ich doch noch eine Fußnote schreiben: Unsere Abarbeitungsrate muss etwas größer sein als die Zuflussrate an neuen Tickets. Auch dann wird noch eine – eher kurze – Warteschlange entstehen, durch statistische Schwankungen in Zufluss und Abarbeitungszeit). Zum Kunden sagen: “Ja, das Problem können wir in ein paar Tagen beheben und dann beim nächsten Update rausbringen” wäre schon schön gewesen. Nicht als besonderes Zugeständnis, sondern einfach so, als zu erwartende Performance.
Wie kann man also diese Warteschlange von hunderten Tickets kürzen und dann möglichst kurz halten?
Bestandsaufnahme machen. Es reichen ein paar einfache Kennzahlen: durchschnittliche Zuflussrate, Abarbeitungsrate, Anzahl der Einträge. Wer möchte, macht noch eine grobe Altersverteilung (x% der Tickets sind älter als 6 Monate u.ä.). Wenn die Abarbeitungsrate kleiner ist als die Zuflussrate, wissen Sie schon mal: die Länge der Schlange wird immer weiter wachsen, wenn Sie nicht grundsätzlich etwas ändern. Ich nehme mal an, bei Ihnen ist das so, anderenfalls wären Sie jetzt eher nicht in einer Situation mit hunderten Tickets.
Alles auslagern, was nicht in eine Warteschlange gehört. Alles, was nicht zeitkritisch ist – z.B. Ideen für neue Features – sollte man anderswo verwalten. Solche Tickets sollten nicht einfach gelöscht werden. Statt dessen den Text in ein Dokument kopieren, damit die Ideengeber nicht enttäuscht sind, dass ihre Arbeit für die Katz war.
Auch andere Dinge, die wir in absehbarer Zeit nicht erledigen werden, sammeln sich manchmal im Ticketing-System an. Etwa detaillierte User Stories, die zu einem fernen Meilenstein gehören. Lagern Sie auch hier die Texte in ein externes Dokument aus.
Ein Limit festlegen. Die Länge der Warteschlange wird ab jetzt zur wichtigen Metrik. Vereinbaren Sie im Team so etwas wie: “Wir wollen nur Arbeit für maximal zwei Monate im Ticketing-System verwalten. Daher begrenzen wir es auf 60 offene Tickets.” (Bei 30 Tickets / Monat Abarbeitungsrate) Verwenden Sie die Anzahl Tickets, das ist wesentlich leichter zu managen als die Durchlaufzeit.
Die Warteschlange aktiv verkürzen. Wahrscheinlich gibt es jetzt immer noch mehr offene Tickets als Ihr Limit. Nun können Sie anfangen, Tickets aktiv zu schließen.
Identifizieren Sie die Tickets, bei denen es am längsten keine Aktivität mehr gab. Hier ein Vorschlag für eine Email an die Beteiligten eines Tickets:
Um besseren Service zu bieten, wollen wir die Anzahl offener Tickets auf 60 begrenzen. Ihr Ticket “Biete Vollmond-Rabatt an” hatte seit 8 Monaten keine Aktivität mehr. Falls Sie noch Interesse haben, antworten Sie bitte bis zum … auf diese Email. Anderenfalls gehen wir davon aus, dass das Ticket nicht mehr relevant ist und wir es schließen können.
Für die meisten Tickets werden Sie wohl keine Antwort bekommen, sie können also geschlossen werden. Dosieren Sie die Anzahl dieser Emails, damit niemand 100 ähnliche Emails auf einmal erhält.
Etliche Tickets können Sie wahrscheinlich auch auf eigene Faust schließen, weil sie zu weit in der Zukunft liegen. Kommentar: “Wir haben beschlossen, dass dieses Thema im Zeithorizont von 12 Monaten nicht angefangen wird. Daher schließen wir dieses Ticket.” Falls der Inhalt erhalten bleiben soll: Behalten Sie Links auf diese Tickets in einem Dokument. Manchmal kann man auch ein spezielles Release definieren “Someday, maybe” und alles dorthin verschieben.
Wenn die Anzahl offener Tickets zu weit weg ist vom vereinbarten Limit, können Sie das ganze auch schrittweise angehen. Setzen Sie ein zeitweises Limit und verringern Sie es nach einem festen Zeitplan. Im Beispiel hätten wir die 735 offenen Tickets schrittweise verringern können, indem wir das Limit bei 700 starten und es dann pro Woche um 50 absenken. Nach ungefähr einem Quartal ist das geplante Limit von 60 offenen Tickets dann in Reichweite.
Die Warteschlange im Auge behalten. Hängen Sie eine Grafik auf: Länge der Warteschlange (Anzahl offene Tickets) über die Zeit. Zeichnen Sie das vereinbarte Limit für die Anzahl Tickets ein. Sie können das gern annotieren mit besonderen Ereignissen auf der Zeitachse, wie Releases oder Maßnahmen aus den vorigen Schritten.
Reagieren, sobald die Warteschlange nahe am Limit ist. Im Supermarkt sehe ich manchmal ein Schild für die Kassiererinnen: “Mehr als 3 Kunden? Neue Kasse öffnen.” Wenn die Schlange zu lang ist, wird also zusätzliche Kapazität aktiviert. Das ist ein Weg, um die Länge zu begrenzen. Ein anderer Weg: keine neue Arbeit annehmen – “Wir sind an der Kapazitätsgrenze, daher nehmen wir keine neuen Tickets an”. Alternative: Wer ein Ticket hinzufügen will, muss auf ein anderes verzichten.
Ursachen angehen. Haben Sie immer noch eine wachsende Warteschlange, weil neue Tickets schneller reinkommen, als sie abgearbeitet werden? Wenn es zu viele Bug-Reports gibt: investieren Sie in Qualität. Wenn zu oft beim Deployment etwas schief geht: investieren Sie in Automatisierung, Checklisten, Schulung u.ä.
Sollen wir auch das Backlog verkürzen? Je nachdem, welche Erwartungen man damit verbindet. Wenn “Ist im Backlog” bedeutet “Machen wir irgendwann”, dann ist es auch eine Warteschlange. Wenn aber allen Beteiligten klar ist: “Irgendwann ist das Projekt zu Ende und was dann noch im Backlog ist, wird eben nicht gemacht”, dann ist es nur ein Mechanismus zur Priorisierung. Ich meine: Wenn 700 Einträge im Backlog sind, macht man auch etwas falsch. Eine häufige Ursache für eine Vielzahl an Einträgen ist die verfrühte Aufgliederung eines Themas. Je weiter weg ein Feature ist, desto gröber sollte seine Beschreibung im Backlog sein, desto weniger Einträge belegt es also im Backlog.
Verfallsdatum für Tickets? Die Idee: offene Tickets werden automatisch geschlossen, wenn es länger als X Monate keine Aktivität gab. Halte ich nicht für gut, weil dann einzelne Tickets manuell am Leben erhalten werden (müssen) und weil möglicherweise relevantes Material verloren geht. Ein Report “Tickets, die seit X Monaten nicht geändert wurden” ist natürlich sinnvoll. Den kann man in regelmäigen Abständen ansehen und dabei schnell Kandidaten für zu schließende Tickets finden.
Offenbarungseid? Die drastische Variante: Ab heute ignorieren wir das bestehende Ticket-System. Statt aufzuräumen fangen wir wieder bei Null an, wer unbedingt will, kann sich ja etwas aus dem alten System kopieren. Wichtige Themen kommen wieder, frische Probleme werden im neuen System verwaltet. Ich hatte jedenfalls manchmal das Gefühl, dass es kein Weltuntergang wäre, wenn das alte Ticket-System sich über Nacht in Rauch auflösen würde.
Wenn Sie es so machen wollen, bedenken Sie bitte die Außenwirkung: es wirkt unprofessionell, und einige werden denken, dass ihre Zuarbeit für das Ticket-System (Fehlerbeschreibungen, Ideen…) umsonst war. O-Ton: “Wenn Ihr [Entwickler] das macht, dann schreibe ich nie wieder etwas für Euch auf!”.
Es besteht natürlich die Gefahr, dass Sie nach einiger Zeit wieder in einer Situation landen, wo Sie einfach zu viele offene Tickets haben. Sie sollten also zukünftig etwas anders machen als in der letzten Runde.
Über die Feiertage haben Sie hoffentlich etwas Zeit und Muße. Vielleicht ja auch Lust, die von uns behandelten Themen aus einem anderen Blickwinkel zu betrachten. Daher wollen wir bis Anfang Januar den SoftwareLiefern.de Newsletter etwas anders gestalten: Wir geben Ihnen an jedem Wochentag eine Empfehlung zu Büchern oder Vorträgen, die für uns besonders spannend, lehrreich oder auch amüsant waren. Es wird sozusagen unsere persönliche Hitliste des Jahres 2018, in der Hoffnung, dass für Sie etwas Interessantes dabei ist.
Matthias Berth