Welchen konkreten Nutzen liefern agile Ansätze?
Ein Erfahrungsbericht aus einem Projekt

Agilität ist ein Mittel zum Zweck und muss sich am Erfolg messen lassen. Sind agile Ansätze in der Praxis  wirklich besser als klassische Projektmanagement Methoden?

Die Einführung von agilen Methoden in einem Unternehmen ist ein aufwendiger Change Prozess; neben neuen agilen 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 diese Frage anhand meiner persönlichen Erfahrungen in einem Projekt beantworten, in dem ich als Scrum Master für 4 Team tätig war.

Hintergrund

Bei dem beschriebenen Projekt handelt es sich um ein mehrjähriges internationales SAP Einführungsprojekt im Bereich Supply Chain Management. Auf fachliche Projektdetails verzichte ich hier bewusst um den Rahmen nicht zu sprengen. Dieses Projekt ist auf den ersten Blick kein typischer Kandidat für einen agilen Ansatz. Im SAP Umfeld wurde lange Jahre mit Wasserfallprozessen und funktionaler Trennung gearbeitet hat. Eine interessante Frage ist, ob auch in diesem Kontext Vorteile durch agile Methoden erzielt werden kann.
Ich bin  PMP zertifizierter Projektmanager und habe früher mit klassischen Projektansätzen gearbeitet, insofern kann ich  beide Methoden auch auf Basis eigener Erfahrungen vergleichen. Im folgenden ein Überblick über einige 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ührte es dazu, dass auch Stakeholder, die nicht  direkt in das Projekt involviert waren, ein gutes Verständnis der neuen  Funktionialität entwickelten. Zum anderen liefert es einen realistischen und belastbaren Einblick in den Stand der Umsetzung und somit einen zuverlässigen Nachweis, dass das Projekt Fortschritt gemacht hat. Und eben 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 die 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 und Integrationsschwierigkeiten 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 kann man diesen Vorteil nicht unbedingt der agilen Methodik zuschreiben. 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 Projektteam und den internen Stakeholdern 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 werden und viel Abstimmungsaufwand für permananente 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 werde.
• 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 agilen Methoden 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 überwogen den Aufwand in diesem Fall deutlich und die Einführung von agilen Arbeitsweisen war eine richtige und zukunftsweisende Entscheidung, die auch nach diesem Projekt noch Früchte trägt.

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