Daniel S. Vacanti ist ein Softwareveteran. Er hat als Java Developer/Architect begonnen und arbeitet seit über 15 Jahren mit Lean und Agile-Methoden. Dan war ganz wesentlich daran beteiligt, Kanban zu entwickeln, und war 2007 im ersten Kanban-Projekt involviert. Mit seinem Unternehmen „Actionable Agile“ hat er sich auf Prognose-Tools spezialisiert und er ist der unbestrittene Meister flussbasierter Metriken.

Klaus: Du bist einer der Experten für flussbasierte Metriken und du hast dich mit Little’s Law intensiv beschäftigt. Warum ist Little’s Law so wichtig?

Dan: Die kurze Antwort lautet: Es ist nicht wichtig. Oder besser gesagt, es ist nicht auf die Art und Weise wichtig, wie viele Leute denken. Vergiss einfach die Mathematik. Meistens wird Little’s Law deterministisch verwendet: Die Zahlen werden eingesetzt und Little’s Law spuckt dann die Antwort aus. Bei dieser Herangehensweise gibt es zwei Probleme:

1. Little’s Law blickt in die Vergangenheit, nicht in die Zukunft – dazu später mehr.
2. Little’s Law ist in Kontexten hilfreich, in denen man nur zwei Metriken messen kann, während die dritte zu schwierig, zu teuer oder zu schwierig und zu teuer zu messen ist. In unserer Welt ist es sehr einfach, alle drei Flussmetriken zu messen, also sollte man Little’s Law nie für Berechnungen nutzen. Die fehlende Flussmetrik selbst genau zu messen, ist in diesem Fall der richtige Weg.

Trotzdem ist es wichtig, die Annahmen zu verstehen, die zusammenspielen müssen, damit Little’s Law funktioniert. Es ist nicht nur eine Gleichung, es ist eine Gleichung und ein Set von Annahmen. Mein Rat ist: Vergesst die Gleichung und fokussiert euch auf die Annahmen. Denn sie sind eine Richtschnur für die Policies, die zuerst etabliert sein müssen, damit ein Prozess vorhersagbar wird. Natürlich unter der Annahme, dass man auf Vorhersagbarkeit Wert legt.

Klaus: Wenn es um Metriken geht, wollen die meisten gleich mitten in sexy Themen wie das probabilistische Forecasting springen. Ist das deiner Meinung nach ein guter Startpunkt?

Dan: Das Problem dabei ist meistens, dass man für Dinge wie Monte-Carlo-Simulationen das Wissen um die Systemstabilität voraussetzen muss. Hier zeigt Little’s Law, was in ihm steckt. Folgt der Prozess den Annahmen von Little’s Law, dann weist der Prozess auch eine gewisse Stabilität auf und man kann allmählich damit beginnen, ausgefeiltere Techniken wie eben eine Monte-Carlo-Simulation ins Spiel zu bringen. Wenn aber der Prozess die Annahmen von Little’s Law immer wieder bricht, dann ist der Prozess per definitionem instabil und jegliche Art von Forecast – ob probabilistisch oder anders – ist äußerst fragwürdig. Deswegen gefällt mir auch dein Ansatz in diesem Buch sehr gut: Du etablierst zunächst eine sehr einfache Metrik, um Feedback über die Stabilität des Systems zu bekommen.

Klaus: Die eigentliche Formel zu Little’s Law lautet L = λ×W, aber wir verwenden DLZ=WIP/DS (DLZ: Durchlaufzeit; DS: Durchsatz). Worin liegt der Unterschied bzw. was sind die Konsequenzen daraus?

Dan: Eigentlich sind beide Formeln legitime Definitionen von Little’s Law, wenn man davon ausgeht, dass die Beziehung von Durchschnittswerten betrachtet wird. Der Unterschied liegt in der Perspektive: L = λ×W betrachtet den Prozess aus der Sicht der Ankünfte im System. DLZ=WIP/DS beleuchtet den Prozess hingegen aus der Sicht der Abflüge. Obwohl beide Formeln Little’s Law repräsentieren, macht der Wechsel der Perspektive den großen Unterschied. Wie ich bereits gesagt habe, gibt es zwei Seiten: die Gleichung und die Annahmen hinter der Gleichung. Die Annahmen hinter DLZ=WIP/DS sind andere als bei L = λ×W. Das ist wichtig zu wissen, denn wie ich gesagt habe, versteht man Little’s Law nur, wenn man die Annahmen dahinter versteht. Zuerst muss man sich darüber im Klaren sein, ob man sich mehr um die Ankünfte oder um die Abflüge kümmern will, denn diese Perspektive hat Einfluss auf alle Policies, die man für Vorhersagen heranzieht.

Klaus: Wie können die Leser und Leserinnen dieses Buchs Little’s Law in ihrer täglichen Arbeit mit Kanban-Systemen einsetzen?

Dan: Indem sie die Annahmen dahinter verstehen und in ihren Prozessen Policies etablieren, durch die diese Annahmen nur minimal verletzt werden. Wie gesagt, wenn die Vorhersagbarkeit eine wesentliche Rolle spielen soll.

Klaus: Wie sehen diese Annahmen also aus?

Dan: Wenn man die Durchsatzversion von Little’s Law verwendet, geht man von den folgenden fünf Annahmen aus:

