Flow mit Hilfe von Metriken beherrschen
17. Februar 2022
Um den Flow beherrschbar zu machen, braucht es Transparenz. Die erreicht man wiederum am besten mit Metriken. Allerdings sind diese für manchen Softwareentwickler ein rotes Tuch. Kein Wunder, werden Metriken leider viel zu häufig auch aus eine unguten Art und Weise verwendet. Deshalb soll dieser Artikel einen auch durchaus kritischen Blick auf das Thema Metriken werfen.
Im ersten Teil dieser Artikelserie wurde beschrieben, wie Softwareentwicklungsteams vom Thema Flow profitieren können und dass es dabei wichtig ist, diesen Flow aktiv zu managen. Dazu ist vor allem Transparenz notwendig. Eine Transparenz, die es erlaubt, Handlungsbedarfe und Optimierungsmöglichkeiten zu identifizieren. Wie diese Transparenz erreicht werden kann, welche Metriken dazu genutzt werden können und wie man diese interpretiert, darum soll es in diesem zweiten Teil der Serie gehen.
Metriken - Teufelszeug oder unverzichtbares Hilfsmittel?
Bevor im Folgenden ein Blick auf konkrete Metriken und deren Nutzen im Kontext von Flow geworfen wird, seien hier noch ein paar allgemeine überlegungen zum Thema erlaubt. Schließlich haben viele Softwareentwickler ein eher gespaltenes Verhältnis zum Thema Metriken. Der Autor selbst hat viele Situationen erlebt, in denen Metriken in einer unguten Art eingesetzt wurden. Metriken sind unbestritten ein wichtiges Hilfsmittel, um eine objektive Transparenz über Abläufe, Verbesserungsbemühungen und Systeme zu erhalten. Jedoch muss man sich zunächst dessen bewusst sein, dass das Messen von Metriken auch das System selbst beeinflusst, und oftmals ist genau diese Beeinflussung ein gewünschter Effekt. Wenn beispielsweise die Anzahl der gemeldeten Bugs pro Zeiteinheit als Metrik erhoben wird, ist die Motivation dahinter ja auch, dass dadurch die Sensibilität für das Thema Qualität erhöht wird und dadurch die Anzahl der Bugs sinkt - soweit die Theorie. Leider kann man aber in der Praxis sehr häufig beobachten, dass die Nutzung von Metriken als Zielvorgabe unerwünschte Effekte auslösen kann und damit zum Teil dem eigentlichen Ziel sogar entgegenwirkt. So könnte in dem genannten Beispiel eine Reaktion auch sein, dass Bugs vermehrt "wegdiskutiert" und als Features deklariert werden. Oder es wird seltener an Anwender ausgeliefert, um keine neuen Bugs zu provozieren. Natürlich wird dadurch das Risiko nur auf einen späteren Zeitpunkt aufgeschoben, aber die Metrik wird zunächst verbessert. Wenn die Anzahl der Unit-Tests oder die Code-Coverage als Ziel ausgegeben wird, wird man viele Tests erhalten, aber damit möglicherweise nicht die Qualität des Produktes verbessern. Im Gegenteil, die hohe Testabdeckung kann zu einem falschen Gefühl der Sicherheit führen. Metriken können auch zur überbetonung von Teilaspekten führen. Das bedeutet, dass eine Verbesserung in diesem Bereich zu Lasten von anderen Bereichen geht und das Gesamtsystem dadurch eher beeinträchtigt wird. Als letzter Aspekt sei hier noch erwähnt, dass Metriken selbst niemals zu einer Verbesserung führen, sondern lediglich dabei unterstützen können, frühzeitig die richtigen Fragen zu diskutieren. Um die Hinweise, die durch Metriken transparent werden, in konkrete Aktionen umzusetzen, braucht es Zeit. Zeit, um die Metriken richtig zu interpretieren, nach Ursachen zu forschen und konkrete Verbesserungen zu erarbeiten und umzusetzen. Eine Aussage wie "Die Anzahl der Bugs ist zu hoch, sie muss wieder runter" ist wenig hilfreich und wird höchstens dazu führen, dass die Zahlen "massiert" werden, aber keine prozessuale Verbesserung hervorbringen.
Deshalb hier ein paar Tipps, die beim Einsatz von Metriken berücksichtigt werden sollten:
- Metriken nicht als Zielvorgaben nutzen, sondern dafür, um eine möglichst unverfälschte Transparenz zu schaffen.
- Metriken sollten durch alle Beteiligten gemeinsam vereinbart werden und nicht "von oben" vorgegeben werden.
- Möglichst verschiedene Metriken erheben, um eine systemische Sicht zu erhalten und lokale Optimierungen zulasten des Gesamtergebnisses zu vermeiden.
- Freiräume schaffen, damit aus den Metriken konkrete Handlungsoptionen abgeleitet und umgesetzt werden können.
Flow-Metriken
Im Folgenden wollen wir nun vier grundlegende Metriken im Zusammenhang mit Flow betrachten. Wie bereits erwähnt, sollten diese mit anderen Metriken, z.B. zur Qualität, Kundenzufriedenheit und anderen ergänzt werden. Der Fokus dieses Artikels soll jedoch bewusst auf das Thema Flow begrenzt werden. Die folgenden Metriken haben dabei allesamt den Charme, dass sie sich sehr einfach ermitteln lassen. Es mag dabei erstaunen, dass keine dieser Metriken die Größe der Arbeitselemente berücksichtigt. Die vorgeschlagenen Metriken lassen sich aus dem Messen der Zeit und durch einfaches Zählen von Aufgabenelementen ermitteln. Das bedeutet, dass ein Schätzen der Größe von Aufgabenelementen für die Erhebung dieser Metriken gar nicht notwendig ist. Aber kann das denn überhaupt funktionieren, wenn wir die Größe ignorieren? Verfälscht das die Aussagekraft nicht? Tatsächlich haben unterschiedliche Untersuchungen ergeben, dass es keine signifikanten Unterschiede in Bezug auf die Prognosegüte im Vergleich zu schätzbasierten Werten gibt. Es stellt sich also die Frage, ob der Aufwand für die Größenschätzung überhaupt gerechtfertigt ist, oder nicht vielleicht einen Ungenauigkeitsfaktor mehr hinzufügt. Dieser Punkt soll an dieser Stelle jedoch nicht weiter vertieft werden, es sei stattdessen auf die umfangreichen Quellen zum Thema #NoEstimates verwiesen. Letztendlich könnten die hier vorgestellten Metriken auch mit Größeneinheiten kombiniert werden. Es soll lediglich aufgezeigt werden, dass das nicht zwingend notwendig ist und jedes Team hier sein präferiertes Vorgehen festlegen kann.
Cycle Time
Die Cycle Time, zu Deutsch die Durchlaufzeit, beschreibt die Zeit, die ein Element benötigt, um unseren Workflow zu durchlaufen. Dabei ist die Definition des Starts und des Endes unseres Workflows wichtig, wie bereits im ersten Teil der Artikelserie beschrieben. Es kann jedoch auch sinnvoll sein, Teilabschnitte der Cycle Time gesondert zu betrachten, also beispielsweise die Zeit, die die Implementierung und das Testen in Anspruch nehmen. Manche Teams nutzen mehrere Cycle Times, um verschiedene Bereiche des Workflows zeitgleich zu betrachten. Die Cycle Time wird üblicherweise für jedes Work Item ermittelt und kann in einem Cycle Time Scatter Plot visualisiert werden. Daraus lässt sich dann eine durchschnittliche Cycle Time für einen bestimmten Zeitabschnitt oder auch für einen bestimmten Typ von Elementen errechnen. Ebenso lassen sich Gruppen bilden, bei denen die Cycle Time, die beispielsweise für 85 Prozent aller Elemente gilt, woraus sich dann die im ersten Teil beschriebene Service Level Expectation (SLE) ableiten lässt. Mit Hilfe der Cycle Time und dem Cycle Time Scatter Plot lassen sich interessante Fragestellungen aufbringen bzw. beantworten. So kann aus empirischen Daten abgeleitet werden, wann ein wichtiges Feature oder ein dringender Bug voraussichtlich abgeschlossen sein wird, wenn unmittelbar mit der Umsetzung begonnen wird. Ein System, das einen guten Flow mit kurzen Durchlaufzeiten aufweist, bietet den Vorteil, dass auch dann der Standardprozess genutzt werden kann, wenn es mal schnell gehen muss. Es müssen keine Sonderregelungen getroffen werden, Konstrukte wie eine "Express-Lane" und ähnliches werden überflüssig. Ebenso können bestehende empirische Daten für Vorhersagen genutzt werden. Dringende Elemente werden lediglich entsprechend hoch priorisiert und damit umgehend umgesetzt.
Darüber hinaus lohnt sich auf jeden Fall auch ein Blick auf die Varianz im Scatter Plot. Warum haben einige Elemente eine deutlich längere Durchlaufzeit als andere? Was unterscheidet diese Elemente? Waren diese übermäßig groß oder gab es bei der Umsetzung Blocker, die die Fertigstellung verzögert haben? Wie kann das System verbessert werden, um die Cycle Time zukünftig zu reduzieren? Durch eine reduziertere Varianz ergibt sich ein viel gleichmäßigerer Fluss im Workflow, was insgesamt die Effizienz positiv beeinflusst. Zudem ist die Vorhersagbarkeit wesentlich exakter, wenn die Varianz der einzelnen Elemente gering ist. Es lohnt sich also auf jeden Fall, die Varianz zu reduzieren. Der Scatter Plot visualisiert die Fortschritte in dieser Richtung. Selbstverständlich ist es auch hilfreich, auf dem Scatter Plot die Elemente näher zu betrachten, die eine sehr kurze Cycle Time haben. Lassen sich daraus bestimmte Muster ableiten? Können diese auch auf andere Elemente übertragen werden? Wirken sich bestimmte Vorgehensweisen wie z.B. Mob-Programming positiv auf die Cycle Time aus?
Flow und Cycle Time vs. Auslastung
In traditionellen Systemen werden Prozesse oftmals auf Auslastung hin optimiert. Wenn alle Beteiligten möglichst keine Leerlaufzeiten haben und jederzeit beschäftigt sind, so die zugrundeliegende Annahme, dann ist das System maximal effizient. Leider ist das jedoch ein Trugschluss. In seinem Buch "The Goal" beschreibt Eliyahu M. Goldratt warum eine hohe Auslastung zu höheren "Wait-Times" führt und damit der Flow und die Effizienz des Systems gemindert wird. Eine einfache mathematische Formel stell diesen Zusammenhang dar:
Wartezeit = Auslastung / (100%-Auslastung)
Das bedeutet, dass bei einer Auslastung von 50 Prozent die Wartezeit eine Zeiteinheit ist, während bei einer Auslastung von 98 Prozent die Wartezeit bereits 49-mal so hoch ist, nämlich 49 Zeiteinheiten. Aus diesem Zusammenhang lässt sich schließen, dass ein System niemals voll ausgelastet werden sollte. Eine Erkenntnis, die Softwareentwicklern nicht fremd sein sollte. Schließlich ist eine CPU, die zu 98 Prozent ausgelastet ist, auch nicht besonders effizient und es werden weniger Operationen durchgeführt als bei einer niedrigeren Auslastung.
Work in Process / Work in Progress
Warum eine kurze Cycle Time grundsätzlich erstrebenswert ist, wurde im ersten Teil der Serie im Kontext der Flow-Prinzipien beschrieben. Neben der Möglichkeit, die Aufgabenelemente entsprechend kleiner zu schneiden, gibt es auch die Möglichkeit, durch eine Reduktion von WIP (Work in Process / Work in Progress) die Cycle Time zu verkürzen. Deshalb ist WIP die zweite Metrik, die hier betrachtet werden soll. Dazu wird einfach gezählt, wie viele Elemente aktuell in Bearbeitung sind. Dabei ist wichtig, ab wann wir etwas als in Process betrachten. Die Antwort darauf gibt die Definition unseres Workflows, der Start und Ende festlegt. Wichtig ist, dabei auch die Elemente einzubeziehen, die aktuell blockiert sind oder an denen aus anderen Gründen momentan nicht gearbeitet wird. Wenn also eine Aufgabe nicht bearbeitet wird und stattdessen an anderen Elementen begonnen wird, zu arbeiten, dann erhöht das den Work in Process.
Die Work in Process kann nun als Diagramm visualisiert werden, bei dem der entsprechende Wert über eine Zeitachse eingetragen wird. Somit werden Phasen deutlich, in denen das WIP hoch bzw. niedrig ist und es kann analysiert werden, was zu diesem jeweiligen Zustand geführt hat und was daraus gelernt werden kann. Gibt es in Phasen mit hohem WIP üblicherweise viele Blocker? Ist das WIP immer dann besonders hoch, wenn jemand im Urlaub ist und sich Elemente deshalb an bestimmten Stellen im Workflow stauen? In welchen Phasen des Workflows ist die WIP verhältnismäßig hoch und was kann dagegen unternommen werden? Die Visualisierung von WIP sollte vom Team regelmäßig auf Auffälligkeiten hin bewertet werden, z.B. im Daily Scrum. Hier kann schnell und einfach erkannt werden, dass das WIP sich gerade auf einem Level befindet, das eine Diskussion im Team auslösen sollte. Gibt es triftige Gründe, momentan ein höheres WIP zu akzeptieren? Was könnte unternommen werden, um das WIP zu senken? Gibt es systemische Ursachen bzw. Störungen in unserem Flow, auf deren Behebung sich das Team fokussieren sollte? So können bestimmte Tendenzen frühzeitig erkannt und schnell gegengesteuert werden.
Product Backlog bei Cycle Time und WIP einbeziehen -
macht das Sinn?
Bei Diskussionen, wann die Cycle Time gestartet werden soll und welche Bereiche des Workflows damit als "in Process" betrachtet werden, wird das Product Backlog meist sehr schnell ausgeschlossen. Schließlich stellt für die meisten Teams die Zeit, die ein Element im Product Backlog wartet, bis es endlich bearbeitet werden kann, den weitaus größten Teil der gesamten Durchlaufzeit dar. Richtig ist, dass sich dadurch die Aussagen verändern, die sich aus der Cycle Time ablesen lassen. Dennoch ist es spannend, auch mal einen Blick auf eine Cycle Time inkl. des Product Backlog zu werfen. Schließlich ist das genau die Sicht von Stakeholdern und Kunden. Wie lange dauert es, bis ein neues Feature genutzt werden kann, das sich ein Kunde gewünscht hat und das ins Product Backlog aufgenommen wurde? Das hängt natürlich von der Wichtigkeit und damit der Sortierung im Backlog ab. Aber wenn das Monate oder gar Jahre dauern könnte, wäre es dann nicht ehrlicher, das Feature erst gar nicht in das Backlog aufzunehmen? Sollte das Backlog nicht einfach nur die Arbeit enthalten, die wir in einem überschaubaren Zeitraum umsetzen können? Und was bedeutet es, wenn unser WIP unter Berücksichtigung des Backlogs kontinuierlich ansteigt? Das würde ja bedeuten, dass dauerhaft mehr Arbeit angenommen wird, als abgearbeitet werden kann. Somit kann die Betrachtung inkl. dem Product Backlog durchaus spannende und hilfreiche überlegungen initiieren. äquivalent dazu, sollte auch überlegt werden, ob das Deployment in die Produktivumgebung nicht auch Teil von WIP und Cycle Time sein sollte.
Work Item Age
Die Cycle Time wird erst beim Abschluss eines Elements ermittelt. Damit lassen sich aus der Cycle Time prozessuale Aussagen ableiten. Für das jeweilige Element lässt sich nachträglich aber nichts mehr optimieren. Deshalb betrachtet Work Item Age das aktuelle Alter eines Elements, also die Zeit, die dieses Element bereits in Bearbeitung ist. So lassen sich bereits bei der Bearbeitung Tendenzen erkennen und entsprechende Maßnahmen einleiten. Die Cycle Time ist somit das Alter des Elements zum Zeitpunkt des Abschlusses. Aus empirischen Daten kann ermittelt werden, welches Alter ein Element in den verschiedenen Phasen des Workflows nicht überschreiten sollte, damit die Service Level Expectation (SLE) noch eingehalten werden kann. Somit dient die häufige Auswertung des Work Item Age einer verlässlicheren Erfüllung der SLE und damit einer verlässlicheren Aussage über den Lieferzeitpunkt von Arbeitselementen.
Throughput
Als vierte Metrik soll hier noch der Throughput, also der Durchsatz des Systems betrachtet werden. Diese Metrik gibt an, wie viele Elemente in einer bestimmten Zeiteinheit (beispielsweise innerhalb eines Sprints) fertiggestellt werden konnten. Der Throughput ist damit vergleichbar zur wesentlich bekannteren Velocity, die viele Teams nutzen. Jedoch ist der Throughput unabhängig von der Größe der Elemente. Hier wird lediglich die Anzahl der Elemente betrachtet. Was zunächst nicht besonders erstrebenswert klingen mag, hat vor allem aus einer Flow-Sicht durchaus seinen Charme. Beginnen Teams nämlich, den Throughput zu messen, so ist die einfachste Möglichkeit, diesen zu erhöhen, das Aufsplitten der Aufgabenelemente in mehrere kleinere Unterelemente. Bricht man ein Element in fünf kleinere herunter, so ist nach Abschluss der Elemente der Throughput 5, während beim Bearbeiten als ein großes Element der Throughput nur 1 wäre. Das ist aber aus einer Flow-Perspektive ein durchaus erwünschter Effekt. Diese kleineren Elemente haben eine kürzere Cycle Time, es entsteht früheres Feedback, die Transparenz über den Fluss steigt und es ergeben sich mehr Möglichkeiten, zu reagieren, wenn es andere dringende Dinge zu tun gibt. Oftmals stellt sich auch heraus, dass eine der fünf Teilaufgaben vielleicht gar nicht so wichtig ist. Man kann diese dann auf später verschieben oder gar ganz streichen. Alles wünschenswerte Effekte. Voraussetzung dafür ist allerdings, dass die Elemente dabei vertikal geschnitten werden, d.h. dass sie für sich gesehen eine validierbare, idealerweise auslieferbare Einheit bilden. Innerhalb kurzer Zeit wird das Ergebnis sein, dass die Größe der einzelnen Arbeitselemente sich gar nicht mehr sehr unterscheidet. Diese kleingebrochenen Elemente - man spricht hier oftmals auch von Rightsizing, also einer für die Umsetzung angenehmen Größe - müssen nicht mehr geschätzt werden, sondern das Zählen der Elemente genügt völlig. Wenn bekannt ist, wie viele Elemente ein Team im Schnitt pro Sprint abarbeiten kann, dann kann daraus einfach eine Prognose abgeleitet werden, wie lange es dauern wird, einen bestimmten Teil des Product Backlogs abzuarbeiten. Voraussetzung dafür ist allerdings, dass das Product Backlog stabil bleibt und dass die Elemente, über die sich die Prognose erstrecken soll, bereits rightsized sind.
Manipulation von Metriken - Velocity vs. Throughput
Jede Metrik wird über kurz oder lang dazu führen, dass begonnen wird, die Metrik zu optimieren und nicht die zugrundeliegenden Prozesse und Arbeitsweisen. Wird die Effizienz eines Teams an der Velocity, also beispielsweise an den Story Points pro Sprint, gemessen, liegt eine Reaktion ziemlich nahe. Das Team wird über die Zeit beginnen, Elemente höher zu schätzen, was direkt zu einer höheren Velocity führt, aber am Ergebnis keinen Unterschied macht. Den Throughput können Teams ebenfalls mit recht einfachen Methoden optimieren. Neben dem Kleinerbrechen in einzelne Teilaufgaben, kann auch darauf geachtet werden, einmal begonnene Elemente möglichst rasch abzuschließen. Beides sind aus Flow-Sicht durchaus erwünschte Effekte.
Metriken ermitteln
Die genannten Metriken haben alle ein gemeinsames Ziel: Sie schaffen Transparenz über wichtige Faktoren für die Optimierung von Flow und bieten einen Einblick in das System in Echtzeit. Und sie haben den großen Vorteil, dass sie einfach zu ermitteln sind. Viele Tools, die zur Aufgabenplanung und -verwaltung genutzt werden, bieten eine entsprechende Ermittlung der Metriken und oft auch eine Visualisierung. Aber auch mit einem papierbasiertem Aufgabenboard lassen sich die Metriken sehr einfach erheben.
Abbildung 1 - Metriken ermitteln
Sobald ein Element den definierten Startpunkt des Workflows überschreitet und damit in Process ist, beginnt die Zeitmessung für dieses Element. Zu jedem beliebigen Zeitpunkt kann nun das Work Item Age für jedes Element abgelesen werden. Mit dem überschreiten des definierten Endpunkts, wird die Zeitmessung für das entsprechende Element angehalten. Dieser Wert stellt nun die Cycle Time dar. Work in Process kann durch einfaches Zählen der Elemente zwischen Start und Ende ermittelt werden und der Throughput ergibt sich, indem man die Elemente zählt, die pro Zeiteinheit (Woche, Sprint o.ä.) die Ziellinie überschreiten.
Flow Metriken manuell ermitteln
Wird ein papierbasiertes Board genutzt oder das verwendete Tool unterstützt nicht alle vorgestellten Metriken, ist das noch lange kein Beinbruch. Diese lassen sich mit wenig Aufwand manuell erheben und visualisieren. Am einfachsten wird hierzu einfach pro Tag auf allen Elementen, die sich in Process befinden, ein Punkt, ein Strich o.ä. vermerkt. Damit kann einfach das Work Item Age und nach Abschluss somit auch die Cycle Time ermittelt werden. Dieser Wert kann dann im Daily oder bei ähnlichen Gelegenheiten aktualisiert werden.
Metriken visualisieren
Ein Diagramm, das im Kontext von Kanban und Flow häufig anzutreffen ist, ist das Cumulative Flow Diagram (CFD). Dabei wird die Anzahl der Elemente in den einzelnen Phasen des Workflows über die Zeit als gestapelte Flächen dargestellt. Man kann aus dem CFD zwar auch Werte wie z.B. das WIP und eine ungefähre durchschnittliche Cycle Time ablesen, aber im Wesentlichen wird das CFD für Trendanalysen eingesetzt. Häufig wird es genutzt, um die Wirkung von Veränderungen am System zu analysieren oder Zeiträume zu identifizieren, bei denen eine nähere Betrachtung sinnvoll sein kann.
Abbildung 2 - Comulative Flow Diagramm
Einen detaillierteren Einblick in Bezug auf die Cycle Time verschafft der sog. Cycle Time Scatterplot (CTS). Dabei wird auf der X-Achse das Datum des Abschlusses eines Elementes eingetragen und auf der Y-Achse die Cycle Time für dieses Element. Im unten abgebildeten Diagramm sind die Elemente, die während der Bearbeitung geblockt waren, rot hervorgehoben. Aus dem CTS lässt sich nicht nur recht einfach die Service Level Expectation (SLE) ermitteln (siehe dazu auch Teil 1 dieser Artikelserie), sondern es können auch andere interessante Einsichten gewonnen werden. Die Ursachenforschung und damit auch der Erkenntnisgewinn, sollte auf die Elemente fokussiert werden, die eine Besonderheit aufweisen, die also z.B. eine besonders hohe Cycle Time hatten, oder Zeiträume, in denen besonders viele geblockten Elemente in kurzer Zeit abgeschlossen werden konnten. Dort scheint es eine gemeinsame Ursache gegeben zu haben, die natürlich große Auswirkungen hat. Man kann auch erkennen, dass die Anzahl der geblockten Elemente ab ungefähr der Mitte des Diagramms deutlich zunimmt. Die Ursache dafür zu beseitigen, kann einen großen Effekt haben, scheinen diese Blocker doch einen deutlichen Einfluss auf die Cycle Time zu haben (alle roten Punkte oberhalb der 50-Prozent-Perzentile). So lassen sich aus einem CTS viele spannende Aspekte herauslesen.
Abbildung 3 - Cycle Time Scatterplot
Während sowohl CFD als auch CTS sich vor allem dazu eignen, die Vergangenheit zu analysieren, bietet die Work Item Aging Chart (WAC) eine Visualisierung der Elemente, die aktuell in Process sind und kann damit genutzt werden, die aktuelle Bearbeitung zu optimieren. Dabei wird das aktuelle Work Item Age für die in-Process-Elemente gruppiert nach aktueller Phase des Workflows dargestellt. Zusätzlich können für jede Phase entsprechende Perzentile farblich markiert werden, um deutlich zu machen, ab welchem Alter es in einer entsprechenden Phase schwierig werden könnte, die SLE noch zu erfüllen. So kann bereits frühzeitig erkannt werden, welche Elemente die SLE vermutlich nicht erfüllen werden und es kann versucht werden, diese Elemente gezielt zu beschleunigen. Ein Team kann das WAC beispielsweise im Daily benutzen, um aktuellen Handlungsbedarf zu erkennen und im Team Aktionen zu planen.
Abbildung 4 - Work Item Aging Chart
Darüber hinaus gibt es noch eine Reihe weiterer Diagramme mit denen Work in Process und Throughput visualisiert werden können. Auf diese soll an dieser Stelle aus Platzgründen jedoch nicht näher eingegangen werden.
Flow-basierte Planung
Die hier vorgestellten Metriken lassen sich auch dazu nutzen, klassische Fragestellungen in der Softwareentwicklung zu beantworten. Aus einer Teamsicht stellt sich beispielsweise die Frage, wie viel Arbeit in die nächste Iteration, etwa einen Sprint, eingeplant werden soll. Diese Frage lässt sich recht einfach mit dem Throughput beantworten. Wenn das Team in den letzten Sprints durchschnittlich 24 Elemente abschließen konnte, dann wird das ungefähr auch die Menge sein, die für den nächsten Sprint erwartet werden kann, wenn sich die Kapazität nicht signifikant verändert und die Elemente rightsized sind. Eine zweite Fragestellung, die häufig an Entwicklungsteams gerichtet wird, ist die Frage, wann etwas fertig sein wird bzw. wie lange es dauert, eine bestimmte Menge von Elementen abzuarbeiten. Hier kann der durchschnittliche Throughput herangezogen werden. Wenn die Frage lautet, wie lange wird es dauern, diese 100 Elemente umzusetzen und der durchschnittliche Throughput 24 beträgt, dann werden dafür wohl 4-5 Iterationen benötigt. Diese Aussagen können aber mit statistischen Methoden noch weiter verfeinert werden. Eine gängige Vorgehensweise ist dabei die sog. Monte-Carlo-Simulation. Dabei wird durch eine Zufallsverteilung die Wahrscheinlichkeit einer bestimmten Prognose basierend auf empirischen Daten ermittelt. Zugrunde liegt dabei das Gesetz der großen Zahlen. Die Ergebnisse können dann genutzt werden, um verschiedene Fertigstellungszeitpunkte mit entsprechenden Wahrscheinlichkeiten zu versehen. Im untenstehenden Beispiel wird mit einer Wahrscheinlichkeit von 70 Prozent eine Fertigstellung bis spätestens 13. September erreicht werden. Eine höhere Wahrscheinlichkeit kann erst zu einem späteren Zeitpunkt erreicht werden, z.B. 95 Prozent bis zum 25. September. Damit verändert sich die Kommunikation mit den Stakeholdern, da nun zusätzlich eine Wahrscheinlichkeit über die Erreichung des Zieldatums ins Spiel kommt. Ganz nach dem Motto: "Sage uns, wie verlässlich die Aussage sein soll, dann können wir ein Datum nennen". Eine 100-prozentige Wahrscheinlichkeit wird aber niemals erreicht werden, was leider viel zu oft ignoriert wird.
Abbildung 5 - Monte Carlo Simulation
Die Genauigkeit solcher Prognosen hängt wiederum sehr stark von der Varianz in unserem System ab. Je gleichmäßiger Cycle Time und Throughput in der Vergangenheit waren, umso geringer wird auch die Varianz in der Prognose sein. So zahlen sich die Bemühungen über einen verbesserten Flow auch in dieser Beziehung aus.
Bonus-Metrik: Flusseffizienz
Eine Metrik, die sich etwas von den bisher genannten Metriken unterscheidet, ist die sog. Flusseffizienz. Sie ist nicht ganz so einfach zu erheben und sie dient auch eher dazu, die Auswirkungen von Prozessverbesserungen in einem mittel- bis langfristigen Zeithorizont transparent zu machen. Dabei wird die Zeit, die aktiv an einer Aufgabe gearbeitet wird, ins Verhältnis zur Cycle Time gesetzt. Wird also beispielsweise zum Beheben eines Fehlers 1 Stunde Arbeitszeit benötigt, die Zeit vom Melden bzw. vom Beginn der Bearbeitung bis zum Ausliefern des Bug-Fixes beträgt jedoch 48 Stunden, dann steht die Flusseffizienz bei einem Wert von 1/48. Die Flusseffizienz gibt damit an, wie hoch der Anteil der Wartezeit in einem System ist. Je näher dieser Wert an 1 liegt, desto höher die Effizienz des Systems und umso besser der Flow. Dies kann durch eine Reduzierung der Wartezeiten erreicht werden, jedoch nicht durch eine Erhöhung der Auslastung der Personen, wie bereits zuvor im Kasten "Flow und Cycle Time vs. Auslastung" beschrieben wird.
Fazit
Wir haben gesehen, dass durch ein paar sehr einfach zu erhebende Metriken bereits sehr viel Transparenz in Bezug auf den Flow erreicht werden kann, und so die richtigen Fragen bereits früher diskutiert werden können. ähnlich wie einige Flow-Prinzipien mögen einige dieser Metriken zunächst nicht sehr praktikabel erscheinen, weil sie alle die Größe der Elemente ignorieren. Wer sich jedoch auf ein Experiment einlässt und diese Metriken tatsächlich einmal ausprobiert, der wird nicht nur feststellen, dass sich damit einiges an organisatorischem Ballast eliminieren lässt, sondern dass diese Metriken in der Tat helfen können, den Fluss der Arbeit zu optimieren.
Natürlich kommt es auch hier darauf an, wie diese Metriken genutzt werden. Man sollte vor allem dem Impuls widerstehen, die Metriken für Zielvorgaben zu nutzen. Sie sollten vielmehr als Informationsquelle angeboten und regelmäßig ausgewertet werden. Der Nutzen der Metriken lässt sich dann daran erkennen, wie viele wertvolle Diskussionen dadurch ausgelöst werden. Das wiederum setzt jedoch einen grundsätzlichen Willen zur Verbesserung der Arbeitsweise und des Systems bei allen Beteiligten voraus. Metriken können also unterstützen, aber nichts erzwingen. Am Ende kommt es wieder auf die Menschen an.
Weiterführende Folgen zur Artikelserie zu Kanban:
Teil 1 - Let there be flow – Die Magie hinter Kanban und Flow -> Hier weiterlesen
Teil 2 - Flow mit Metriken beherrschen (dieser Artikel)
Teil 3 - Flow mit Azure DevOps -> Hier weiterlesen
Sie finden das Thema spannend und möchten mehr darüber erfahren? Vielleicht ist das Professional Scrum with Kanban Training für sie interessant?
Oder sie vereinbaren einen Termin zu einem kostenlosen und unverbindlichen Gedankenaustausch.
Termin vereinbaren