Wer misst, misst Mist!

If you can’t measure it, you can’t manage it!“ Dieser vielfach zitierte und variierte Spruch von Robert Kaplan und David Norton ist eine Säule modernen Managements [1]. Doch jeder naturwissenschaftlich oder am Ingenieurwesen Interessierte hat irgendwann erkannt, dass das mit dem Messen so eine Sache ist. Messtechnik und Messfehler machen uns das Leben schwer. Und in der Quantenmechanik verleidet Heisenbergs Unschärferelation das Messen, denn schon die Messung selbst beeinflusst das Messobjekt. Das ist nicht nur ein Problem für Experimentalphysiker. Das ist im Projektmanagement leider genauso. Und auch Agilität hat daran erst mal nicht verändert, sondern das Problem nur verschoben.

Messen und Agilität

Ein Thema, auf das Manager bei der Einführung agiler Prozesse sofort anspringen, ist „Velocity“, ein einfaches Messverfahren für den Projektfortschritt, aus dem sich – nach Ansicht besagter Manager – Liefertermine ableiten lassen und über das die Leistungsfähigkeit der Teams gesteigert werden kann. Das mag vielleicht auch irgendwann möglich sein. In erster Linie dienen Metriken in agilen Verfahren allerdings einem anderen Zweck: Es geht um die Prozess- und Produktqualität [2].Doch zuerst stellt sich die Frage, was eigentlich der Sinn agiler Verfahren ist. Es geht dabei um die Umsetzung komplexer Projekte. Das haben bereits Takeuchi und Nonaka in ihrem Grundlagenartikel 1986 beschrieben und es findet sich auch in der jüngsten Ausgabe des Scrum Guide von 2017 bereits im ersten Abschnitt [3][4].Warum ist das so wichtig? Komplexe Projekte zeichnen sich gegenüber komplizierten Unterfangen dadurch aus, dass sie nicht wirklich vorab planbar sind. Die Zusammenhänge bei komplexen Aufgaben lassen sich nur im Nachhinein herausfinden [2]. Damit unterscheiden sich die Managementprozesse von komplizierten und komplexen Projekten grundlegend.Aus der Systemtheorie sind bereits seit den 1950er Jahren die Prinzipien bekannt, wie bei der Lösung komplexer Aufgaben erfolgreich vorzugehen ist. Kurze Rückkopplungsschleifen und adaptive, also lernende Verfahren bilden unter anderem die Grundlagen dafür. Das Regelwerk von Scrum überträgt diese Prinzipien in den Kontext der Softwareentwicklung. Aufgrund der systemimmanenten großen Planungsunsicherheit können Messverfahren im Agilen also gar nicht direkt den Projektfortschritt messen. Es fehlt eine ausreichend genaue Vergleichsgröße aus der Planung, mit der sich die Messwerte in Bezug setzen lassen; eine Fortschrittsmessung kann also nur indirekt erfolgen.Was bedeutet das für die Velocity? Velocity misst die Prozessqualität hinsichtlich ihrer Stabilität. Ein konstanter Wert über mehrere Iterationen hinweg weist auf einen stabilen Entwicklungsprozess hin. Dieser Entwicklungsprozess muss dafür weder effizient noch effektiv sein. Er ist erst einmal nur stabil.

Was misst Velocity?

Bei einer Velocity-Messung wird eine Messgröße in zeitlich festen Intervallen betrachtet. Gebräuchlich ist die Anzahl fertig umgesetzter Story Points je Sprint oder Iteration. Wird die Summe aller in Produktqualität umgesetzter und abgenommener Story Points nach jedem Sprint ermittelt und aufsummiert, ergibt sich in einer Säulendarstellung ein sogenanntes Burnup-Diagramm. Die Velocity ist dann die Steigung der Geraden, die sich über die Enden der Säulen ergibt (Bild 1).

