Traditionelle vs. agile Projektmanagement: Wichtige Unterschiede & das Eisen-Dreieck erklärt

Unabhängig davon, ob Sie ein Scrum Master, Projektmanager, Product Owner, Teammitglied oder einfach jemand, der versucht, die Frage zu beantworten: „Wie führt man ein Agil ScrumProjekt in der realen Welt?“ – Dieser Artikel wird Ihnen definitiv die Antworten liefern, die Sie brauchen.

Traditionelles Projektmanagement

Der traditionelle Ansatz des Projektmanagements (Waterfall) ist linear, bei dem alle Phasen des Prozesses nacheinander ablaufen. Dieser Ansatz beruht auf vorhersehbaren Werkzeugen und vorhersehbaren Erfahrungen. Jedes Projekt folgt demselben Lebenszyklus, einschließlich der Phasen Machbarkeit, Planung, Design, Erstellung, Test, Produktion und Support, wie in der Abbildung unten dargestellt.

Waterfall vs Agile Software Development

Waterfall vs. agile Softwareentwicklung

Das gesamte Projekt wird vorab geplant, ohne dass Änderungen in den Anforderungen möglich sind – wie beim Waterfall, PMBOK von PMI und PRINCE2 sind diese Ansätze streng und hochgradig kontrolliert. Sie definieren klar abgegrenzte Phasen vom Anfang bis zum Ende und gehen davon aus, dass Sie bereits alle benötigten Anforderungen und Informationen besitzen.

Dieser Ansatz geht davon aus, dass Zeit und Kosten variabel sind, während die Anforderungen festgelegt sind – weshalb traditionelles Projektmanagement oft mit Budget- und Zeitplanproblemen kämpft.

Agiles Projektmanagement

Während traditionelle Systeme stark auf vorherige Planung setzen, sind Faktoren wie Kosten, Umfang und Zeit entscheidend. Agile hingegen legt Wert auf Teamarbeit, Kundenkollaboration und Flexibilität.

Agile lehnt traditionelles Projektmanagement als langweilig, einschränkend und ungeeignet für die schnelle moderne Welt ab. Agiles Projektmanagement ist iterativ und zielt darauf ab, kontinuierlich Benutzerfeedback und fortlaufende Releases mit jeder Entwicklungsiteration zu integrieren, wie oben gezeigt. Jede Aufgabenausgabe ist ein Produkt, das Sie an die Stakeholder verkaufen. Teams und Arbeitsabläufe sind darauf ausgerichtet, etwas direkt Nutzbares für den Kunden zu schaffen.

Traditionell oder agil – Wie wählt man aus?

Laut dem CHAOS-Report 2011 des Standish Group sind agile Projekte dreimal erfolgreicher als Waterfall-Projekte. Das folgende Diagramm zeigt die spezifischen Ergebnisse aus Studien, die zwischen 2002 und 2012 durchgeführt wurden:

Success Rate of Waterfall vs Agile Projects

Erfolgsrate von Waterfall- gegenüber agilen Projekten

Unterschiede zwischen traditionellem und agilem Projektmanagement

Die folgende Tabelle fasst viele wesentliche Unterschiede zwischen Scrum und traditionellen Projektmanagementmodellen zusammen.

Kategorie Traditionell Agil
Entwicklungsmodell Sequentiell (Waterfall) Iterativ
Fokus Prozess Menschen
Management-Stil Kontrolle Facilitierung
Kundenbeteiligung Beschränkt auf die Phasen der Anforderungserhebung und Lieferung Kontinuierliche und vor Ort stattfindende Beteiligung
Entwickler-Arbeitsstil Arbeitet individuell innerhalb des Teams Kooperativer oder Pair-Programming
Technologie Beliebig Hauptsächlich objektorientiert
Produktfunktionen Alle Funktionen enthalten Zunächst die wichtigsten Funktionen
Testen Am Ende des Entwicklungszyklus Iterativ und/oder testgetrieben
Dokumentation Umfangreich Nur wenn erforderlich

