---

Das ganze Projekt planen, bevor Sie es verstehen? Das könnte Sie überraschen!

Ohne Scrum entwickelten und lieferten unsere Teams völlig falsche Hard- und Software, die Kundenanforderungen nicht erfüllte.

Dritte schrieben uns manchmal vor, wie wir Softwareprodukte und -dienste entwickeln sollten.

Capability Maturity Model (CMM), ISO 9001:2008 und weitere Ableitungen sollten helfen, die richtige Software richtig zu entwickeln.

Ihr Erfolg ist nicht Thema dieses Buchs. Es konzentriert sich auf Scrum und seine Vorteile statt auf Kritik an fast ausgestorbenen Verfahren.

Diese früheren Verbesserungsmodelle empfahlen allerdings ein schrittweises Vorgehen, das wir so nannten: Wasserfallmodell der Softwareentwicklung.

Jedes Projekt sollte mit der Anforderungsanalyse beginnen, um Kundenwünsche und -bedarf zu verstehen.

Danach entwarfen, implementierten, testeten (verifizierten) und warteten wir die Anforderungen in der Produktionsumgebung. So endete der Lebenszyklus.

Doch die Wirklichkeit sah anders aus!

Wasserfallmethode und Scrum im Vergleich

Phasen des klassischen Wasserfallmodells in der Softwareentwicklung

Unvorhergesehene Verzögerungen einer Phase beeinträchtigten zwangsläufig die folgenden Phasen.

Studien zufolge war die Wasserfallmethode bei über 80% der untersuchten gescheiterten Softwareprojekte ein wesentlicher Misserfolgsfaktor. Aber warum?

Links sehen Sie die streng aufeinanderfolgenden Phasen. Eine muss abgeschlossen sein, bevor die nächste beginnt. Zurückzugehen ist meist schmerzhaft, teuer, frustrierend und zeitaufwendig.

Der Zeitplan wird am Anfang festgelegt. Ein freigabefähiges Produkt entsteht erst am Ende. Eine verzögerte Phase verzögert alle anderen.

Projektmanager wollen deshalb alle Möglichkeiten vorwegnehmen und früh alle Anforderungen vollständig und detailliert definieren. Das ist jedoch schwierig; viele Anforderungen ändern sich im Verlauf oder sollten sich ändern.

In großen, komplexen Projekten ändern sich Studien zufolge etwa 60% der ursprünglichen Anforderungen. Andere werden umgesetzt, obwohl Kunden sie nicht brauchen. Zeit und Geld hätten besser höherwertige Funktionen ermöglicht.

Die Phasentrennung verlangt getrennte Schätzungen. Tatsächlich sind die Phasen jedoch meist verbunden und laufen parallel.

Niemand kann vernünftig annehmen, die Entwicklung sei vor Testbeginn fertig. Leider funktionierte Wasserfall genau so.

Für kleine, einfache Projekte kann Wasserfall geeignet sein. Bei größeren, komplexen Vorhaben ist er jedoch äußerst riskant, wenn nicht unsinnig. Er ist häufig teurer und immer weniger effizient als Scrum.

So war die Zeit vor Scrum. Software ohne fachkundige Anleitung zwischen Teams hin- und herzuschieben, machte unsere Arbeit bürokratisch, kompliziert und unproduktiv..

Nicht nur das Produkt litt: Auch Mitarbeitermoral und Verpflichtung zur gemeinsamen Mission wurden völlig gestört.