Zuerst erschienen in der Ausgabe .public 01-2019
von Christian Meyer
KPIs für agile Projekte – ein Erfahrungsbericht
Immer mehr IT-Projekte im öffentlichen Sektor gehen agil vor. Und das nicht nur auf der grünen Wiese, sondern im Rahmen klassischer Organisationsstrukturen. Dabei wird allerdings in den seltensten Fällen rein nach Scrum vorgegangen. Oft wird das Vorgehen an die besonderen Umstände im Projekt angepasst. Das ist auch gut so. Aber wie viel Anpassung ist nützlich? Und ab wann ist der Erfolg des Projektes gefährdet? Kann man den Erfolg messen? Sind KPIs in agilen Projekten sinnvoll und nützlich?
Diese Fragen kennt wohl jeder, der schon einmal erlebt hat, wie ein agiles Projekt gescheitert ist. Und das ist gar nicht so selten – auch wenn es im allgemeinen Hype um diese Methode gerne vergessen wird. Laut einer VersionOne-Umfrage „Gründe für das Scheitern agiler Projekte“ von 2014, in der über ein halbes Jahr 4.082 Personen in agilen Projekten befragt wurden, gab es in 82 Prozent aller befragten Projekte Probleme mit der Umsetzung agiler Methoden.1 Daher ist es sinnvoll, bei der umfassenden Einführung agiler Softwareentwicklung in großen Organisationen auch eine kompetente, aber neutrale Instanz zu schaffen, die alle agilen Projekte beraten und kontrollieren kann. Im Informationstechnikzentrum Bund (ITZBund), dem IT-Dienstleister für Behörden, arbeitet ein solches Projekt seit über zwei Jahren.
Das Projekt
Das Projekt EAGLE steht für die Einführung agiler Softwareentwicklung im ITZBund und erarbeitet seit 2017 mit einem interdisziplinären Team Standards für agile Projekte. Dabei liegt der Fokus darauf, was verändert und ergänzt werden muss, um in der klassisch geprägten Welt der Softwareentwicklung im ITZBund Bestand zu haben. Kernfragen, die sich das Projekt stellt, sind: Ab wann wird Agilität richtig eingesetzt? Ab wann muss das Vorgehen korrigiert werden? Welche Anhaltspunkte gibt es, um den Unterschied rechtzeitig festzustellen? Und für welche Art von Projekten ist agiles Vorgehen im Rahmen des ITZBund tatsächlich geeignet?
Da das Projekt EAGLE agiles Projektmanagement nicht nur als Theorie im ITZBund einführen, sondern auch aus der Praxis lernen wollte, wurden ausgewählte Pilotprojekte über ein Jahr begleitet, um zu sehen, was funktioniert und ab wann der Projekterfolg gefährdet sein könnte. Diese Erkenntnisse bildeten die Grundlage für KPIs (siehe unten). Projekte, die agil vorgehen möchten, werden diese KPIs in regelmäßigen Abständen überprüfen, um die Methodik des eigenen Vorgehens abzusichern.
Ist Agilität immer und für jedes Projekt geeignet?
Überzeugte Anwender sind der Meinung, es gebe keinen Grund, nicht agil zu entwickeln. Vorausgesetzt, es handelt sich um Projekte, bei denen iterative Ergebnisse sinnvoll sind. Doch die Erfahrung zeigt: Es gibt durchaus Kontexte, in denen agiles Projektmanagement nicht die erste Wahl ist.
Beispielsweise ist in bereits klassisch begonnenen Projekten eine Änderung hin zum agilen Vorgehensmodell nur mit erheblichem Aufwand möglich und damit in der Regel nicht sinnvoll. Die Struktur von Lasten- und Pflichtenheften sowie klassischen Abnahmetests zum Projektende hin zu verändern, ist oft sehr aufwendig, so dass es wohl sicherer und auch zeitsparender ist, weiterhin linear zu entwickeln.
Auch wenn zum Projektstart bereits ein vollständig erarbeitetes Lastenheft vorliegt und auf dessen Basis eine Qualitätssicherung durchgeführt wurde, ist ein Wechsel zum agilen Vorgehen nicht optimal. Hier mag es zwar möglich sein, das Lastenheft in User Storys zu überführen, aber da die abschließende Qualitätssicherung gegen die ursprünglichen Anforderungen des Lastenhefts durchgeführt wird, ist seine Anpassung durch Änderungen während der agilen Entwicklung nicht einfach und kann sich zu einem unnötigen Zeitfresser im Projekt entwickeln.
Wenig geeignet sind auch Projekte mit einem klar und verbindlich definierten Umfang sowie einer bereits in Vorgängerprojekten erprobten Umsetzungsweise. Auch hier kann Agilität zu einem Overhead führen. Und schließlich gibt es auch Konstellationen, in denen es nicht möglich ist, die Rolle des Product Owners umfänglich zu gewährleisten. Auch dann muss von einer agilen Vorgehensweise abgeraten werden.
Kann Agilität auch scheitern?
Auch wenn agiles Vorgehen viele Vorteile hat – ein Selbstläufer ist es bei Weitem nicht. Zwar sind die Regeln dieser Projektmanagement- Methode einfach zu lernen, aber längst nicht so einfach zu leben. Wie kommt das? Scrum besteht – im Vergleich zu anderen Projektmanagementmethoden – aus nur wenigen Regeln. Das ist kein Zufall, sondern eine bewusste Entscheidung. Der erste Leitsatz von Scrum lautet „Individuen und Interaktionen sind wichtiger als Prozesse und Werkzeuge“. Prozesse in Scrum sind auf vier Events (Ereignisse) reduziert, die unbedingt eingehalten werden müssen. Alle weiteren Ereignisse (im Sinne von Meetings) werden individuell und nach Bedarf abgestimmt und können immer wieder infrage gestellt werden (iterative Anpassung). Das Nichtvorhandensein weiterer detaillierter Prozessschritte soll durch Kommunikation und Eigeninitiative gefüllt werden. Mehr Kommunikation und weniger vorgegebene Regeln klingen zunächst zwar nach Freiraum, weil es die Chance zu mehr Kommunikation suggeriert. Doch es besteht das Risiko, dass dieser Freiraum durch selbst aufgestellte Regeln aufgefüllt wird. Anstatt zu kommunizieren und das eigene Vorgehen immer wieder zu analysieren und zu optimieren, ersetzen diese Regeln dann die teaminterne Kommunikation und verhindern damit einen Fortschritt in der Projektmethodik. Zwei Beispiele verdeutlichen diese Problematik (siehe Infobox).
Das Problem mit der Einstellung
Ein weiterer Hinderungsgrund ist die falsche Einstellung der Beteiligten. Die Mitarbeiterinnen und Mitarbeiter leben die Scrumwerte nicht so aktiv, wie es eine agile Organisationsentwicklung erfordert. Wenn Projekte zwar der agilen Methodik folgen, aber der Kunde, seine Stakeholder oder die Projektleitung das dafür nötige Verständnis nicht entwickeln, entstehen statt hochwertiger Ergebnisse Missverständnisse und unnötige Prozesse. Manchmal warten auch Vertreter klassischer Entwicklungsmethoden geradezu auf (vermeintliche) Fehler in der agilen Vorgehensweise, um die Methoden zu kritisieren. Daher ist eine Rückendeckung und Legitimation im oberen Management für diese Vorgehensweise unabdingbar.
Laut der VersionOne-Umfrage „Gründe für das Scheitern agiler Projekte“ scheitern agile Projekte vor allem aus folgenden Gründen:
Bei 53 Prozent der Befragten widersprach die Kultur beziehungsweise die Firmenphilosophie den agilen Werten. 42 Prozent fühlten sich nicht vom Management unterstützt, 35 Prozent haben Defizite in Training und Ausbildung gesehen und bei 31 Prozent fehlt der Product Owner.
Während 2014 noch 11 Prozent der Befragten „externen Druck, Wasserfall anzuwenden“ nannten, spielte dieses Thema im letzten Jahr keine Rolle mehr. Dafür gaben 14 Prozent Probleme mit der Compliance und anderen Regularien an.
Wie gelingt Agilität?
Nach der Prüfung dessen, was im agilen Projektmanagement alles schiefgehen kann, stellt sich die Frage, wie man feststellen kann, ob Agilität im Projekt richtig gelebt wird und zum Projekterfolg führt. Dafür liegt der Fokus darauf, welche Vorgehensweisen dazu führen, dass agile Projekte erfolgreich sein können. Im Rahmen von EAGLE wurden dazu verschiedene KPIs zusammengestellt und als „Agile Fitness Check“ zusammengefasst.
1. Die Methode
Agilität gibt zwar weniger Regeln und genormte Prozesse vor als das klassische Vorgehen, aber gerade deshalb ist es wichtig, die vorhandenen Regeln einzuhalten. Dies gilt besonders für das Einhalten der in Scrum vorgeschriebenen Events: der Dailies, Sprint Reviews, Retrospectives und Sprint Plannings. Jedes dieser Events hat seine spezifische Bedeutung für den Erfolg im agilen Vorgehen. Alle gemeinsam bieten die Möglichkeit zur Kommunikation mit jeweils unterschiedlichem Fokus. In ihrer Summe sind sie ein unverzichtbarer Bestandteil des agilen Vorgehens.
2. Ziele
Die Frage „Was soll mit diesem Projekt in einem Jahr, unabhängig von vielleicht geplanten Release-Zyklen, erreicht werden?“ sollte sich jedes Projekt bereits zu Anfang stellen und sie kontinuierlich überprüfen. Und an dieser Produkt- (oder Projekt-)Vision muss jedes einzelne Sprintziel gemessen werden. Ist die Vorgehensweise geeignet, diese Ziele – diese Vision – zu erreichen? Erfüllt die Priorisierung im Backlog ihre Aufgabe, dass das Projekt von Sprint zu Sprint diesen Zielen näher kommt?
3. Ergebnisse liefern
Nach spätestens drei Sprints sollte ein theoretisch auslieferbares Inkrement vorliegen. Doch in manchen Fällen sind die User Stories nicht so geschnitten und priorisiert, dass das möglich ist.
4. Qualität
Agiles Vorgehen setzt, was die Qualitätssicherung der entstehenden Inkremente angeht, auf die Eigenverantwortung des Entwicklungsteams. Anders als im klassischen Vorgehen wird nicht zuerst das gesamte Produkt fertig entwickelt und dann vollständig gegen die Akzeptanzkriterien getestet, sondern innerhalb jedes Sprints. Folgende Fragen müssen beantwortet werden: Gibt es ein belastbares und dokumentiertes Vorgehen bei Tests? Werden automatisierte Tests eingesetzt? Ist eine möglichst hohe Testabdeckung gewährleistet? Sind Tests ein fester Bestandteil in der Umsetzung jeder User Story? Entstehen technische Schulden, weil Fehler nicht direkt im Sprint behoben wurden?
5. Transparenz
Der Erfolg eines agilen Projekts hängt davon ab, dass immer Transparenz in der Kommunikation mit allen Beteiligten herrscht. Nur durch den Verzicht auf umfangreiches Controlling und Reporting wird sichergestellt, dass alle vom Gleichen reden und alle informiert sind. Das Thema muss immer wieder in der Retrospektive vom Team überprüft werden.
6. Hinterfragen
Jeder Sprint enthält ein Erfolgscontrolling. Agiles Vorgehen baut auf der Annahme des frühen und häufigen Scheiterns auf. Das heißt, der Projektfortschritt wird nicht sporadisch gemessen und mit einem abstrakten Endziel des Projektes verglichen, sondern von Sprint zu Sprint gemessen, beobachtet und optimiert. Dies ist einer der wichtigsten Unterschiede zum klassischen Vorgehen. Von Sprint zu Sprint bieten sich häufigere, frühzeitigere und immer wiederkehrende Gelegenheiten zum Messen und Optimieren der eigenen Vorgehensweise.
7. Risiken minimieren
Agile Projekte bieten Methoden zur Risikominimierung. Eine Methode ist die Priorisierung des Backlogs, um sicherzustellen, dass zuerst die Teile des Entwicklungsumfangs erstellt werden, die für den Kunden den höchsten Wert haben. Das Backlog muss klar und für alle verständlich priorisiert werden. Auch eine ständige Fortschrittskontrolle ist wichtig, die durch die (zum Beispiel in Form von Burn-down-Charts) gemessene Bereitstellung von Funktionalität (zum Beispiel User Stories) und die gemessene Performance des Entwicklungsteams (Velocity) erreicht wird. Burn- down und Velocity ermöglichen eine immer genauer werdende Vorhersage über die Fertigstellung eines geplanten Umfangs im Projektverlauf.
Sind das denn KPIs?
KPIs sollten messbare Erfolgsindikatoren sein. Doch der oben erwähnte „agile Fitnesscheck“ des EAGLE-Projekts besteht aus Fragen, die sich ein agil vorgehendes Projekt stellen sollte. Ist das also falsch? Nein, denn das Ziel aller KPIs ist die kontinuierliche Überprüfung, ob ein Vorhaben noch auf dem richtigen Weg zu seinen und den Unternehmenszielen ist. Wo quantitative Messung möglich und sinnvoll ist, sollte sie auch in agilen Projekten vorgenommen werden. Aber im agilen Projektmanagement steht zusätzlich das kontinuierliche Verbessern der eigenen Vorgehensweise (Kaizen) im Fokus. Und das geht durch Beobachten, Analysieren, Diskutieren und Verbessern – und zwar häufig und schnell.
Rahmenbedingungen zur Führung von potenziell erfolgreichen agilen Vorgehen
Die Erfahrungen aus dem Projekt EAGLE haben gezeigt, dass eine von oben legitimierte und von einem Expertenteam begleitete Einführung agiler Methoden besser funktioniert als einzelne „Leuchtturmprojekte“, die auf sich allein gestellt Agilität ausprobieren. Ebenso wichtig ist eine transparente Kommunikation zwischen den agilen Projekten und das Erfassen und Formulieren von „Lessons Learned“. Daraus können neue Projekte, die mit der agilen Methode starten möchten, wichtige Praxiserfahrungen ziehen. Das kann durch ein begleitendes Projekt wie bei EAGLE geschehen oder auch durch Communities of Practice, die einen projektübergreifenden Austausch bieten.
Fazit
Zurück zu den Kernfragen aus der Einleitung. Ja, es gibt deutliche Anzeichen, wann agile Projekte Probleme mit ihrer Vorgehensweise bekommen können. Zwar lassen sich diese Anzeichen nicht unbedingt quantifizieren, aber sie sind am Vorgehen selbst häufig deutlich zu erkennen. So gesehen sind KPIs wie oben aufgeführt in agilen Projekten sehr sinnvoll. Die eigene „agile Fitness“ muss mit jedem Sprint neu hinterfragt und optimiert werden. So kann sichergestellt werden, dass Agilität im Projekt gelingt.
Quellenangaben:
1 https://www.agil-werden.de/versionone-umfrage-1 https://www.agil-werden.de/versionone-umfrage-9-gruende-fuer-das-scheitern-agiler-projekte/
2 https://explore.versionone.com/state-of-agile/versionone-12th-annual-state-of-agile-report
