Alle Unternehmen, die wir bislang kennenlernen durften, setzen heute agile Entwicklungsmethoden ein oder denken darüber nach, sie einzusetzen. Die agile Entwicklung ist aus der IT überhaupt nicht mehr wegzudenken und breitet sich auch in anderen Unternehmensbereichen aus, etwa in Form von agilem Projektmanagement. Woran aber erkennt man, dass die Einführung agiler Vorgehensweisen wirklich zu einer Verbesserung geführt hat?
Unternehmen führen agile Entwicklungsmethoden wie Scrum ein, weil sie sich davon konkrete Verbesserungen versprechen wie
- Höhere Produktivität in der Entwicklung
- Kürzere Time-to-Market
- Kostensenkungen
- Höhere Kundenzufriedenheit
Diese Hoffnung speist sich nicht zuletzt aus dem nicht selten anzutreffenden Empfinden, dass die bisherige Anwendungsentwicklung zu langsam und zu teuer sei und am Ende nicht das produziere, was man haben wolle.
Aber treten diese Verbesserungen auch nach angemessener Zeit mit agiler Vorgehensweise ein? Wie lässt sich das messen?
Kennzahlen in der Applikationsentwicklung. Voraussetzung für alle Messbarkeit ist, dass man überhaupt in der Lage ist, in der Applikationsentwicklung etwas zu messen. Entsprechende Kennzahlensysteme sind für die Applikationsentwicklung noch nicht sehr weit verbreitet.
Da sich die Applikationsentwicklung bekanntermaßen immer im Spannungsfeld von Kosten, Zeit und Qualität bewegt, sind dies aus unserer Sicht auch die wesentlichen Dimensionen für die Messung von Erfolg.
Ein einfaches Kennzahlenset ist zum Beispiel:
- Kosten: Aufwand pro Einheit (Personentage pro Function Point – mehr dazu später)
- Zeit: Time-to-Market, das heißt Dauer von Projektbeginn bis zur ersten Nutzung von Funktionalität durch den Kunden
- Qualität: Kundenzufriedenheit auf einer gegebenen Skala
Diese Kennzahlen können sowohl auf Projektebene als auch übergreifend für ein Team oder die Entwicklung insgesamt erhoben werden.
Das Set sieht einfach aus, der Teufel steckt aber im Detail: Es wird eine Einheit benötigt, die als Referenz herangezogen wird, um Projekte vergleichbar zu machen.
LEXTA verwendet dazu die Metrik Function Points [1]. Die Messung von Function Points ist in Unternehmen nicht sehr weit verbreitet, da sie aufwendig und erst nach Abschluss des Projekts fundiert möglich ist. Für LEXTA als Benchmarker ist es die einzig nutzbare Metrik, um die Komplexität von Applikationsentwicklungsprojekten unternehmensübergreifend und standardisiert vergleichen zu können. Wenn wir bei LEXTA Applikationsentwicklungsprojekte benchmarken, erheben wir immer die im Projekt geschaffene Anzahl Function Points, ohne geht es nicht. Für die von LEXTA untersuchten Projekte liegt daher diese Kennzahl vor.
Im einzelnen Unternehmen gibt es aber möglicherweise auch eigene Alternativen, die sich als Vergleichseinheit heranziehen lassen. So existieren etwa verschiedene Abwandlungen von Use Case Points oder Story Points, die sich nutzen lassen, manchmal auch »Anforderungspunkte« (zur Bewertung der Komplexität von Anforderungen). Auch die Anzahl der Testfälle oder Regressionstestfälle kann als Komplexitätsmaß und Vergleichseinheit geeignet sein. Hier ist also zunächst Kreativität gefragt.
Time-to-Market. Die Time-to-Market für ein Projekt fällt ebenfalls nicht einfach aus einem Reporting-System. Fragt man die Projektleiter, können sie aber die Dauer zwischen Projektbeginn und erster Nutzung von Funktionalität durch den Kunden recht genau angeben (etwa nach dem ersten Release oder nach dem ersten Sprint). Will man die Kennzahl durchgängig erheben, muss also eine Möglichkeit bestehen, diese für jedes abgeschlossene Projekt beim Projektleiter abzufragen. Diese Möglichkeit bietet sich zum Beispiel im Rahmen des Projektabschlussprozesses – wir kommen gleich noch einmal darauf.
Messung der Kundenzufriedenheit. Eine weitere Herausforderung besteht in der Messung der Kundenzufriedenheit. Zwar gibt es dazu standardisierte Verfahren wie den Net Promoter Score [2], aber die Erhebung ist trotzdem relativ aufwendig. Zudem wird die Kundenzufriedenheit bezogen auf ein einzelnes Projekt benötigt.
Bewährt hat sich hier eine kurze und knappe Abfrage der Kundenzufriedenheit im Rahmen des Projektabschlussprozesses (auch bekannt als Projekt-Post-Mortem). Die Bedeutung eines kurzen Innehaltens nach Abschluss des Projekts und der Wert von dokumentierten Erfahrungen (Lessons Learned) für Folgeprojekte und andere Mitarbeiter wird in vielen Unternehmen geschätzt, so dass ein entsprechender Prozess zum endgültigen Abschluss eines Projekts vielerorts existiert. Wenn man nun ohnehin zusammenkommt, um gute und schlechte Erfahrungen im Projekt zu dokumentieren, ist es wenig Mehraufwand, beim Kunden mit einer Frage die Zufriedenheit mit dem Projekt abzufragen. Je stärker der Projektprozess durch ein Workflow-Management-System unterstützt wird, desto weniger Mehraufwand fällt für eine solche Abfrage an, die mit einem Klick beantwortet werden kann (wie beispielsweise in den Sanifair-Toilettenanlagen).
Ausgangslage muss bekannt sein. Um den Erfolg einer Maßnahme wie der Einführung agiler Vorgehensweisen messen zu können, muss nun die Ausgangslage bereits eine Weile vermessen worden sein, um den Ausgangszustand (auch »Baseline« genannt) zu definieren, gegen den die Veränderung gemessen wird.
Das heißt, bevor mit der Einführung agiler Methoden begonnen wird, muss – unter Verwendung des obenstehenden Beispiels – folgendes bekannt sein:
- Kosten: Durchschnittlicher Aufwand in Personentagen pro entwickeltem Function Point oder anderer Einheit (über alle betrachteten Projekte hinweg)
- Zeit: Durchschnittliche Time-to-Market
- Qualität: Durchschnittliche Kundenzufriedenheit
Das ist schwierig, aber machbar. Die Kennzahlen lassen sich auch im Nachhinein noch ermitteln, sofern auf Daten zu abgeschlossenen Projekten zurückgegriffen werden kann.
Den Erfolg der agilen Transformation messen. Ist die Hürde der Etablierung von Kennzahlen in der Applikationsentwicklung einmal genommen, ist die Messung des Erfolgs der agilen Transformation einfach. Um die oben genannten Erwartungen an den Nutzen agiler Vorgehensweisen zu erfüllen, sollten alle drei Kennzahlen (Kosten, Zeit und Qualität) eine Verbesserung anzeigen: Die Kosten sind gesunken, die Time-to-Market hat sich verkürzt, die durchschnittliche Kundenzufriedenheit ist besser.
Wichtig ist, dass hier auf aggregierter Ebene verglichen wird – also pro Team, für die gesamte Entwicklung, nicht zwischen einzelnen Projekten. Außerdem muss ein Zeitpunkt festgelegt werden, der als »vor der Einführung« gelten soll, und einer, zu dem die Einführung abgeschlossen ist und die agile Entwicklung stabil läuft. Die Veränderung zwischen diesen beiden Zeitpunkten zeigt die Verbesserung durch die Änderung an.
»Bis die agile Entwicklung stabil läuft« ist dabei ein unbestimmter Zeitraum. Keinesfalls aber sollte er zu kurz gewählt werden, da die Teams Zeit brauchen, die neuen Vorgehensweisen zu etablieren. Wir empfehlen mindestens ein Jahr.
Nun ereignen sich meist während dieser Zeit noch andere Dinge, die die Messung beeinflussen. Mitarbeiter kommen und gehen, Fachbereiche werden umorganisiert, neue Technologien eingeführt. Diese »Störfaktoren« beeinflussen ebenfalls unsere Kennzahlen für Kosten, Zeit und Qualität. Sofern sie sich nicht herausrechnen lassen, sollten sie mindestens dokumentiert werden, um das Ergebnis einordnen zu können.
So einfach ist es also, den Erfolg agiler Entwicklung zu messen. Das Schöne an einem Kennzahlensystem für die Applikationsentwicklung ist, dass man damit auch den Erfolg anderer Maßnahmen messen kann – wenn also der nächste Hype kommt, sind Sie schon vorbereitet …
Dr. Ursula Löbbert-Passing promovierte 2004 über Methoden zur Aufwandschätzung für Softwareprojekte. Die Kosten für Applikationen ließen sie seither nicht mehr los. Bei LEXTA ist sie verantwortlich für die Benchmarkingmethoden für Applikationsbetrieb und -entwicklung.
www.lexta.com
[1] siehe https://de.wikipedia.org/wiki/Function-Point-Verfahren
[2] siehe https://de.wikipedia.org/wiki/Net_Promoter_Score
Illustration: © Stakes, KASUE, Kannunikov Pavlo, Login /shutterstock.com
Kundenfreundliche Frontends – Bimodale IT ermöglicht agile Entwicklung
Plattform für agile und gesetzeskonforme Software-Entwicklung – Datenmaskierung mit DataOps
Deutsche Entwicklerbranche setzt auf agile Software-Entwicklung
Internationale Studie zur Softwareentwicklung: Deutschland auf Spitzenplatz
IT-Organisationen benötigen Cloud für agile Prozessstrukturen
DevOps: Praktische Auswirkungen auf ITSM – Agiles IT Service Management