Wird zusätzlich eine Zielkurve auf Basis von Umfangsschätzungen ermittelt, so lassen sich über die Velocity auch Aussagen treffen zu möglichen Lieferterminen oder umgesetzten Umfängen zu fest vorgegebenen Lieferterminen. Damit das funktioniert, braucht es zwei Voraussetzungen: eine ausreichend gute Zielkurve und eine halbwegs konstante ­Velocity. Ansonsten ist sowohl die Velocity zu ungenau als auch der Zielkorridor zu unscharf, um belastbare Aussagen treffen zu können.Velocity ist also nur von Wert, wenn sie nah genug um einen stabilen Mittelwert schwankt. Das bedeutet nichts anderes, als dass der Entwicklungsprozess trotz der komplexen zu bewältigenden Aufgaben stabil funktioniert. Erstes Ziel ist daher eine konstante Velocity. Ist das nicht zu erreichen, ist das Fortschrittstempo so lange zu reduzieren, bis sie konstant gehalten werden kann; dann ist ein stabiler Prozess erreicht. Jetzt ist es möglich, über das Umsetzen von Maßnahmen, die das Team in Retrospektiven erarbeitet hat, zu versuchen, die Velocity langsam zu steigern, ohne Stabilität im Prozess einzubüßen [2].

Konstante Velocity

Über die Velocity kann man erkennen, ob der Entwicklungsprozess stabil läuft und ob ausgewählte Maßnahmen zu einem verbesserten Prozess geführt haben. Ohne eine ausreichend konstante Velocity sind alle darauf aufbauenden Analysen und Prognosen nicht denkbar. Das bedeutet allerdings auch, dass die Velocity nicht maximal ist. Natürlich lässt sie sich kurzfristig steigern, zum Beispiel indem technische Schulden eingegangen werden. Langfristig erodieren technische Schulden aber zumindest die Konstanz der Velocity und meist auch deren erreichbare Höhe (Bild 2).

Gleiches gilt für Überstunden. Kurzfristig lassen sich dadurch mehr Tasks umsetzen, doch langfristig sind sie je nach Arbeitszeitmodell entweder durch Minderarbeit wieder abzubauen oder auszubezahlen, was wiederum die Velocity verringert oder das Budget stärker als gedacht belastet. Trifft beides nicht zu, besteht die Gefahr, dass wertvolle Mitarbeiter das Team verlassen, was ebenfalls zu einem Einbruch der Velocity führt.

Messen von Indikatoren

In agilen Verfahren wird also die Qualität und Stabilität des Entwicklungsprozesses gemessen. Wirklich korrekt ist das aber leider immer noch nicht. Tatsächlich wird nicht die Qualität/Stabilität des Entwicklungsprozesses gemessen, sondern nur ein Indikator dafür.Ist das ein Problem? Ja, denn im Gegensatz zu einer direkten Messung sind Indikatoren nur Hinweise. Diese Hinweise können, wie im Fall der Velocity, recht stark sein, es sind jedoch nur Indizien und keine Beweise. Trotz einer konstanten Velocity kann also einiges im Argen liegen. Werden zum Beispiel nicht alle Aufwände passend erfasst, so spiegelt die Velocity nur einen Teil der Teamleistung wider. Leistet ein Team etwa noch Wartungsarbeiten an einem Altprojekt, die nicht in die Velocity einfließen, kann das trotz guter Prozessqualität zu einer stark schwankenden Velocity führen. Außerdem können die Messungen manipuliert werden, indem beispielsweise umgesetzte User-Stories bis zum nächsten Sprint zurückgehalten werden, um eine konstante Velocity vorzutäuschen. Immer dann, wenn die Messungen vom Management zu stark in den Vordergrund gerückt werden, besteht die Gefahr von Manipulationen.

Messverfahren beeinflussen die Arbeit

