Die unterschätzte Schwäche des Wasserfallmodells: fehlendes Kundenfeedback
Was bringt ein sauber geplantes Softwareprojekt, wenn der Kunde erst bei der Abnahme erkennt, dass die Lösung am eigentlichen Bedarf vorbeigeht? Genau hier liegt eine der unterschätzten Schwächen des Wasserfallmodells: Feedback erreicht das Entwicklungsteam spät, wenn Architektur, Datenmodell und Prozesse bereits festgelegt sind.
Das Wasserfallmodell schafft klare Phasen, Verantwortlichkeiten und Dokumente. Diese Ordnung hilft bei stabilen Anforderungen. Bei komplexen Produkten mit unsicheren Annahmen wird sie jedoch zum Risiko, weil jede falsche Entscheidung lange unentdeckt bleibt und sich durch die folgenden Phasen fortpflanzt.
Wenn die Abnahme zum ersten echten Produkttest wird
Stell Dir ein internes Portal vor, dessen Anforderungen vollständig in einem Pflichtenheft stehen. Das Projektteam entwickelt Oberfläche, Rollenmodell und Schnittstellen nach dieser Grundlage. Die Fachabteilung sieht zwischendurch Statusberichte und Designentwürfe. Eine nutzbare Version bekommt sie erst zur Abnahme.
Dann zeigt sich: Die wichtigsten Abläufe passen zur Dokumentation, aber nicht zum Arbeitsalltag. Ein zentraler Prozess benötigt zusätzliche Freigabestufen. Die Daten werden anders gepflegt als angenommen. Eine Rolle, die im Konzept klar aussah, ist organisatorisch gar nicht besetzt.
Technisch lässt sich vieles reparieren. Organisatorisch und finanziell wird es unangenehm, weil die Änderung mehrere bereits abgeschlossene Entscheidungen berührt. Der erste echte Nutzerkontakt findet zu einem Zeitpunkt statt, an dem Feedback vor allem eines produziert: Änderungsanträge.
Wie funktioniert das Wasserfallmodell als lineares Vorgehensmodell?
Das Wasserfallmodell ist ein lineares Vorgehensmodell in der Softwareentwicklung, bei dem ein Projekt definierte Phasen nacheinander durchläuft. Typische Phasen sind Anforderungsanalyse, Entwurf, Implementierung, Test sowie Einführung und Wartung (wirtschaftslexikon.gabler.de).
Die Ergebnisse einer Phase dienen als Grundlage für die nächste. Anforderungen werden spezifiziert, daraus entsteht die Architektur, anschließend der Code und danach die Integration. Am Ende steht die Abnahme eines möglichst vollständigen Produkts. Rücksprünge sind in erweiterten Varianten vorgesehen, gehören aber nicht zum normalen Takt des klassischen Entwicklungsmodells.
Das Modell erzeugt dadurch eine klare Projektlogik:
- Anforderungen und Machbarkeit klären
- System und Architektur entwerfen
- Software implementieren
- Integration und Systemtest durchführen
- Lösung ausrollen und warten
Diese Struktur ist für Entscheider attraktiv. Sie erleichtert Verträge, Meilensteine und Budgetfreigaben. Sie beantwortet allerdings vor allem die Frage, wann welches Dokument vorliegt. Die Frage, ob die Lösung für ihre Nutzer funktioniert, bleibt lange offen.
Warum fehlt Kundenfeedback im Wasserfallmodell so lange?
Im klassischen Wasserfallmodell ist Kundenfeedback vor allem am Anfang und am Ende vorgesehen, weil die Phasen durch formale Übergaben voneinander getrennt sind. Während der Umsetzung wird der Kunde zum Abnehmer von Ergebnissen, während das Team an der Realisierung einer bereits festgelegten Lösung arbeitet.
Das Problem liegt weniger in fehlender Kommunikation als in der Form des Feedbacks. Ein Statusbericht zeigt Fortschritt. Ein Prototyp oder ein nutzbarer Teil der Software zeigt dagegen, ob eine Annahme trägt. Genau diese produktnahe Rückmeldung fehlt, wenn die erste vollständige Interaktion erst bei der Abnahme stattfindet.
Warum sind Anforderungsänderungen im Wasserfallmodell problematisch?
Anforderungsänderungen im Wasserfallmodell sind problematisch, weil eine Änderung auf bereits abgestimmte Entwürfe, Schnittstellen, Tests und Dokumente wirkt. Aus einer fachlichen Anpassung wird dadurch eine Kette technischer und organisatorischer Folgeentscheidungen.
Eine Änderung an einem Datenfeld kann etwa API-Verträge, Berechtigungen, Migrationen, Testfälle und Benutzerdokumentation betreffen. Je später sie auffällt, desto mehr bereits erledigte Arbeit muss geprüft oder überarbeitet werden. Das gilt besonders für Anforderungen, die früh als verbindliche Grundlage behandelt wurden.
Die typischen Nachteile des Wasserfallmodells entstehen deshalb aus einer Kombination von drei Faktoren:
- Anforderungen werden früh fixiert.
- Feedback aus der Nutzung kommt spät.
- Änderungen laufen über formale Change Requests und Impact-Analysen.
Warnsignal: Wenn Stakeholder im Projekt regelmäßig sagen, dass sie „erst bei der Abnahme richtig sehen können, was gebaut wurde“, ist das Feedbacksystem zu spät angesetzt. Noch deutlicher wird das Problem, wenn Änderungsanträge vor allem deshalb entstehen, weil niemand vorher mit einer nutzbaren Version arbeiten konnte.
Ein sauberer Änderungsprozess reduziert das Risiko. Er beseitigt die Ursache jedoch nicht. Jede formale Kontrolle hilft wenig, wenn die ursprüngliche Annahme nie praktisch geprüft wurde.
Individuelle Software, die zu Deinen Prozessen passt
Wir entwickeln maßgeschneiderte Lösungen iterativ und mit Dir im Loop, damit Änderungen kein Änderungsantrag-Marathon werden.
Welche Folgen hat späte Fehlererkennung für die Projektkosten?
Späte Fehlererkennung im Softwareprojekt erhöht den Aufwand, weil sich ein Fehler dann bereits in weitere Artefakte und Entscheidungen eingeschrieben hat. Die Kosten später Fehlerkorrektur bestehen aus Analyse, Anpassung, erneuten Tests, Abstimmung und verzögerter Lieferung.
Eine NASA-Untersuchung zu komplexen Hardware- und Softwaresystemen kam zu deutlich steigenden Korrekturkosten: Für einen Fehler in den Anforderungen setzte sie die Korrektur in der Anforderungsphase als eine Einheit an; in Design, Build, Integrationstest und Betrieb lagen die untersuchten Relationen deutlich höher und reichten im Betrieb bis über 1.500 Einheiten. Diese Werte gelten für Systeme wie Raumfahrzeuge und militärische Flugzeuge und taugen deshalb als Risikosignal, nicht als allgemeine Preisliste (ntrs.nasa.gov).
Die pauschale Aussage „später ist immer exponentiell teurer“ verdient trotzdem Skepsis. Eine Studie von Menzies, Nichols, Shull und Layman untersuchte 171 Softwareprojekte und fand keinen konsistenten, allgemein gültigen Nachweis dafür, dass spätere Fehlerkorrekturen immer deutlich mehr Aufwand verursachen (arxiv.org).
Die belastbare Schlussfolgerung lautet daher: Spätes Feedback erhöht das Projektrisiko, aber der konkrete Kosteneffekt hängt vom System, dem Prozess und der Art des Fehlers ab. Bei eng gekoppelten Architekturen, sicherheitskritischen Funktionen und vielen Abhängigkeiten steigt der Schaden einer späten Änderung besonders stark.
Wann ist ein sequentielles Vorgehensmodell sinnvoll?
Ein sequentielles Vorgehensmodell ist sinnvoll, wenn Anforderungen stabil, Schnittstellen bekannt und Änderungen streng begrenzt sind. Das gilt für klar definierte technische Lösungen, wiederholbare Abläufe und Projekte, bei denen Nachweisführung und formale Freigaben einen hohen Stellenwert haben.
In regulierten Branchen braucht Software eine nachvollziehbare Entwicklung mit dokumentierten Entscheidungen, Tests und Freigaben. Sie schreiben jedoch nicht automatisch vor, dass Nutzerfeedback erst am Projektende stattfinden darf.
Unsere Empfehlung lautet deshalb: Nutze sequenzielle Planung dort, wo sie Risiken beherrscht. Ergänze sie um Prototypen, frühe Reviews, technische Spikes und klar definierte Entscheidungspunkte. Regulierte Softwareentwicklung darf iterativ organisiert sein, solange Anforderungen, Tests, Freigaben und Nachweise kontrolliert bleiben.
Vom Wasserfallmodell raten wir ab, wenn mindestens eines dieser Merkmale zutrifft: Nutzerbedürfnisse sind unklar, Geschäftsprozesse befinden sich im Wandel, technische Risiken sind noch offen oder der Erfolg hängt von Bedienbarkeit und Akzeptanz ab. In diesen Fällen ist ein dicker Plan vor dem ersten Lernschritt vor allem eines: ein sehr ordentlich formatiertes Risiko.
Welche agilen Alternativen passen zu sich ändernden Anforderungen?
Agile Methoden passen zu sich ändernden Anforderungen, weil sie Feedback und Anpassung in den Entwicklungsrhythmus einbauen. Scrum eignet sich für komplexe Produktentwicklung mit priorisierten Anforderungen und regelmäßigen nutzbaren Inkrementen; Kanban eignet sich für kontinuierlichen Arbeitsfluss, wechselnde Prioritäten und begrenzte laufende Arbeit.
Scrum organisiert Arbeit in Sprints und sieht mit Sprint Reviews einen festen Moment vor, in dem das Ergebnis inspiziert und die weitere Arbeit angepasst wird. Der Scrum Guide beschreibt Scrum als Framework für adaptive Lösungen bei komplexen Problemen (scrumguides.org). Das funktioniert nur, wenn Product Owner, Fachseite und Entwicklung tatsächlich Entscheidungen treffen können. Ein Product Owner ohne Entscheidungsspielraum ist ein Kalendertermin mit Titel.
Kanban visualisiert den Workflow, steuert laufende Arbeit und verbessert den Fluss kontinuierlich. Der aktuelle Kanban Guide von Mai 2025 nennt das Definieren und Visualisieren des Workflows, das aktive Managen von Arbeitselementen und die Verbesserung des Workflows als Kernpraktiken (kanbanguides.org).
Die Wahl sollte zur Unsicherheit passen:
- Scrum: Wenn ein Produkt schrittweise entwickelt und regelmäßig bewertet werden soll.
- Kanban: Wenn Aufgaben laufend eintreffen und Prioritäten flexibel wechseln.
- Hybrider Ansatz: Wenn Planung, Dokumentation und Freigaben feststehen, die Umsetzung aber iterativ erfolgen soll.
Agil bedeutet dabei nicht, Anforderungen beliebig zu ändern. Gute Teams machen Annahmen sichtbar, liefern prüfbare Ergebnisse und entscheiden bewusst, welche Änderung welchen Wert bringt. Genau dadurch wird Kundenfeedback vom späten Korrektiv zum frühen Steuerungsinstrument.
Das Wasserfallmodell ist ein lineares Vorgehensmodell in der Softwareentwicklung. Anforderungen, Entwurf, Implementierung, Test und Einführung folgen aufeinander und werden durch definierte Übergaben sowie Dokumente verbunden.
Die Nachteile des Wasserfallmodells liegen vor allem in spätem Feedback, geringer Anpassungsfähigkeit und hoher Abhängigkeit von frühen Annahmen. Fehler in Anforderungen oder Architektur werden dadurch erst sichtbar, wenn bereits Folgearbeiten darauf aufbauen.
Fehlendes Kundenfeedback in der Softwareentwicklung verhindert die frühe Prüfung fachlicher Annahmen. Das Team kann dann zwar planmäßig liefern, erfährt aber spät, ob die Lösung im tatsächlichen Arbeitsablauf funktioniert.
Die Kosten später Fehlerkorrektur lassen sich nicht seriös mit einem universellen Multiplikator angeben. Sie hängen von Systemkomplexität, Abhängigkeiten, Fehlerart und Prozess ab; Untersuchungen zeigen sowohl starke Kostensteigerungen in komplexen Systemen als auch Fälle ohne allgemeinen statistischen Spätfehler-Effekt.
Ein sequentielles Vorgehensmodell ist sinnvoll, wenn Anforderungen stabil, technische Risiken bekannt und Nachweise oder Freigaben verbindlich sind. Bei stark veränderlichen Anforderungen und hoher Nutzerunsicherheit passt ein iteratives Vorgehen besser.
Scrum als Alternative zu klassischen Vorgehensmodellen eignet sich für komplexe Produktentwicklung mit regelmäßigem Feedback und klarer Priorisierung. Kanban passt besser zu kontinuierlichem Arbeitsfluss und wechselnden Aufgaben; entscheidend sind Arbeitsumfeld, Entscheidungswege und tatsächlicher Feedbackzugang.