agil: systemisch & werteorientiert.

agile Projekte

Sind agile Projekte schneller, günstiger und effizienter?
Eine persönliche Retrospektive aus einem Projekt

Die Einführung von agilen Methoden in einem Unternehmen ist ein aufwendiger Change Prozess; neben neuen Prozessen wie daily stand-ups, inkrementeller Entwicklung, etc ändert sich die Arbeitsweise der Teams hin zu mehr Selbstorganisation und Eigenverantwortung. Ein nicht unerheblicher Veränderungaufwand. Die naheliegende Frage, die sich stellt ist daher: „Lohnt sich dieser Aufwand?“

Ich möchte die Frage anhand meiner persönlichen Erfahrungen in einem Projekt beantworten, in dem ich als Scrum Master für 4 Team tätig war. Es geht mir dabei nicht um einen allgemeinen Überblick über die Vorteile von agilen Ansätzen (dazu gibt es genug gute Literatur) sondern um meine konkreten Erfahrung in einem realen Projekt. Ich bin  PMP zertifizierter Projektmanager und habe früher mit klassischen Projektansätzen gearbeitet, insofern kann ich auch beide Methoden aus eigenen Erfahrung vergleichen.

Bei dem beschriebenen Projekt handelt es sich um ein mehrjähriges internationales SAP Projekt. Auf Projektdetails verzichte ich hier bewusst um den Rahmen nicht zu sprengen.

Im folgenden meine Einschätzung einiger wesentlicher Veränderungen und Verbesserungen, die sich durch die Einführung von agilen Methoden ergaben.

 

Frühe Sichtbarkeit von Ergebnissen

Nach Ablauf einer Iteration wurden Erweiterungen und neue Funktionalitäten von Geschäftsprozessen (Customisation, Enhancements) in einem end-to-end Prozess getestet und den Projektsponsoren und projektexternen Stakeholdern demonstriert.
Dies hat sich als sehr wertvoll erwiesen. Zum einen führt es dazu, dass auch Stakeholder, die nicht direkt in das Projekt involviert waren ein gutes Verständnis der neuen Funktionialität entwickelt haben  Zum anderen liefert es einen zuverlässigen Nachweis, dass das Projekt Fortschritt gemacht hat. Und zwar nicht nur auf dem Papier oder in Form einer abstrakten Metrik, sondern in Form von funktionierender Software. Dies erhöhte das Vertrauen der externen Stakeholder in das Projekt und in die agile Methodik deutlich.

 

Risikominimierung

In traditionellen Projekten werden Risiken zum Teil erst sehr spät im Projektverlauf angegangen; dazu zählt zum Beispiel Performance oder Integration mit anderen Systemen. In diesem Projekt hatten wir sehr früh lauffähige Software, die grundlegende Kerngeschäftsprozesse abdeckte. Diese beinhaltet zwar nicht den vollen Funktionsumfang, war aber ausreichend um bereits in einem sehr frühen Stadium Performanceengpässe anzugehen oder Integrationsthemen zu identifizieren. Dadurch konnten diese Risiken frühzeitig adressiert und gelöst werden.

 

Frühe Verfügbarkeit der Software beim Kunden

Die SAP Software löst ein altes System ab. Dies machte es schwierig, mit einem reduzierten Funktionsumfang zu launchen, da die Kunden berechtigerweise einen bestimmten Funktionsumfang erwarten. Der launch wurde auf drei Releases aufgeteilt; ein Vorgehen, das auch bei Wasserfallprojekten als phased approach nicht unüblich ist . Insofern haben sich hier durch agile keine weiteren Vorteile ergeben. Dennoch führte die Aufteilung auf drei Releases zu einer Entzerrung der Launches und einer früheren Verfügbarkeit von Teilfunktionalitäten.

 

Frühe Verfügbarkeit der Software für interne Business Analysten

In Wasserfallprojekten wird viel Zeit mit der Beschreibung von zukünftigen Prozessen verwendet. Ein Problem dabei: Die Businesskunden kennen oft ihr altes System und ihre alten Prozesse und neigen dazu, das neue System ähnlich zu spezifizieren wie das bekannte alte. Insbesondere bei SAP Projekten, die bestrebt sind, nahe am SAP Standard zu bleiben, entsteht so oft unnötiger und teuerer Anpassungsbedarf
Welchen Unterschied macht Agilität hier? In diesem Projekt wurden zuerst die SAP Standardprozesse aufgesetzt und dem Team die Möglichkeit gegeben, die neuen SAP Standardprozesse und Customization Möglichkeiten kennenzulernen. Erst basierend auf dieser Erfahrungen wurden notwendige Erweiterungen und Veränderungen der SAP Standardsoftware spezifiziert und entwickelt. Dies trug dazu bei, die Anzahl der SAP Anpassungen signifikant zu verringern.

 

Projektplanung und Statusverfolgung

In Wasserfallprojekten wurden typischerweise große Projektpläne entwickelt, die oft unübersichtlich wurden und viel Abstimmungszeit für Aktualisierung benötigten. In diesem Projekt wurde Rally als tool eingesetzt um Arbeitsaufgaben zu beschreiben und zu planen sowie deren Status zu tracken. Dies hatte erhebliche Vorteile im Vergleich zu einem zentralen Projektplan

· Die Teammitglieder aktualisieren den Status selbst zeitnah, Es ist somit immer der aktueller Status für alle Teammitglieder verfügbar.

· Jedes Teammitglied hat einen aktuellen Überblick über seine Tasks und tasks von Kollegen in dieser Iteration.

· Mit Hilfe des tools können ohne Aufwand zu jeder Zeit wichtige Metriken wie velocity, release burndown chart, Auslastung des Teams, Zahl von offenen Defekten, etc. erstellt werden

· Das tool ermöglicht eine einfache Bearbeitung von Defekten. Können User Stories aufgrund eines Defektes nicht fertiggestellt werden, kann im selben tool ein Defekt geöffnet werden und einem anderen Teammitglied zugewiesen werden. Dies ermöglicht eine hohe Transparenz und schnelle Bearbeitung von Fehlern auch zwischen Teams

 

Fazit

Die Einführung von agile bringt viele fundamentale Änderungen sowohl im Prozessablauf als auch in der Unternehmenskultur mit sich. Diesem Aufwand stehen aber signifikante Vorteile gegenüber, die ich in diesem Beitrag kurz skizziert haben. Die Vorteile überwiegen den Aufwand aber bei weitem und die Einführung von agile war eine richtige und zukunftsweisende Entscheidung.

Auch die Teams entwickeln sich mit der Methodik weiter und ich bin überzeugt, dass das Potential von agilen Methoden noch lange nicht voll ausgeschöpft ist.