Die Gefahr von Manipulationen besteht auch beim traditionellen Management. Und falls keine direkte Messung möglich ist, bleiben nur noch Indikatoren als Anhaltspunkte. Damit ergibt sich anscheinend kein Unterschied zwischen agilen und traditionellen Verfahren und es bräuchte im Management nichts verändert zu werden. Nun heißt es halt Velocity und nicht mehr Lines of Code oder was auch immer als Maßzahl benutzt wurde. Die Velocity ist nichts weiter als ein Indikator und hat damit auch ähnliche Nebenwirkungen wie andere Messungen. Doch was hat die moderne, agile Velocity mit den Lines of Code gemeinsam?Sobald im Management ein Messverfahren angewendet wird, richtet sich der Fokus der Mitarbeiter darauf; sie werden daran gemessen, also orientieren sie sich auch daran. Das ist ja genau der Mechanismus, der – wenn auch glücklicherweise eher selten – zu den oben erwähnten Manipulationen führt. Auch ohne dieses Extrem führen Messungen dazu, dass die Bewertung guter Arbeit sich auf wenige Zahlen reduziert.Am Beispiel der Lines of Code ist schnell der negative Effekt solcher Verfahren zu erkennen. Wenn die Anzahl geschriebener Codezeilen einen guten Entwickler ausmacht, wird er viele Zeilen schreiben. Häufig ist guter Code jedoch eher schlank und übersichtlich geschrieben. Wird er unnötigerweise aufgebläht, verteuert dies später die Wartung und verschlechtert die Erweiterbarkeit.Sind also gute Entwickler an ihren wenigen Lines of Code zu erkennen? Auch das wird kaum gelingen, da dieses Raster meist nur die Faulen und die Hobbykryptografen herausfindet. Diese schaffen entweder nichts weg oder produzieren erst recht schwer wartbaren Code.Das Grundproblem bleibt also: Die Teammitglieder orientieren sich mit ihrer Arbeit an den laufenden Messungen, um später gut dazustehen. Das ist nur allzu menschlich.

Das Dilemma auflösen

Vielleicht können wir auf Messungen verzichten. Nicht jedes Detail einer Messung hat einen Wert, kann aber massiven Schaden anrichten. Auf alle Indikatoren wollen Sie aber vielleicht doch nicht verzichten. Es wäre sehr wertvoll, die Prozess- oder Produktqualität hinsichtlich bestimmter Aspekte bewerten zu können, um frühzeitiges Korrigieren zu ermöglichen.Zwei Wege bieten sich dafür an. Zum einen können Sie mehrere Indikatoren messen, um daraus ein Gesamtbild zu gewinnen. Ein einzelner Indikator verliert dadurch an Gewicht. Auch lassen sich diese Indikatoren regelmäßig anpassen und durch andere Verfahren ersetzen. Dies umgeht die Probleme, führt aber zu einem hohen Aufwand mit den Me­triken. Sinnvoll ist dies nur, wenn sich die Messungen einfach oder am besten automatisch ausführen lassen. So erhalten die Entwickler schnell Feedback.Zum anderen können die Retrospektiven besser genutzt werden. Die Menschen, die am besten beurteilen können, wie es um die Prozess- und Produktqualität steht, sind die Entwickler; sie arbeiten täglich damit. Wenn es den Scrum Mastern oder Projektleitern gelingt, den Fokus des Teams regelmäßig auf die für das Produkt und damit auch für das Management wichtigen Parameter zu legen, reicht ein minimaler, automatisch ermittelter Satz von Indikatoren aus. Nicht das Management erhält und bewertet die Zahlen, sondern das Team. Es kann mit deutlich höherer Wahrscheinlichkeit daraus die wertvollen, erfolgversprechenden Schlüsse ziehen. Dazu bedarf es eines Managements, das gelernt hat loszulassen und zu vertrauen. Mikro-Controlling schafft nur die Illusion von Kontrolle und keinen Mehrwert [5].Neben dem Vertrauen aus dem Management kommt ein zweiter notwendiger Aspekt hinzu: Das Team muss willens und in der Lage sein, diese Managementaufgabe zu übernehmen. Dies zu entwickeln und sicherzustellen, ist Aufgabe des Scrum Masters. Die Teammitglieder selbst zeichnen sich dafür durch ausreichende Selbstdisziplin aus. Umgangssprachlich kann man das auch als Professionalität bezeichnen. Alles Weitere kann dann jedes einzelne Teammitglied unter Anleitung durch den Scrum Master lernen. So kann ein Team sich selbst steuern, was meist missverständlich mit dem Begriff der Selbstorganisation bezeichnet wird.Die Aufgaben des Managements in einer agilen Organisation lassen sich in drei Punkten zusammenfassen: Ziele vorgeben, Rahmenbedingungen verbessern und Personal entwickeln. Diese Frage kann das Team alleine nicht beantworten. Auch Rahmenbedingungen kann es nicht alleine verändern. Dies sind die strategischen und operativen Aufgaben des Managements für den Projekterfolg. Dazu kommt langfristig die fachliche Entwicklung der Mitarbeiter und ihrer Soft Skills sowie das Finden und Einbinden neuer Kolleginnen und Kollegen. Innerhalb dieser Managementaufgaben gilt es, eine Reihe wichtiger Entscheidungen zu treffen.

Was lohnt es, zu messen?

Bei Weitem nicht alles, was sich automatisch ermitteln lässt, ist wertvoll. Es führt nicht zu Informationen, sondern nur zu Datenmüll. „Information ist ein Unterschied, der einen Unterschied macht“ hat es Gregory Bateson treffend formuliert [6]. Was braucht das Team, um seine Arbeit hinsichtlich der inneren und äußeren Qualität des Produkts bewerten zu können? Dazu seien zwei Beispiele betrachtet.Die Anzahl automatisierter Tests hilft beim Bewerten der Produktqualität meist wenig. Zu oft werden nur die einfachen Aspekte geprüft und immer wieder ähnliche Bereiche durchlaufen. Die Anzahl automatisch getesteter Akzeptanzkriterien kann da schon hilfreicher sein, ebenso wie den Fokus im Team auf die Akzeptanzkriterien zu legen. Aber sind die Kriterien überhaupt hilfreich und einigermaßen umfassend? Oder zeigt sich hier bereits eines der grundlegenderen Probleme? Wie lässt sich das einfach und automatisch messen? Die Antworten auf solche Fragen werden die Entwicklung weiterbringen.Aus der Methode Kanban kommt eine Reihe von Prozessmetriken. Diese lassen sich in einem sogenannten Cumulative Flow Diagram anschaulich visualisieren (Bild 3). Die Einheit der Dauer ist entsprechend der betrachteten Aufgabengröße zu wählen. Sie ist typischerweise meist Tag, Woche oder Iteration/Sprint.

Die regelmäßige Diskussion in den Retrospektiven anhand des aktuellen Diagramms kann helfen, Schwachpunkte im Prozess zu identifizieren, um die Diskussion schnell zur Lösung zu bringen. So ergibt sich sowohl eine Vielzahl von Sichten und Metriken, die hervorragend im Team diskutiert werden können, als auch eine Basis, um über die Zeit die Wirkung von Veränderungen im Workflow zu verfolgen. Als besonders lohnenswert haben sich Analysen zu WIP (Work in Progress), Cycle Time (Entwicklungsdauer) und Lead Time (Durchlaufzeit) herausgestellt. Werden zu viele Aufgaben parallel angefangen (WIP)? Gibt es zu viele Wartezeiten oder Störungen in der reinen Entwicklung (Cycle Time) oder im gesamten Prozess (Lead Time)? Oder droht das Backlog, also die Liste der Aufgaben, leerzulaufen? Oder im Gegenteil: Wächst diese schneller, als das Team sie abarbeiten kann? Hier werden entsprechende Indikatoren sichtbar.

Gut genug ist gut genug

