„Was gemessen wird, wird erledigt!“ Diesen Satz lesen Sie bestimmt nicht zum ersten Mal. Sind Sie derselben Meinung? Ich bin hin und her gerissen. Nur mal angenommen, die Aussage trifft zu, gilt sie auch in der agilen (Produkt-) Entwicklung? Agilität bedeutet nicht, wie so häufig propagiert, primär Schnelligkeit, sondern vielmehr Flexibilität. Flexibilität beschreibt in diesem Kontext wiederum die Fähigkeit, auf sich ändernde Anforderungen zu reagieren. In Zeiten von Agilität stellen sich demnach unbedingt die Fragen, ob Metriken überhaupt noch benötigt werden und müssen wir auch in Bezug auf Kennzahlen flexibel sein, uns auf veränderte Anforderungen einstellen?
Die Notwendigkeit von Metriken und die Rolle von Vertrauen
Die Frage, ob wir im agilen Umfeld Metriken brauchen, ist leicht zu beantworten. Um teilweise mit Ken Schwabers Worten zu sprechen: „Wenn das Produkt die bestmögliche Software unter Berücksichtigung der Kosten, der Funktionalität, der Zeit und der Qualität ist“, dann kann man davon ausgehen, dass Metriken keineswegs irrelevant sind, sondern immanent. Um die „magischen“ Faktoren berücksichtigen zu können, müssen sie zunächst gemessen werden.
Bevor ich näher auf die anderen aufgeworfenen Fragen eingehe, verzeihen Sie mir, dass ich Sie kurz „entführe“: Es ist kein Geheimnis, dass Vertrauen im agilen Umfeld eine zentrale Rolle spielt. Ohne lange um den heißen Brei herumzureden: Agile Teams funktionieren nicht ohne Vertrauen! Vielleicht fragen Sie sich, was diese, zugegebener Maßen nicht ganz neue Erkenntnis mit Metriken zu tun hat? Eine Gegenfrage: Was passiert mit Vertrauen in einem Scrum-Team, wenn der Scrum Master anfängt, alle möglichen Metriken zu erheben und im Zweifel auch noch einen Report darüber verfasst? Die „Gesundheit“ eines Teams baut auf vertrauensvollen Verhältnissen auf. Bei der Frage nach den relevanten Metriken spielt das Vertrauen also insofern eine Rolle, als dass im Sinne der maximalen Transparenz, immer auch allen Beteiligten klar sein sollte, wofür eine Kennzahl ermittelt wird.
Welche Metriken sind im Rahmen einer agilen Vorgehensweise also relevant? Ich hoffe Sie sind mit mir einer Meinung, wenn ich schreibe, dass z. B. die Produktivität eines Entwicklungsteams definitiv nicht durch die Zeilenanzahl an Code gemessen werden, und dass Produktivität am besten anhand der hoffentlich entstehenden Funktionalitäten bewertet werden kann. Des Weiteren gehe ich davon aus, dass wir uns einig sind, wenn ich außerdem schreibe: Der Blick auf die letztlich entstandenen Funktionalitäten kann aus Unternehmenssicht nicht ausreichen. Wir erheben Metriken nicht um ihrer selbst willen, sondern sie helfen vielmehr bei der Erreichung bestimmter Ziele. Ganz allgemein beschrieben, möchten die meisten Unternehmen den Arbeitsfortschritt sichtbar machen, die Qualität der Arbeitsergebnisse messen und damit letztendlich möglichst gute Entscheidungen treffen können.
Velocity, Velocities und der Velocity Faktor
Die am meisten verwendete Metrik ist wahrscheinlich die sog. Velocity – sei es die Sprintvelocity auf Teamebene oder im Fall von skaliertem Scrum die Programm-, Produkt- oder Portfolio-Velocity. Gemessen wird die Geschwindigkeit, in der neue Funktionalitäten geliefert werden und das scheint auf allen Ebenen eines modernen Unternehmens relevant. Aber relevant wofür? Der Vorwurf, dass man sie heranzieht, um die Teams zu überwachen, liegt leider nahe. Meines Erachtens greift dieser Vorwurf jedoch zu kurz. Zweifellos können Geschwindigkeitskennzahlen dazu missbraucht werden, um eine niedrige Geschwindigkeit zu bestrafen und hohe Geschwindigkeiten zu belohnen. Ich schreibe allerdings bewusst „missbrauchen“, denn eigentlich ist einer der Vorteile von einer kontinuierlich gemessenen Velocity im agilen Kontext die Befähigung zu einer validen Vorhersage. Eine solche Vorhersage erhebt, im Gegensatz zum klassischen Projektplan, zwar nicht den Anspruch einer hundertprozentigen Genauigkeit, ist in der Kommunikation zwischen Business und IT jedoch trotzdem essentiell.
Neben der gerade beschriebenen, üblichen Velocity, können noch weitere Velocities gemessen werden. Scrum fokussiert bekanntlich den Mehrwert für den Kunden. Dieser Mehrwert kann ähnlich wie die Komplexität pro User Story in Punkten bewertet werden. Man spricht von sog. Value Points. Mit Hilfe von Value Points bewertet der Product Owner den Mehrwert, der durch eine User Story generiert werden kann. Warum messen wir also nicht auch die Value Velocity? Diese Kennzahl hilft dem Team den kumulierten pro Iteration realisierten Mehrwert für die Kunden sichtbar zu machen.
Zwei einfache und häufig erhobene Kennzahlen sind außerdem die Anzahl der Story Points, die am Sprintende tatsächlich geliefert werden und die Punktanzahl, auf die sich zu Sprintbeginn verpflichtet wurde. Beide Zahlen ins Verhältnis gesetzt, also Story Points done / Story Points committed liefern einen Faktor, nennen wir ihn Velocity Faktor, der zeigt wie viel Prozent des Sprintzieles ein Team tatsächlich realisiert. Je näher der Velocity Faktor an der Eins ist, desto besser schätzt das Team die eigene Leistungsfähigkeit ein. Ein guter Velocity Faktor ist eine Voraussetzung, um Stakeholdern gegenüber eine realistische Schätzung der in einer bestimmten Zeit lieferbaren Funktionalität abzugeben, ebenso um abzuschätzen, wie viele Sprints ein Team voraussichtlich benötigt, um eine bestimmte Funktionalität zu liefern.
Test – wir automatisieren und decken ab
Testautomatisierung ist eine weitere weit verbreitete Metrik, ja sogar ein Allheilmittel, wenn man Teilen der Literatur glauben möchte. Sie hilft bei der Beseitigung von Stolpersteinen und Zeitfressern wie dem Beheben von Fehlern, in dem automatische Tests u. a. den Code modular und sauber halten sowie Regression verhindern. Das Ganze funktioniert selbstverständlich nur im Fall einer hohen Testabdeckung. Eine 90-prozentige Testabdeckung bedeutet zwar nicht zwangsläufig, dass 90 % des Codes „sauber“ ist, trotzdem muss eine hohe Testabdeckung doch irgendetwas Gutes bedeuten, oder nicht? Ist es wirklich logisch, dass ein besonders guter Code auch eine besonders hohe Testabdeckung aufweist und belegt eine hohe Testabdeckung umgedreht auch zwangsläufig einen gut geschriebenen Code? Grundsätzlich ist doch auch ein nicht funktionierender Code bei einer hundertprozentigen Testabdeckung möglich. Wenn ich ehrlich sein soll, fehlt mir das IT-Know-How, um diese Frage fachlich detailliert zu beantworten. Nichtsdestotrotz werfe ich die Frage an dieser Stelle auf, da ich noch keine befriedigende Antwort gefunden habe. Wenn Sie also eine haben, immer her damit!
Einseitige Metriken, die Qualität und glückliche Teams
Neben den exemplarisch beschriebenen Metriken existieren noch viele weitere. Da ich nicht den Anspruch erhebe, alle Metriken im Detail zu kennen und ich Sie ohnehin nicht mit einer ausführlichen Liste langweilen will, nur noch eine letzte Frage: Sind Sie auch der Meinung, dass die Erhebung von Metriken an sich bereits die gemessene Leistung verbessert? Ich bin es nicht, insbesondere dann nicht, wenn die erhobenen Kennzahlen rein leistungsbezogen sind. Ein möglicher Effekt ist, dass vordergründig die Leistung gesteigert wird, die Frage wodurch die Leistungssteigerung hervorgerufen wurde allerdings oftmals außen vor gelassen wird. Es kann sein, dass die Einführung einer Metrik (z. B. der Velocity), motivierend wirkt und ein agiles Team effizienter wird. Es kann aber auch sein, dass die Metrik Druck aufbaut und das Wissen, dass beobachtet wird, dazu führt, dass man zwar schneller liefert, jedoch auf Kosten der Qualität! Um das Risiko genau eines solchen Effektes zu reduzieren, kann es helfen, zusätzlich auch Metriken wie z. B. das Wohlbefinden des Teams zu messen. Etwas esoterischer, jedoch nicht weniger wichtig als andere Metriken, wird das Wohlbefinden auf einer Skala oder mit einer einfachen Ja-Nein-Abfrage gemessen. Ich gehe sogar so weit zu behaupten, dass Wohlbefinden (auch bekannt als Zufriedenheit oder Glück) sämtliche andere Metriken bedingt. Je glücklicher ein Team, desto höher die Produktivität. Der wesentliche Unterschied des Wohlbefindens im Vergleich zu den anderen zuvor erwähnten Metriken ist, dass es an sich an Objektivität mangelt und wir streng genommen nicht von einer Metrik sprechen können. Diese Erkenntnis ändert jedoch nichts an der Nützlichkeit des Gemessenen für das jeweilige Team, denn auch Dinge, die nicht objektiv messbar sind, können verbessert werden.
