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 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:

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:

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.

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.

Eisen-Dreieck im agilen Kontext