Der Kunde weiß aus seiner Erfahrung, wie unwahrscheinlich es ist, dass das Team ein System liefert, das den Kundenwünschen entspricht. Das Team hat wiederum die Erfahrung gemacht, dass der Kunde nicht weiß, was er will, und in dem Moment, in dem das Team glaubt, die Kundenwünsche zu kennen, seine Meinung erneut ändert.[…]
– Ken Schwaber: Agiles Projektmanagement mit Scrum. Washington 2007, S. 56 –
Mit meinem ersten Beitrag zum agilen Projektmanagement bin ich mittendrin eingestiegen, ohne jedoch den ersten Schritt anzugeben: Aber am Anfang eines Projektes steht immer die Kundenanforderung. Das obere Zitat von Ken Schwaber, der mit Jeff Sutherland zusammen Scrum entwickelte, trifft oft die Problematik der Anfangssituation.
Aber wie kommt es dazu?
In den meisten Softwarefirmen wird das Wasserfall-Modell oder das V-Modell eingesetzt. Sie beschreiben einen Fluss von mehreren Punkten. Meistens Analyse- und Definition, Entwurf, Implementierung und Test. Nach jedem Punkt wird den Stakeholdern, also allen am Projekt Interessierten,die Ergebnisse präsentiert und überprüft, ob sich das Projekt in die richtige Richtung bewegt. Je tiefer im Projekt oder „Wasserfall“, desto schwerer oder kostenintensiver ist es, frühere unbeachtete Fehler zu korrigieren. Die Vorstellung, man fällt wirklich einen Wasserfall herunter zeigt deutlich: Es ist unmöglich wieder hoch zu schwimmen. Es sei denn, man bestelle einen Kran, der einen wieder hochzieht. Somit ist auch der Kunde daran interessiert, spät entdeckte Fehler oder Fehlinterpretationen zu ignorieren, damit seine Projektkosten nicht explodieren. Das Ergebnis ist ein Produkt, welches nur zum Teil oder im schlimmsten Fall gar nicht den Kundenanforderungen entspricht. Die Bezeichnung Wasserfall Modell passt somit wie die Faust aufs Auge. Viele Projekte ertrinken unterwegs.
Aber was macht Agiles Projektmanagement besser und wo liegen seine Vorteile? Es beruft sich auf kurze Iterationen und Inspektionszyklen. Am Anfang steht bei Scrum eine Kundenvision. Sie enthält den erwarteten ROI, die Releases und Meilensteine. Daraus entwickelt der Kunde zusammen mit dem Product Owner den sogenannten Product Backlog mit allen sich abzeichnenden Anforderungen. Das Team wählt nun aus diesem Product Backlog in dem sogenannten Sprint Planning Meeting Funktionen aus, welche sie innerhalb des nächsten Sprints (30 Tage) zu einem demonstrierbaren Prototyp entwickeln können. Mit diesem Sprint Backlog fängt das Team an zu entwickeln und überprüft alle 24 Stunden im Daily Scrum den Fortschritt. Am Ende jedes Sprints können der Product Owner und die Stakeholder das Projekt im Sprint Review Meeting anpassen.
Der Unterschied ist enorm. Dadurch, dass der Kunde alle 30 Tage Funktionen sieht, kann er Wünsche und Korrekturen kostengünstig äußern und umsetzten. Er sieht, was möglich ist und bekommt genau das, was er wünscht. Durch diese persönliche Einbindung des Kunden wird das Projekt qualitativ hochwertiger und der Softwareentwicklungsprozess schneller. Die Kundenvision, welche am Anfang stand, kann der Kunde durch Sehen des Machbaren immer neu ausrichten und diese folglich von Sprint zu Sprint immer realer erscheinen lassen.
Durch diese einfachen Methoden der kurzen Iteration kann man dem Fluch der Lasten- und Pflichtenhefte entkommen und den Kunden und das Entwicklungsteam wieder näher zusammenbringen.
Das Problempotenzial wird drastisch verringert und beide Seiten können Missverständnisse schneller korrigieren. Dadurch sind alle Beteiligten positiver gestimmt und bekommen ein zufriedenstellendes Ergebnis.
No responses yet