Ralf Gruber - systemisch agil
 

Praxisbericht aus einem agilen Software Projekt

Sind agile Projekte in der Praxis wirklich schneller, günstiger und effizienter? Eine persönliche Retrospektive eines agilen Projektes

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 diese 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 auf Basis von eigenen Erfahrungen vergleichen.

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.

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ü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 agile 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 noch lange nicht voll ausgeschöpft ist.