Was ist Flow Debt?

Flow Debt (dt. Flow-Schuld) ist ein auf Daniel Vacanti zurückgehender Begriff, der an die Idee der Technischen Schulden angelehnt ist. Sie ist ein Leading Indicator, der signalisiert, wie gut es um Euren Kanban Workflow bestellt ist und ob Dein Team (auf Kosten bereits begonnener Work Items) anderen Dingen den Vorzug gibt. Denn in solchen Fällen leiht sich Dein Team Zeit, die es jedoch später zwangsläufig zurückzahlen muss.

Was Flow Debt genau meint, wie sie entsteht und wie Du sie mit Deinem Kanban Team messbar machen kannst, erfährst Du in diesem Blogartikel.

Flow Debt bedeutet, dass die Cycle Time von Work Items reduziert oder niedrig gehalten wird, indem andere, bereits begonnene Work Items liegengelassen werden. In solchen Fällen beschleunigt Dein Team also Aufgaben auf Kosten anderer, die dann nicht weiter vorankommen.

Natürlich kann es diverse Ursachen dafür geben, dass Flow-Schuld entsteht. Etwa weil sich Prioritäten verschoben haben oder weil Blocker und andere Unterbrechungen dazu führen, dass es an bestimmten Stellen nicht weitergeht und dafür neue Dinge begonnen werden.

Außerdem kann es durchaus sinnvoll sein, Flow Debt einzugehen. Allerdings ist das Dilemma das gleiche wie bei Technischer-Schulden: Irgendwann muss Dein Team die von anderen Work Items geliehene Zeit zurückzahlen

Dabei ist das Zurückzahlen der Flow-Schuld nicht zwangsläufig das größte Problem an der Sache. Vielmehr macht sie Euren Workflow weniger vorhersagbar, sodass eine hohe Flow Debt irgendwann auch Auswirkungen auf die Aussagekraft Eurer Service Level Expectation haben wird. Das macht dann den Forecast mehr oder weniger zum Blick in die Glaskugel.

Der häufigste Grund für die Entstehung von Flow Debt sind sicherlich dringende Work Items. Also alle Aufgaben, die in den Workflow Deines Teams hineinströmen und bevorzugt bearbeitet werden müssen bzw. sollen. Denn jede dieser Aufgaben führt natürlich dazu, dass andere, bereits begonnene (aber weniger wichtige) Aufgaben liegenbleiben.

Dieser Umstand lässt sich auch durch die Nutzung einer eigenen Swimlane für dringende Aufgaben nicht umgehen. Aber zumindest ist die Visualisierung ein erster Schritt in die richtige Richtung. Denn auf diese Weise kann Dein Team später ermitteln, wie viele solcher Tickets in einem bestimmten Zeitraum (zum Beispiel in den letzten 2 Wochen) anfallen und dann Maßnahmen ergreifen, die Entstehung solcher Notfälle zu reduzieren oder bestenfalls sogar ganz zu eliminieren.

Der zweite Grund für die Entstehung von Flow Debt sind geblockte Work Items. Denn immer dann, wenn es irgendwo nicht weitergeht, weil Abhängigkeiten oder Impediments auftauchen, werden sich die Mitglieder Deines Teams anderen Aufgaben zuwenden, damit sie nicht Däumchen drehen müssen. Dieser Umstand führt jedoch dazu, dass begonnene Work Items künstlich altern, während sie im Work In Progress Eures Workflows verbleiben.

Flow Debt lässt sich recht einfach sicht- bzw. messbar machen: Sie ist die Differenz zwischen ungefährer durchschnittlicher Cycle Time und exakter durchschnittlicher Cycle Time. Ja, richtig gelesen! Es existieren zwei unterschiedliche Werte für die Cycle Time eines Kanban Workflows. (Und leider sind sich nicht unbedingt alle Kanban Teams wirklich darüber bewusst.)

Stell Dir vor, Dein Kanban Team ermittelt seine Cycle Time immer rückblickend für die letzten zwei Wochen. Diese lässt sich berechnen, indem alle abgeschlossenen Work Items begutachtet werden und aus der Summe aller Zykluszeiten dieser Work Items ein Durchschnittswert berechnet wird.

Diese Cycle Time ist die exakte durchschnittliche Cycle Time (engl. exact average Cycle Time).

Was die Cycle Time, die Du über das Scatterplot ermitteln kannst, jedoch nicht beachtet, ist die Tatsache, dass sich im Workflow Deines Teams noch aktive Work Items befinden, die dort eventuell festhängen. Und um genau die geht es ja. Denn je später diese abgeschlossen werden, desto älter sind sie dann und desto stärker werden sie Eure Cycle Time negativ beeinflussen.

Die ungefähre durchschnittliche Cycle Time lässt sich über das Cumulative Flow Diagram ermitteln. Denn auf diesem Kanban Chart lässt sich die Zykluszeit als horizontale Linie ermitteln, die beim ersten aktiven Arbeitsstatus beginnt und endet, wenn sie auf die Linie Done bzw. Fertig trifft.

Dadurch umfasst die mit Hilfe des CFD ermittelte Cycle Time auch diejenigen Work Items, die sich noch im Work In Progress befinden!

Wenn Du die Flow Debt Deines Teams über den Vergleich von ungefährer vs. exakter (durchschnittlicher) Cycle Time errechnest, erhältst Du einen guten Indikator dafür, in welche Richtung sich die (exakte) Cycle Time Deines Teams entwickeln wird. Denn wenn die ungefähre (durchschnittliche) Cycle Time größer ist als die exakte (durchschnittliche) Cycle Time, wird sich letztere früher oder später ebenfalls erhöhen.

Sind jedoch beide Metriken in etwa gleich, kannst Du sicher sein, dass die exakte Cycle Time und die daraus resultierende Service Level Expectation bzw. Euer Forecast verlässlich sind.

Neben der direkten Berechnung von Flow Debt kannst Du die exakte (durchschnittliche) Cycle Time Deines Teams auch mit der aktuellen (durchschnittlichen) Work Item Age vergleichen. Denn auch diese Kanban-Metrik ist ein guter Indikator für Dich, in welche Richtung sich Durchlauf- und Zykluszeiten Eures Workflows entwickeln werden.