Wer heute Projekte anhand eines  „klassischen“ Projektplans steuert, wird belächelt. Denn im 21. Jahrhundert ist Projektmanagement agil in Sprints. Vielfach wird Agilität schon im negativen Sinne als Hype bezeichnet.

 

Vielleicht liegt der Fehler bereits in der Frage? Agil und Wasserfall müssen sich gar nicht gegenseitig ausschließen oder ersetzen.

 

Agil ohne Projektplan vs. Wasserfall ohne Agilität?

 

Weder Agil noch Wasserfall erscheinen als in sich geschlossene, absolut definierte Projektmanagement-Methoden. Ein klassisch geplantes und gesteuertes Projekt benötigt und realisiert meiner Erfahrung nach Flexibilität, Iterationen, Änderungen und Anpassungen. Die Projektmanagement-Prozesse, die Unternehmen spezifisch für ihre Projekte und Entwicklungen definieren, ließen und lassen Raum für Flexibilität und häufig auch Agilität.

 

Agile Projekte erfordern ebenso ein bestimmtes Maß an Planung. Auch Agilität bedeutet nicht, endlos flexibel zu sein. Ein Wasserfall-Projekt wird häufig mit einem fixen Plan gleichgesetzt, der sklavisch befolgt wird. Das agile Projektteam erstellt im Gegensatz dazu nur einen groben Plan, der nach und nach detailliert wird, in Abhängigkeit vom Projektfortschritt. Projektmanagern, die Wasserfall-Methoden verwenden, ist diese Vorgehensweise nicht vollständig unbekannt.

 

Das Management eines Projektes ergibt sich nicht aus dogmatischen Vorstellungen, sondern aus dessen spezifischen Anforderungen. Welcher Ansatz oder welches Produkt in einem bestimmten Moment geeignet ist, ist relativ. Bin ich in der Frankfurter Innenstadt unterwegs, beneide ich den Smart-Fahrer, der ruckzuck einen Parkplatz findet; auf einer langen Autobahnreise weniger.

 

Sicherheit und Unsicherheit

 

Für Entwicklungsprojekte, die einer hohen Unsicherheit unterliegen, ist ein Wasserfall-Ansatz im Projektmanagement einem agilen Ansatz vermutlich in den meisten Fällen unterlegen. Die Entwicklung brandneuer Produkte oder Forschungsprojekte mit einer potentiell hohen Zahl an Überraschungen werfen Projektpläne zu häufig über den Haufen. Ein zu rigides, planorientiertes Projektmanagement führt potentiell zu Verzögerungen und erstickt die Kreativität.

 

Bei einem hohen Grad an Sicherheit, was wann und wie zu bearbeiten ist, bleibt ein klassischer, umfassender und detaillierter Projektplan empfehlenswert. In vielen Fällen mag er sogar zwingend sein. Gerade Bauprojekte erfordern ein hohes Maß an Abstimmung zwischen einzelnen Gewerken. Kein Bauingenieur wird den ersten Teil eines Wolkenkratzers bauen und anschließend darüber nachdenken, wie er oder sie den Rest des Gebäudes angeht. Auch muss das ganze Gebäude am Ende des Projektes garantiert komplett fertig sein. Auf einzelne Funktionen kann selten verzichtet werden. Sub- und Fachunternehmer stehen selten agil auf Abruf bereit, um einen Estrich bei Bedarf zu gießen. Auch wenn Bauprojekte vielen Unsicherheiten im Bezug auf Wetterbedingungen und Verzögerungen unterliegen, werden sie in der Regel anhand verbindlicher Projektpläne und Verträge gesteuert.

 

Ratenweise Lieferung von Produkten und Funktionen

 

Die Softwareentwicklung dagegen unterliegt anderen Gesetzmäßigkeiten als der Bau eines Hauses. Agile Projektmanagement-Methoden wie Scrum zielen darauf ab, Funktionen einer Software schnell und funktionsfähig zu liefern, unabhängig von der Fertigstellung des gesamten Softwarepaketes. Kurze Entwicklungs- und gleichzeitige Testzyklen sorgen für unmittelbares Feedback im Rahmen einer engen Zusammenarbeit zwischen Entwickler und Kunden. Sowohl Entwickler als auch Nutzer profitieren von diesem Ansatz.

 

Bei einer Software ist die ratenweise Lieferung von Funktionen machbar und wünschenswert. Nicht alle Projekte sind Projekte zur Entwicklung von Software. Aus meiner Sicht wird dieser Aspekt in der Diskussion agil vs. Wasserfall häufig vernachlässigt. Bei mechanischen oder elektrotechnischen Antrieben, dem Aufbau einer Produktionsanlage – oder dem Bau eines Gebäudes oder Staudamms – ist eine ratenweise Lieferung oder kontinuierliche Verbesserung potentiell ungünstig.

 

Die agilen Werte

 

Für jeden Projektleiter lohnt der Blick auf die vier Kernwerte agilen Projektmanagements. Im agilen Manifesto für die Softwareentwicklung betonen die Unterzeichner, dass sie die Werte auf der linken Seite als wichtiger erachten. Dennoch blieben die Werte auf der rechten Seite für sie wichtig, nicht unwichtig.

 

Individuen und Interaktionen mehr als Prozesse und Werkzeuge.

Funktionierende Software mehr als umfassende Dokumentation.

Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung.

Reagieren auf Veränderung mehr als das Befolgen eines Plans.

 

Quelle: http://agilemanifesto.org/iso/de/manifesto.html

 

Das bedeutet, dass auch agiles Projektmanagement Prozesse und Werkzeuge, Dokumentationen, Verträge und Pläne erfordert. Der Fokus liegt jedoch klar auf den Menschen im Projekt, deren Interaktion sowie Schnelligkeit und kontinuierliche Anpassung.

 

Agile und Wasserfall-Ansätze im Projektmanagement sind nicht absolut definiert. Nicht alle Projekte sind Software-Entwicklungsprojekte. Nicht alle Ergebnisse eines Projektes lassen sich in Raten oder Funktionen liefern. Wasserfall-Projekte profitieren auf der einen Seite von mehr Agilität. Auf der anderen Seite erlangt ein agiles Projekt unter den richtigen Bedingungen Vorteile durch die Nutzung etablierter Prozesse und Methoden des klassischen Projektmanagements. Weniger „0 oder 1“, sondern eine stärkere, fallweise Kombination und projektspezifische Vorgehensweise erscheint mir sinnvoll. Am Ende profitieren alle Projekte davon, die Werte des agilen Manifestos zur Verbesserung der Zusammenarbeit, Kommunikation, Flexbilität und Innovationskraft zu berücksichtigen.

 

Ich freue mich auf Kommentare und Anregungen! 

 

(Bildnachweis: