Inhalt
Auch im agilen Umfeld gehört das Messen als fester Bestandteil zum Entwicklungsprozess! Es ist sozusagen inhärenter Bestandteil der so oft genannten Transparenz. Allerdings sollten nicht große, gut gefüllte Dashboards mit Kennzahlen, Diagrammen und Ampeln für einen vermeintlichen Überblick sorgen, sondern besser einige ausgewählte Kennzahlen und temporär notwendige Visualisierungen direkt im agile Workspace. Während es im klassischen Umfeld also eher darauf ankommt jeden nur denkbaren Aspekt zu beleuchten und jedes Schlupfloch in der Methode mit einer weiteren Metrik zu schließen, liegt in der agilen Welt das Augenmerk eher auf wenigen, dafür aber passgenauen Messungen.
Außerhalb der agilen Welt gibt es Metriken, Kennzahlen, KPI und Balanced Scorecards gefühlt an jeder Ecke. Mit der Goal Question Metric (GQM) gibt es sogar eine Vorgehensweise die für Softwarequalität systematisch Modelle mit Kennzahlen erstellt. All dies hat nichts mit den in diesem Beitrag vorgestellten Metriken gemein. Im agilen Umfeld kommt es mehr darauf an, für spezifische Fragestellungen Metriken zu identifizieren und sie nur so lange beizubehalten, wie sie einen erkennbaren Mehrwert bieten.
Ziel von Metriken
Ziel einer jeden Metrik sollte es sein, etwas zu quantifizieren und Verbesserungspotenziale zu heben. Sie sind also Hilfsmittel, um auf dem richtigen Weg zu bleiben. Diese Funktion als Wegweiser können Metriken nur erfüllen, wenn sie dosiert eingesetzt werden – ein Wald aus vielen Wegweisern ist dabei eher kontraproduktiv. Die Metriken sollten trotz ihrer Kontrollfunktion NICHT dazu dienen einzelne Teams zu vergleichen oder Schuldige zu identifizieren.
Mit Hilfe von Metriken soll durch Verdichtung eine Fokussierung auf das Wesentliche erreicht werden, um so Probleme und Schwachstellen, aber auch Stärken aufzuzeigen. Das Aufzeigen erfolgt nicht um seiner selbst willen, sondern um gezielt an den Stärken und auch Schwächen arbeiten zu können. Sie sind damit eine Basis für Entscheidungen. Auch Ziele lassen sich hervorragend durch Metriken definieren. Dabei ist nicht die Veränderung des gemessenen Wertes das Ziel. Im Rahmen der Zielfindung muss überprüft werden, welche Faktoren zwischen dem aktuell gemessenen Zustand und dem gewünschten Zustand liegen. Für die identifizierten Punkte können dann einzelne messbare Maßnahmen und Ziele z. B. im Rahmen von OKR (siehe auch “OKR - Objectives und Key Results”) definiert werden. Anhand der Metrik kann dann im Nachgang überprüft werden, ob die Maßnahme, Änderung oder Anpassung den gewünschten Erfolg gebracht hat.
Da Metriken niemals für sich allein sprechen, sind zwei Punkte entscheidend. Erstens muss die Metrik leicht zu verstehen sein – also was wird hier gemessen und dargestellt. Zweitens muss immer klar sein, dass die Metrik nur die Auswirkung eines Ereignisses oder Zustandes aufzeigt, nie aber das Ereignis oder den Zustand selbst – so könnte z. B. ein Anstieg der Fehler aufgezeigt werden, nicht aber der Grund dafür (verbessertes Testen, schlechtere Qualität).
Sobald es eine Metrik gibt und damit der Blick auf bestimmte Messpunkte gerichtet wird, steuert sie damit auch das Verhalten. Diese Tatsache hat sowohl positive als auch negative Aspekte. Auf der einen Seite kann mit einer Metrik ganz bewusst der Fokus auf ein bestimmtes Thema gesetzt werden. Auf der anderen Seite wird damit das natürliche Verhalten manipuliert und dadurch die Metrik selbst verfälscht.
Gute Metriken
Gute Metriken zeichnen sich vor allen Dingen dadurch aus, dass sie passgenau sind. Für jedes agile Rahmenwerk, für jedes Umfeld und für verschiedene Situationen gibt es Metriken, die besonders geeignet sind. Alle Metriken haben gemeinsam, dass die Messungen zur Erhebung jederzeit einfach wiederholt werden können und dass die Metrik eine Bedeutung z. B. für die Steuerung oder die Entscheidungsfindung hat.
Im Idealfall lässt sich eine Metrik schnell erheben und die Aussagekraft schnell erfassen. Wenn die Metrik zusätzlich einen für die Lösungsfindung relevanten Teilaspekt abbildet, dann ist sie für den Kontext gut geeignet. Wenn eine Metrik hingegen in ihrem Kontext keinem Ziel dient, ist sie nutzlos und kann eingestellt werden. Auch Metriken, die nur sehr aufwändig zu ermitteln sind, sollten mindestens überdacht werden - Der Nutzen sollte dann entsprechend hoch sein.
Bevor also etwas gemessen wird, muss immer die Frage nach dem konkreten Nutzen gestellt werden. Um diesen Nutzen auch praktisch zu haben, müssen die Metriken regelmäßig in Dailys, Weeklys, Retrospektiven oder anderen Events thematisiert werden.
Interne und Externe Metriken
In der agilen Praxis unterscheide ich zwischen externen und internen Metriken. Die externen Metriken bilden dabei einen überschaubaren und stabilen Kern ab, der es außenstehenden ermöglicht die wichtigsten Informationen zu bekommen und schnell die richtigen Fragen zu stellen. Die internen Metriken sind grundsätzlich auch frei zugänglich, müssen sich aber in erster Linie dem Team erschließen. Hier werden häufig für temporäre Problem- oder Fragestellungen Daten erhoben und transparent gemacht.
In der konkreten Umsetzung hat es sich bewährt bei den externen Metriken für alle Teams identisch ermittelte Werte zu verwenden. Irrtümlich wird oft die Vergleichbarkeit als Begründung angeführt, die ist allerdings gar nicht Zweck und Ziel. Vielmehr können Außenstehende schnell die Metrik verstehen und die richtigen Fragen zum Einordnen des angezeigten Wertes zu stellen.
Metriken in der Praxis
Grundsätzlich sollte eine Metrik nicht um ihrer selbst willen erhoben werden. Vorgeschaltet steht die Frage im Raum „Welche Basiswerte bestehen und wie kann ich sie darstellen bzw. ins Verhältnis setzen, um Informationen gewinnen zu können, damit ich mich stetig verbessern kann?“ Von daher sind die folgenden Beispiele nicht dahingehend zu verstehen, dass diese Metriken notwendiger Weise in einem agilen Umfeld vorhanden sein müssen. Vielmehr sollte jedes Team eigene Metriken definieren. Die Beispiele dienen also eher der Anregung und sind nicht abschließend.
Burndown
Die wohl bekannteste Metrik im agilen Umfeld, die oft bei Scrum anzutreffen ist, ist der Burndown-Chart. Hier werden täglich die offene und die erledigte Arbeit eines Scrum-Sprints, eines Epics oder eines Feature erhoben und grafisch dargestellt. Die Erhebung erfolgt häufig anhand von Storypoints einer User Story.
Neben der noch offenen Arbeit ist die Darstellung einer Ideallinie ein wesentlicher Bestandteil, da die Darstellung ohne die Ideallinie an Informationsgehalt verliert. Weicht der Chart wesentlich von der Ideallinie ab, so muss das verantwortliche Team prüfen, welche Maßnahmen getroffen werden können, um die geplante Arbeit noch in der verbliebenen Zeit abzuschließen.
In Abbildung 1 wird die offene Arbeit hervorgehoben, die noch zu erledigen ist. Eine Darstellung der erledigten Arbeit als Burnup-Chart (Start bei 0 Punkten und Entwicklung bis zum committen Storypoint-Wert) ist aber auch gebräuchlich.
Velocity
Eine weitere bekannte Metrik, die häufig im Scrum-Umfeld eingesetzt wird, ist die Velocity. Hier wird ermittelt, wie viel Arbeit in einem definierten Zyklus erledigt wurde. Im Regelfall wird die Anzahl der Storypoints, die ein Scrum-Team während eines Sprints erledigt hat, dargestellt. Ihre Aussagekraft erhält die Metrik erst bei einer Darstellung im Zeitverlauf.
Die Darstellung gibt im Kontext von Scrum dem Product Owner einen Hinweis, wie viele Storypoints für einen Spring eingeplant werden können, um anhand dieser Informationen eine Product-Roadmap zu erstellen. Das Scrum-Team erhält bei Einbrüchen oder schleichender Verschlechterung einen Impuls, um auf Ursachenforschung zu gehen und Maßnahmen für eine Verbesserung oder Stabilisierung zu erarbeiten. Dies kann z. B. sehr gut in einer Retro thematisiert und mit konkreten Maßnahmen definiert werden. Die definierten Maßnahmen können dann anhand der Metrik nachfolgend kontrolliert werden.
Kumulatives Flussdiagramm
Eine weitere Metrik, um mögliche Engpässe zu erkennen ist das kumulative Flussdiagramm. Hier wird im Zeitverlauf dargestellt, zu welchem Zeitpunkt wie viele User Stories in welchem Status waren.
Erkennbar ist in welchem Bereich Engpässe zu suchen und durch Maßnahmen zu beseitigen sind. Ziel sollte es sein, dass die Linien möglichst parallel zueinander verlaufen damit ein optimale Fluss der ein- und ausgehenden Arbeit stattfindet. Auch hier müssen zur detaillierten Analyse ggf. weitere Metriken temporär im betroffenen Team erhoben werden. Diese Metrik wird insbesondere von IT-Managern fälschlicherweise zur Statuskontrolle genutzt. Wie bereits erwähnt, ist dies nicht das Ziel und eine Kombination mit anderen Metriken sowie Informationen im Daily helfen ungemein bei der Präzisierung.
Durchlaufzeit
Bei der Durchlaufzeit wird die Zeit erhoben, die eine Anforderung von einem bestimmten Punkt im Anforderungsprozess (z. B. Zeitpunkt der Ticketerstellung) bis zu einem bestimmten Punkt im Auslieferungsprozess (z. B. Zeitpunkt der Ticketschließung) benötigt. Für die Messung ist es notwendig, dass sowohl die beiden Messpunkte als auch der dazwischenliegende Prozess eindeutig und präzise beschrieben sind. Darüber hinaus muss auch Außenstehenden klar sein, welcher Zeitraum hier betrachtet wird.
Die einzelne Durchlaufzeit bringt noch keinen Erkenntnisgewinn, erst die Betrachtung des Durchschnittswertes im Zeitverlauf lässt Tendenzen erkennen und liefert damit den Impuls für Maßnahmen.
Im Idealfall sind weitere Messpunkte im Durchlauf vorhanden (z. B. Zeitpunkt von Statusänderungen), die für eine Analyse betrachtet werden können. Hier kann dann für die detailliertere Betrachtung temporär eine zusätzliche Metrik aufgestellt werden und nach Klärung wieder eingestellt werden.
Anzutreffen ist diese Metrik häufig im Kanban-Umfeld, kann aber auch für User Stories in Scrum-Teams verwendet werden. Im Sinne eines möglichst hohen Durchsatzes liegt der Fokus oftmals auf einer möglichst kurzen Durchlaufzeit. Aber auch konstante Durchlaufzeiten haben mit Blick auf Planbarkeit einen Vorteil, um so dem Kunden eine genauerer Zusage der Lieferung geben zu können.
Entwicklungstage
Die Messung der Entwicklungstage ist nicht nur im Scrum-Umfeld gebräuchlich. Häufig sind auch Bezeichnungen wie Teamkapazität oder Plankapazität für die Metrik zu finden. Gemessen wird hier, die Anzahl der in einem definierten Zeitraum (z. B. Scrum Sprint) verfügbaren Entwicklungstage. Dies kann entweder als Plankapazität am Anfang eines Sprints oder retrospektiv als Entwicklungskapazität am Ende eines Sprints erfolgen.
Die Kapazität wird dabei im Regelfall als Verhältnis von ermitteltem Wert zum theoretischen Wert bei Vollverfügbarkeit (ohne Ausfälle und Abwesenheiten) in Prozent dargestellt.
In Kombination mit der Velocity im Zeitverlauf können ggf. Wechselwirkungen der Teamkapazität zur Velocity erkannt und so ein Impuls für Maßnahmen gesetzt werden (z. B. Teamstabilität sicherstellen).
Störungen
Der im agilen Umfeld wichtige Wert „Fokus“ wird im Allgemeinen schnell von allen Beteiligten akzeptiert. Dennoch ist es einer der Punkte, die am häufigsten für Konflikte sorgen. Sei es im Bereich von Scrum und Kanban oder aber bei der Arbeit mit anderen agilen Rahmenwerken, Störungen treten auf und ab einem gewissen Grad muss gegengesteuert werden.
Damit die Messung der Störung nicht selbst zu einer weiteren Störung wird, sollte dies schnell und einfach passieren. Hier bietet sich die unkomplizierte Messung über ein zentral im agilen Workspace platziertes Flipchart an. Jede Störung erhält pro angefangene 15 Minuten einen Strich. Am Ende des Tages können dann die Striche gezählt werden und man hat ein einfaches Maß für Störungen. Für eine detaillierte Analyse können bestimmte Störungen (z. B. Supportanfragen) auch in einer anderen Farbe dargestellt werden. Alternativ können auch etwas verspielter (Tisch-)Tennisbälle in einem Gefäß als Maß dienen.
Agile Reife
Den verschiedenen agilen Rahmenwerken ist unter anderem gemein, dass sie von einem ständigen Verbesserungsprozess profitieren. In regelmäßigen Abständen wird der aktuelle Standpunkt festgestellt, Verbesserungspotenzial identifiziert und konkrete Veränderungsmaßnahmen initiiert. In der Realität sind die verschiedenen agilen Rahmenwerke selten bis nie allein und exklusiv im Einsatz. Um hier trotzdem einen kontinuierlichen Verbesserungsprozess zu etablieren, haben sich Modelle zur Bestimmung der agilen Reife etabliert.
Anhand dieser Reviews wird der aktuelle Standpunkt bestimmt, um im Anschluss Verbesserungspotenziale zu identifizieren und konkrete Maßnahmen zur Verbesserung zu initiieren.
Diese Metrik ist zwar nicht einfach zu erheben, bietet dafür aber einen tiefen Blick über viele Aspekte hinweg. Dieses Werkzeug sollte insbesondere von agile Coaches im Unternehmen genutzt werden, um Teams und die Organisation schrittweise weiterzuentwickeln.
Metriken und Agile Rahmenwerke
Agilität begegnet einem selten auf der grünen Wiese. Daher gibt es in den verschiedenen agilen Rahmenwerken laufend Kontakt zu Metriken und Kennzahlen, die nicht unbedingt zur Agilität passen. Hier ist es wichtig zwischen den für die Agilität relevanten Metriken und den anderen Metriken im Umfeld zu trennen. Im Folgenden finden sich einige Beispiele – wieder ohne Anspruch auf Vollständigkeit.
Scrum
Im Rahmen der Softwareentwicklung mit Scrum begegnet man zwangsläufig irgendwann dem Thema Test im agilen Umfeld. Der Test im agilen Umfeld unterscheidet sich von dem im klassischen Umfeld (siehe auch „Qualität als Erfolgsfaktor für Softwareprojekte“). Die Metriken zur Bestimmung der Qualität sind aber im Wesentlichen identisch. Aber auch hier gilt es nur das zu messen, was auch einen Mehrwert bring. So ist es wenig zielführend allein die Anzahl der Zeilen Code zu zählen oder permanent die zyklomatische Komplexität zu ermitteln. Dies ist für den Test oder die Testmethodik an einigen Stellen sicherlich unerlässlich, aber damit trotzdem keine Metrik im agilen Sinne.
Als allgemeiner Indikator in der agilen Softwareentwicklung werden häufig die Anzahl bekannter Fehler während der Entwicklungsphase und die Fehler nach Abnahme im Zeitverlauf gegenübergestellt. Dies wäre ein Beispiel für eine externe Metrik im agilen Umfeld.
Bei dieser Metrik ist es besonders wichtig den Kontext zu betrachten, um eine Aussage und damit mögliche Maßnahmen abzuleiten. So kann z. B. die Zahl der Fehler in der Entwicklung dadurch steigen, dass der Test mit dem Ziel intensiviert wurde, weniger Fehler in der Auslieferung an die Kunden zu geben.
Design Thinking
Im Design Thinking ist ein wesentlicher Punkt, dass im Laufe des Prozesses neben möglichen Lösungen auch Metriken gefunden werden müssen, mit deren Hilfe die Wirksamkeit der Lösung überprüft werden kann. Dreht sich die Fragestellung zum Beispiel um das Thema Steigerung der Kundenbindung, muss auch eine Metrik entwickelt werden, die die Kundenbindung abbildet.
Spätestens zusammen mit dem Prototyp muss also auch eine Metrik zur Kontrolle bereitstehen. In der Praxis wird daher häufig schon in den Phasen 1 und 2 die Metrik erarbeitet, anhand derer die Reaktion des Kunden auf die Lösung gemessen werden kann. Diese Metriken müssen dabei vor allen Dingen eins sein – einfach. Manchmal genügt es schon zu wissen, dass eine bestimmte Anzahl von Kundinnen und Kunden die Absicht äußern ein Produkt anzunehmen.
OKR
Im Bereich von OKR spielen Metriken eine große Rolle, obwohl es für OKR selbst keine gebräuchlichen Metriken gibt. Hier werden bereits bestehende Metriken genutzt, um Objectives abzuleiten und später nach Umsetzung die Wirksamkeit der Umsetzung zu überprüfen. Auch wenn sich bestehende Metriken auf den ersten Blick gut dafür eignen sie direkt in messbare Key Results umzumünzen, so sollte doch stets das Problem herausgearbeitet werden, was dem gewünschten Zielmesswert im Wege steht. Für dieses Problem können dann Objectives und Key Results formuliert werden.
Fazit
Gemessen werden kann viel, aber nur eine geschickte Auswahl und die kluge Verwendung weniger Metriken bringt am Ende auch einen Mehrwert. Die Auswahl hängt wiederum von den eingesetzten agilen Rahmenwerken, dem spezifischen Umfeld und den konkreten Fragestellungen ab. Wir empfehlen, Metriken gemeinsamen mit dem Team bzw. den Teams aufzubauen. Die in dem Artikel vorgestellten Metriken können als Inspiration dienen. Nach dem Start, sollten Metriken laufend in z. B. Dailys, Retros und Reviews integriert und weiterentwickelt werden. Nur so wird ein Nutzen daraus generiert und eine laufende Verbesserung der individuellen Stärken und Schwächen initiiert.
Die frobese GmbH unterstützt gerne bei der gemeinsamen Definition interner und externer Metriken für ihr Team und ihre Organisation sowie der zielgerichteten Umsetzung. Kontaktieren Sie mich / uns gern.
Über Christian Mercier
