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 Teams tätig war.
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.
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.
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.
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.
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.
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 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.