Kosten der Änderung

Traditionell werden Änderungen an Softwareprojekten vermieden, da die Kosten erheblich später im Projekt ansteigen. Agile Softwareentwicklung erkennt, dass Änderungen unvermeidbar sind und dass eine intensive Planung zu Beginn unrealistisch ist. Dies wird deutlich in einem der vier Werte des Agile Manifestos ausgedrückt:

„Reagieren auf sich ändernde Anforderungen statt folgen eines festen Plans.“

Agile stellt diese Vorstellung in Frage und argumentiert, dass die Kosten der Änderung relativ flach sein können, wie in der folgenden Abbildung gezeigt:

Cost of Change in Traditional vs Agile

Kosten der Änderung bei traditionellen versus agilen Ansätzen

Agil versus traditionell im Eisen-Dreieck der Projektmanagement

Der Erfolg im Projektmanagement wurde traditionell mit der Fähigkeit zur Bewältigung von Einschränkungen in Umfang, Zeit, Kosten und Qualität verbunden, wie in der folgenden Abbildung gezeigt. Dies ist ein beliebter Metapher, die suggeriert, dass Projektmanager diese Einschränkungen angemessen ausbalancieren sollen.

Iron Triangle in Agile vs Traditional Project Management

Eisen-Dreieck im agilen versus traditionellen Projektmanagement

Was ist das Problem mit dem traditionellen Eisen-Dreieck?

Zum Beispiel kann ein Projekt schneller abgeschlossen werden, indem das Budget erhöht oder der Umfang verkleinert wird. Ähnlich verhält es sich bei der Erweiterung des Umfangs, die in der Regel eine entsprechende Erhöhung von Budget und Zeitplan erfordert. Die Reduzierung des Budgets ohne Anpassung von Zeitplan oder Umfang führt zu einer Verschlechterung der Qualität. In der Praxis sind jedoch Austauschbeziehungen zwischen den Einschränkungen nicht immer möglich. Zum Beispiel kann die Investition zusätzlicher Mittel (und Personal) in ein Projekt mit ausreichenden Ressourcen die Fortschritte tatsächlich verlangsamen. Außerdem ist es in schlecht funktionierenden Projekten oft unmöglich, Budget, Zeitplan oder Umfang zu verbessern, ohne die Qualität negativ zu beeinflussen.

Daher ist das traditionelle Eisen-Dreieck eindeutig unzureichend als Modell für Projekt-Erfolg, da es entscheidende Erfolgsdimensionen außer Acht lässt, darunter den Einfluss der Stakeholder, das Lernen und die Benutzerzufriedenheit.

Agiles Eisen-Dreieck – Ein Paradigmenwechsel

Bei der traditionellen Herangehensweise sieht das Dreieck gewöhnlich aus wie das linke unten abgebildete. Wie Sie sehen können, haben die Produktanforderungen einen festen Umfang. Um sicherzustellen, dass das Produkt alle erforderlichen Funktionen liefert, benötigen wir Flexibilität in unseren Ressourcen (und Budget) sowie im Zeitplan (Frist). Wenn wir unbedingt sicherstellen müssen, dass das Produkt die vollständige Liste der im ursprünglichen Anforderungsdokument beschriebenen Funktionen enthält, könnten wir den Veröffentlichungszeitpunkt um mehrere Monate oder länger verschieben müssen.

Im agilen Sinne gibt es einen festen Zeitplan (in Scrum wird dies erreicht durchzeitlich begrenzte Sprintsund feste Ressourcen). Daher muss der Umfang reduziert werden, wenn die Dinge nicht wie geplant verlaufen. Doch im agilen Ansatz stellen wir sicher, dass wir selbst dann die wichtigsten Elemente aus demProdukt-Backlogliefern, um den durch das Projekt erzeugten Wert zu maximieren.

Iron Triangle in Agile Context

Eisen-Dreieck im agilen Kontext

 

Kommentar hinterlassen