Wie weit sollen die Optimierungen gehen? Hier ist eine passende Balance zu finden. Gute Prozesse sorgen für einen hohen Durchsatz. Doch je weiter ein Entwicklungsprozess hinsichtlich seines Durchsatzes optimiert wird, desto anfälliger ist er für Änderungen an den Rahmenbedingungen. Damit wird er unflexibel. Die Abläufe lassen sich nur noch schwer und mit hohen Einbußen im Durchsatz an veränderte Rahmenbedingungen anpassen. Das Team verliert also Agilität.Dies war einer der Ausgangspunkte für Taiichi Ohno, das Toyota-Produktionsprinzip und damit Kanban zu entwickeln [7]. Die Basis für eine hohe Flexibilität bildet ein hoher, daran angepasster Automatisierungsgrad. Für Ohno bedeutete das in der Automobilproduktion, zuerst Werkzeuge zu ent­wickeln, die sich leicht an verschiedene Produktionslinien anpassen ließen. Dies war eine Voraussetzung, um von der optimierten Produktion auf Halde zu einer flexiblen Produktion just in time zu kommen.Das Team verbessert seine Entwicklungsprozesse so weit, dass es die normalen Aufgaben gut und stabil abarbeiten kann. Alle besonderen Themen werden genau und detailliert betrachtet und passend zur Aufgabe umgesetzt. Hierfür Standards bis hin zu einer eigenen Entwicklungsprozessvariante zu definieren, wäre Verschwendung. Genau diese Balance zwischen standardisiertem und individuellem Vorgehen ist vom Team in den Retrospektiven regelmäßig zu prüfen und gegebenenfalls neu zu justieren.Alle Prozessschritte von den Build-Prozessen bis zur automatischen Prüfung werden so automatisiert, dass sie jederzeit, jedoch mindestens einmal am Tag durchlaufen werden und das Team selbst in der Lage ist, jederzeit Anpassungen vorzunehmen. Unterbrechungen dieser Prozesskette haben stets Vorrang vor anderen Aufgaben, da ansonsten der Entwicklungsprozess selbst ins Stocken gerät. Neben dem eigentlichen Entwicklungsprozess wird daher auch in einem Metaprozess die Art und Weise betrachtet, wie der Entwicklungsprozess gestaltet und weiterentwickelt wird. Letztendlich ist diese notwendige Flexibilität auch der Grund dafür, dass die Velocity nicht maximal sein kann oder sein sollte. Das wäre für ein Projekt sogar sehr gefährlich. Das Team benötigt den Spielraum, der sich aus einer guten, konstanten, aber nicht maximalen Velocity ergibt, um die besonders komplexen Aufgaben zu bewältigen.

Effiziente Prozesse

Jeff Sutherland hat nicht nur im Scrum Guide die Dinge auf den Punkt gebracht. Für ihn ist die Value Stream Map wie in Bild 4 die einzig sinnvolle Basis, um die Effizienz von Prozessen zu messen [8]. Über diese Metrik kann ein Team die Prozesse besser verstehen, analysieren und verbessern.

Im Kern ist die aus der Value Stream Map abgeleitete Prozesseffizienz sehr einfach: Es ist das Verhältnis aus der reinen, notwendigen Arbeitszeit und der Gesamtdauer für das Umsetzen dieser Aufgabe. Ist das aber nicht das Gleiche? Beileibe nicht, was deutlich wird, wenn eine Value Stream Map erzeugt wird [2].Um eine Value Stream Map zu erstellen, ist der zu betrachtende Prozess mit seinen einzelnen Prozessschritten zu ermitteln und es sind zu jedem Schritt zwei Zeiten aufzutragen:

• Nutzen: die tatsächliche Bearbeitungsdauer, also die Nettoarbeitszeit, welche die bearbeitende Person für diesen Schritt benötigt
• Gesamt: die Verweildauer der Aufgabe in diesem Schritt, also die Differenz zwischen dem Eintrittszeitpunkt (die einen Schritt bearbeitende Person hat sich die Aufgabe genommen) und dem Austrittszeitpunkt (die Aufgabe ist in den nächsten Prozessschritt hinübergezogen worden)

