Auf dem Agile Camp Berlin gab es eine interessante Session zum Thema “KPIs / Time Predictability”. Es ging darum, welche Metriken oder Key Performance Indicators (KPIs) für ein Team in der agilen Softwareentwicklung angewandt werden sollten, und wie man vorhersagen kann, wann bestimmte Aufgaben (oder ganze Projekte) fertig sind. Die Session war als Fish Bowl organisiert, so dass viele TeilnehmerInnen mit ihren eigenen Erfahrungen und Tipps zu Wort kommen konnten.
Beim Zuhören und Mitdiskutieren fiel mir auf, dass ich doch einige Meinungen zum Thema habe. Diese Meinungen will ich heute und morgen mal darlegen, vielleicht kann ich Sie ja zu einem Kommentar verleiten…
Welche Metriken (KPIs) sollte man für agile Teams erfassen?
Vorher muss ich noch ein bisschen grundsätzlich werden. Ich werde beim Thema KPIs immer vorsichtig, weil sie so verführerisch sind: Endlich muss die Führungskraft sich nicht mehr inhaltlich mit der Arbeit der Untergebenen auseinandersetzen, es reicht ja, die KPIs im Auge zu behalten und entsprechend zu reagieren. Also nutzen Sie bitte keine Metriken, um:
Warum? Das wäre einen eigenen Text wert, oder Sie lesen gleich “Schwarmdumm” von Gunter Dueck. Kurzfassung: Wenn man Druck ausübt, oder die Leute sich ungerecht behandelt fühlen, wird nur noch die Metrik optimiert, während das Gesamtergebnis leidet.
Ich sehe zwei Ziele, die man mit Metriken bzw. KPIs sinnvollerweise verfolgen kann:
Bei jeder Metrik muss man vorher festlegen, was genau eigentlich gezählt oder gemessen werden soll.
Was soll man zählen bzw. messen?
Stellen Sie sich vor, die sprichwörtliche gute Fee kommt vorbei und Sie dürfen sich eine Metrik wünschen. Welche Metrik wäre das bei Ihnen? Ich würde sagen: “Gib mir für jeden Monat einen Report, der sagt, wieviel Euro unser Software-Team in diesem Monat zum Betriebsergebnis der nächsten 20 Jahre beigetragen hat.” Das wäre doch toll, oder? Nie wieder Budget-Diskussionen, weil wir natürlich jeden Monat viel mehr einbringen als wir kosten.
Die zweitbeste Metrik: Der Wert, den ein Endkunde unserem Feature, Release o.ä. beimisst. Im E-Commerce ist das noch relativ einfach anzunähern: Steigerung im Customer Lifetime Value multipliziert mit Anzahl der Kunden. Wenn Sie also die Möglichkeit haben, den Einfluss eines neuen Features in Euro und Cent zu bestimmen, sollten Sie das unbedingt tun.
Oft wird man etwas anderes messen müssen, das nur indirekt mit dem Kundennutzen zusammenhängt: den “Output” des Entwicklungsprozesses, also User Stories, Tickets, Features usw. Was sollen wir da genau zählen? Jedes einzelne Ticket, inklusive technischer Tasks wie z.B. “Upgrade MySQL”? Sollen Bugs mitgezählt werden? Sollen aufwändige Tickets mehr zählen als Dinge, die wir in einer Stunde erledigt haben?
Es hilft wieder, sich auf den Nutzen aus Sicht des Kunden zu konzentrieren. Bugfixes und Datenbank-Upgrades sind zwar notwendig, liefern aber keinen Kundennutzen. Wenn Sie unsicher sind, fragen Sie einfach: “Würde der Kunde uns mehr bezahlen, wenn wir mehr davon tun?” Der Kunde hätte am liebsten gar keine Bugs, er zahlt nur zähneknirschend für unsere Bugfixes. Genauso verhält es sich mit Datenbank-Upgrades und ähnlichen technischen Aufgaben; wenn er könnte, würde der Kunde uns das Projekt sogar ganz ohne Datenbank abkaufen. Wir sollten also nur Dinge zählen, die für den Kunden sichtbar und wertvoll sind. (Sie ahnen vielleicht, was schief gehen kann wenn man daraus ein Anreiz-System macht, in dem z.B. Refactoring oder Security-Updates mit 0 Punkten bewertet werden…)
Je weiter unsere Metrik vom echten Kundennutzen entfernt ist, desto problematischer wird es. Ich könnte z.B. stolz verkünden “Wir haben in diesem Monat 50 Features fertig entwickelt”. Nehmen wir mal an, in unserem Software-Lieferprozess heißt “fertig entwickelt” nur, dass die Programmierer etwas für fertig halten. Die Features wurden also noch nie von einem Tester gesehen, und sie wurden auch noch nie einem Anwender vorgeführt. Wenn wir nun bei 20% dieser Features die Anforderung falsch verstanden haben, und vielleicht 123 Bugs unentdeckt sind, was ist meine Aussage “50 fertige Features” dann wert? So gut wie nichts, weil der Weg zum echten Kundennutzen für diese 50 Features noch sehr lang sein kann.
Eine gute Empfehlung zur sinnvollen Definition von “Output” liefert Ron Jeffries mit dem Konzept Running Tested Features:
From day one, until the project is finished, we want to see smooth, consistent growth in the number of Running, Tested Features.
- Running means that the features are shipped in a single integrated product.
- Tested means that the features are continuously passing tests provided by the requirements givers – the customers in XP parlance.
- Features? We mean real end-user features, pieces of the customer-given requirements, not techno-features like “Install the Database” or “Get Web Server Running”.
(Ron Jeffries: A Metric Leading to Agility)
Diese Metrik stellt ziemlich hohe Ansprüche: gleichmäßiges Wachstum an “Running Tested Features” schafft man nur, wenn man Tests automatisiert, häufig Subsysteme integriert, in hoher Qualität arbeitet usw. Deswegen spricht Jeffries davon, dass diese Metrik zu Agilität führt. Das ist doch schon mal nicht schlecht, oder?
Morgen geht es darum, wie man Metriken zur Verbesserung des Software-Lieferprozesses und für Prognosen einsetzen kann.
Matthias Berth