1. Die durchschnittliche Input- bzw. Ankunftsrate sollte gleich wie die durchschnittliche Output- oder Abflugsrate sein.
2. Jede Arbeit, die gestartet wird, wird irgendwann fertiggestellt und verlässt das System auch wieder.
3. Der Work in Progress sollte am Anfang und am Ende des für die Berechnung herangezogenen Zeitintervalls einigermaßen gleich sein.
4. Das durchschnittliche Alter des Work in Progress nimmt weder zu noch ab.
5. Durchlaufzeit, Work in Progress und Durchsatz müssen mit konsistenten Einheiten gemessen werden. Man sollte also zum Beispiel nicht für die Durchlaufzeit den Tag als Einheit verwenden und für den Durchsatz die Woche.

Am besten ist es, sich einen Moment Zeit zu nehmen und über den eigenen Prozess nachzudenken: Hat man die Ankunfts- und Abflugsrate von Arbeit im Auge oder kommt Arbeit schneller ins System, als sie fertiggestellt wird? Um das festzustellen, kann man zum Beispiel die in diesem Buch vorgestellte Stabilitätsmetrik verwenden. Achtet man darauf, wie alt die Arbeitseinheiten sind, an denen gerade gearbeitet wird, oder bleiben Arbeiten über willkürliche Zeitspannen liegen? Wenn man sich diese Dinge nicht ansieht, bricht man die Prinzipien von Little’s Law. Jedes Mal, wenn man einer der grundlegenden Annahmen zuwiderhandelt, wird der Prozess instabiler. Je instabiler der Prozess wird, desto schwieriger wird es, einen genauen Forecast zu erstellen. In meinem Buch „Actionable Agile Metrics for Predictability“ geht es in erster Linie darum, stabile Prozesse auf Basis von Little’s Law zu schaffen, um genaue Forecasts erstellen zu können.

Klaus: Warum kann man nicht einfach die Formel von Little’s Law verwenden, um Forecasts zu erstellen?

Dan: Das hat zwei Gründe. In erster Linie kann man mit Little’s Law keine Forecasts anstellen, weil Dr. Little selbst gesagt hat, dass man es nicht kann: „However, let it be noted that the determinism and exactness are after the fact, i.e., the sample path is known. This is not all bad. It just says that we are in the measurement business, not the forecasting business.” Wer Little’s Law für das Forecasting einsetzen will, ist auf dem Holzweg, weil es speziell für den Rückwärtsblick auf Basis bereits gesammelter Daten entwickelt wurde – nicht für eine Vorausschau, bei der es viele verschiedene Ausgänge geben kann.

Aber selbst wenn man Little’s Law für das Forecasting einsetzen könnte, würde man das nicht wollen. Es basiert auf dem Verhältnis von Durchschnitten. Es gibt ein exzellentes Buch, das diesen Punkt detailliert behandelt: „The Flaw of Averages“ (vgl. Savage 2012). Das Tückische an den Durchschnitten ist im Wesentlichen, dass auf Durchschnitten basierende Pläne im Durchschnitt scheitern. Selbst wenn man einfach zwei Zahlen in die Formel einsetzen könnte, damit sie eine dritte Zahl als Forecast ausspuckt, sollte man im Hinterkopf behalten, dass die dritte Zahl nur einen Durchschnitt angibt – und Durchschnitte haben für einen Forecast keinen Nutzen.

Klaus: In deinem Buch schreibst du über „Flow debt“ – auf Deutsch könnte man etwas holprig „Flussschuld“ dazu sagen. Kannst du erklären, was du damit meinst?

Dan: Flow debt bedeutet einfach, dass man sich Durchlaufzeit von einer Arbeitseinheit im Arbeitsprozess „leiht“, um sie einer anderen Arbeitseinheit im Arbeitsprozess zu geben. Kurzfristig kann man den Prozess dadurch beschönigen, weil bestimmte Arbeiten schnell durch den Prozess gepusht werden. Langfristig trägt diese Strategie aber nur dazu bei, den Prozess weniger vorhersagbar zu machen. Express-Tickets sind dafür das beste Beispiel: Sobald Teams eine Express-Anfrage bekommen, unterbrechen sie meistens das, woran sie gerade arbeiten. Natürlich hat diese Policy den Vorteil, dass die Express-Tickets im Prozess schneller vorankommen und die Durchlaufzeit dieser Arbeitseinheiten sieht auch gut aus. Diese schöne Durchlaufzeit hat aber ihren Preis: Bei allen anderen Arbeiten, die für das Express-Ticket gestoppt wurden, erhöht sich die Durchlaufzeit. Irgendwann muss diese Schuld beglichen werden und das passiert in Form von schlechterer Durchlaufzeit der verspäteten Arbeiten, wenn sie dann endlich fertiggestellt werden. Bessere Durchlaufzeit, die zum Preis schlechterer Durchlaufzeit erkauft wird, bezeichne ich als „Flow debt“. Jedes Mal, wenn man bestimmte Arbeitseinheiten in einem bereits laufenden Arbeitsprozess bevorzugt behandelt, entsteht Flow debt. Der Preis, den man dafür bezahlt, ist die wachsende Unvorhersagbarkeit des Systems.

---

Dieses Interview ist ein Auszug aus dem Buch Kanban in der Praxis, erschienen im November 2016 im Hanser Verlag.