Jetzt lassen sich zwei Zeiten bestimmen und ins Verhältnis setzen: die Nettobearbeitungsdauer für die gesamte Umsetzung einer Aufgabe und die gesamte Zeit, über die hinweg die Aufgabe im Prozess verweilt. Dieses Verhältnis sagt etwas über die Prozesseffizienz aus.Dieses Verhältnis können wir statistisch für die Umsetzung der geplanten Aufgaben in einer Iteration betrachten und für spezielle Abläufe wie die Behandlung hoch priorisierter Fehler aus dem Betrieb unseres Produkts auf der Überholspur des Kanban-Boards ermitteln.Letzteres ist in Bild 4 exemplarisch geschehen. Darin ist als Beispiel die Sonderbehandlung bei einem schwerwiegenden Fehler in ausgelieferter Software zu sehen. Der obere Teil zeigt die Dauer für die einzelnen Schritte und Übergaben. Sie summiert sich auf 705 Minuten. Für die gesamte Nutzdauer kommen 495 Minuten Arbeitszeit zusammen. Daraus ergibt sich eine Differenz von 210 Minuten, die als Verschwendung angesehen werden kann. Der Quotient Nutzdauer/Gesamtdauer wird als Prozesseffizienz betrachtet. Er beträgt für das Beispiel aus Bild 4 hervorragende 70 Prozent.Wundern Sie sich nicht, wenn Ihre Prozesse zu Beginn bei zehn Prozent stehen. Oft macht diese Betrachtung enormes Verbesserungspotenzial sichtbar. Das Team kann nun Prozessverbesserungen entwickeln und umsetzen und regelmäßig über die genannten Metriken überprüfen. So führen sinnvolle Metriken in den Händen verantwortungsvoller Teams zu einer kontinuierlichen Prozessverbesserung.

Fazit

Metriken sind ein zweischneidiges Schwert. Es besteht die große Gefahr, mehr zu verlieren als zu gewinnen. Das liegt daran, dass sich einerseits nur Indikatoren messen lassen und andererseits sich die Entwickler nach den Metriken ausrichten und weniger auf den gesamten Prozess achten.Die Lösung erfolgt auf zwei Wegen. Zum einen wird eine ganze Reihe solcher Indikatoren eingesetzt, um zu Aussagen über die Produkt- und Prozessqualität zu kommen. Zum anderen wandert die Aufgabe, die Indikatoren zu überwachen und gegebenenfalls anzupassen, ebenso an das Entwicklungsteam, das daraus die passenden Schlüsse zur fortlaufenden Verbesserung ziehen kann. Das setzt allerdings ein hohes Maß an Vertrauen im Management sowie Reife und Selbstdisziplin im Team voraus.

Fussnoten

1. Robert S. Kaplan, David P. Norton: The Balanced Scorecards – Translating Strategy into Action, ISBN 978-0-87584-651-4,
2. Uwe Vigenschow: APM – Agiles Projektmanagement, ISBN 978-3-86490-211-6,
3. Hirotaka Takeuchi, Ikojiro Nonaka: The New New Product Development Game, http://www.dotnetpro.de/SL1808Messen1
4. Ken Schwaber, Jeff Sutherland: The Scrum Guide, http://www.scrumguides.org
5. Reinhard K. Sprenger: Vertrauen führt, ISBN 978-3-593-38502-0,
6. Gregory Bateson: Ökologie des Geistes, ISBN 978-3-518-28171-0,
7. Taiichi Ohno: Das Toyota-Produktionssystem, ISBN 978-3-593-39929-4,
8. Jeff Sutherland: Process Efficiency in Scrum – Why it Matters and How to Measure it, http://www.dotnetpro.de/SL1808Messen2