Wasserfall vs. Agile: Zentrale Unterschiede und Einsatzmöglichkeiten

Was ist das Wasserfallmodell?

Es war die erste formale Methode der Softwareentwicklung und wurde 1970 eingeführt. Die Idee einer vorhersehbaren, sequentiellen Entwicklung stammt ursprünglich aus dem Ingenieur- und Bauwesen. Besonders in militärischen und luft- und raumfahrtbezogenen Projekten wurde das Wasserfallmodell populär, da es als planbar, kontrollierbar und gut dokumentiert galt. Seine größte Schwäche ist jedoch seine Starrheit.

Laut Sommerville (2015) handelt es sich um einen sequenziellen Prozess, bei dem ein Projekt nacheinander klar abgegrenzte Phasen durchläuft – Anforderungsanalyse, Design, Implementierung, Test und Wartung. Jede Phase muss vollständig abgeschlossen sein, bevor die nächste beginnt. Diese Struktur ermöglicht eine detaillierte Planung und Kontrolle, schränkt jedoch die Flexibilität bei sich ändernden Anforderungen stark ein. Das Modell gilt daher als grundlegendes Rahmenwerk für spätere Softwareentwicklungsmethoden.

Unsere Erfahrungen mit dem Wasserfallmodell

Bei Moravio haben wir früher die Wasserfall-Methodik zur Steuerung unserer Projekte eingesetzt. Dieser Ansatz fühlte sich natürlich an, da er leicht verständlich ist und in vielen Branchen weit verbreitet genutzt wird. Unser Prozess begann damit, alle Anforderungen und Inputs des Kunden zu Projektbeginn zu sammeln, die anschließend als Grundlage für die gesamte Entwicklung dienten.

Änderungen oder Abweichungen wurden zunächst aus vertraglicher Sicht geprüft, bevor sie im Code umgesetzt wurden. Auf Basis der vereinbarten Anforderungen boten wir einen Festpreis für das Projekt an. Um ein effektives Projektmanagement sicherzustellen, teilten wir die Arbeit in einzelne Phasen auf, wobei der Kunde nach Abschluss jeder Phase eine Zahlung leistete.

1. Phase: Anforderungsanalyse (Requirements Gathering & Analysis)

In dieser Phase führen wir eine detaillierte Analyse der Kundenvorgaben, Geschäftsziele, Prozesse und Marketingstrategien durch. Dabei definieren wir sowohl funktionale als auch nicht-funktionale Anforderungen sowie die unterstützten Geräte. Diese Analyse ermöglicht es uns, eine umfassende Projektdokumentation zu erstellen, die die vorgeschlagene Lösung beschreibt und in manchen Fällen auch Wireframes enthält. Zusätzlich führen wir eine technische Analyse durch, in der die geplante Architektur, die eingesetzten Technologien und die Datenbankstruktur beschrieben werden. Nach der Freigabe der Anforderungen planen wir die technischen Aufgaben, erstellen das Budget und legen die erwarteten Implementierungskosten fest.

2. Designphase

In dieser Phase wird das grafische Design der Lösung erstellt. Wir stellen dem Kunden zwei bis drei Feedback- und Überarbeitungsrunden zur Verfügung, bevor die finale Version gemeinsam freigegeben wird.

3. Implementierung

Sobald das Design freigegeben ist, beginnt die Umsetzung der geplanten Aufgaben. Während dieser Phase erhält der Kunde regelmäßig Updates zum Projektfortschritt, das fertige Produkt wird am Ende der Implementierung geliefert. Neue Anforderungen, die während dieser Phase entstehen, werden als Zusatzleistungen betrachtet und müssen vom Kunden separat geschätzt und genehmigt werden.

4. Testphase

Das final funktionierende Produkt wird in einer Testumgebung bereitgestellt und dem Kunden zur ausführlichen Prüfung übergeben. In der Regel wird dafür ein zuvor vereinbarter Zeitraum festgelegt. Nach Abschluss der Tests wird erwartet, dass der Kunde Feedback gibt und das Übergabeprotokoll unterzeichnet.

5. Deployment

Sobald das Produkt freigegeben ist, wird es gemäß der mit dem Kunden getroffenen Vereinbarung in die Produktionsumgebung ausgerollt („Go-live“).

6. Wartung

Nach der Übergabe des fertigen Produkts schließen wir in der Regel einen SLA-Vertrag ab und leisten über einen definierten Zeitraum laufenden Support für die Lösung. Möchte der Kunde die Zusammenarbeit zu irgendeinem Zeitpunkt im Projekt beenden, müssen die Bedingungen für die Stornierung von Aufträgen und die Beendigung des Vertrags einvernehmlich geregelt werden.

What do we think about Waterfall?

Ich würde nicht sagen, dass dieser Ansatz grundsätzlich falsch ist – er kann für kleinere Projekte oder für die Erstellung derselben Softwarelösung für mehrere Kunden durchaus geeignet sein. Allerdings entspricht dies nicht der Art von Arbeit, die wir normalerweise leisten. Wir entwickeln maßgeschneiderte Software für unsere Kunden. Während wir auf Basis früherer Erfahrungen grobe Schätzungen abgeben können, wird es umso schwieriger, jedes Detail zu Beginn eines Projekts genau festzulegen, je komplexer oder größer das Projekt wird – sowohl für uns als auch für den Kunden.

Es gab Fälle während der Entwicklung, in denen die verantwortliche Person auf Kundenseite gewechselt hat oder sich interne Prozesse verändert haben. Manchmal stellten Kunden, sobald sie die entwickelte Funktion oder das Design sahen, fest, dass es anders funktionieren oder an geänderte Benutzergewohnheiten oder Marktbedingungen angepasst werden musste.

All diese Faktoren führten zu Änderungen der Anforderungen für ein bereits entwickeltes Produkt. Am Ende war der Kunde oft unzufrieden, weil die ursprünglichen Anforderungen seine tatsächlichen Bedürfnisse nicht mehr widerspiegelten – und wir waren ebenfalls unzufrieden, aufgrund der gestiegenen Projektkosten und der schwierigen Verhandlungen über die zusätzlichen benötigten Ressourcen.

Einschränkungen des Waterfall-Modells, die wir beobachten:

• Probleme mit den Anforderungen treten häufig erst in späteren Phasen auf – während Design, Implementierung oder Tests.
• Neue Informationen tauchen während der Entwicklung oft auf und müssen sowohl in der Dokumentation als auch in der Umsetzung berücksichtigt werden.
• Die nächste Phase kann erst beginnen, wenn die vorherige abgeschlossen ist, was zu Verzögerungen zwischen den Phasen und einer Verlängerung des Projektzeitplans führt.
• Jede Änderung muss von beiden Parteien genehmigt und vertraglich festgehalten werden, bevor sie in der Dokumentation und Umsetzung umgesetzt werden kann.
• Benutzertests finden erst nach der vollständigen Implementierung des Systems statt, was oft Fehler oder Lücken in den ursprünglichen Anforderungen aufdeckt – deren Behebung ist teuer.
• Neue Feature-Ideen können nach den Benutzertests entstehen und zusätzliche Entwicklungsarbeit erfordern.
• Höheres Risiko des Scheiterns bei komplexeren oder dynamischeren Projekten.
• Die Beteiligung des Kunden während des Projekts ist typischerweise gering.
• Projektänderungen können durch verändertes Nutzerverhalten oder Marktbedingungen erforderlich werden. Die ursprünglichen Anforderungen spiegeln möglicherweise nicht die realen Bedürfnisse wider.
• Steigende Projektkosten können sowohl für den Kunden als auch für das Softwareunternehmen zu Herausforderungen führen.

Vorteile des Waterfall-Modells, die wir beobachten:

• Kosten, Zeit und Ressourcen sind klar definiert.
• Jede Phase hat spezifische Ziele, Ergebnisse und Genehmigungskriterien.
• Alle Anforderungen werden dokumentiert und von beiden Parteien genehmigt.
• Einfachere Nachverfolgung von Fortschritt, Budgeteinhaltung und Zeitplan.
• Klare Verteilung der Verantwortlichkeiten.

Wann ist Waterfall nützlich?

• Systeme mit klaren Anforderungen, die sich wahrscheinlich nicht ändern werden (z. B. ERP-Module, Buchhaltungssysteme, Bankensoftware).
• Systeme, die gesetzlichen oder regulatorischen Vorgaben unterliegen (z. B. pharmazeutische Tracking-Systeme oder gesetzeskonforme Buchhaltungssoftware).
• Projekte mit strikten Vorgaben zu Zeit, Umfang und Kosten – oft bei staatlichen Aufträgen.
• Projekte, die detaillierte Dokumentation und formale Genehmigungsprozesse erfordern (z. B. Luft- und Raumfahrt, Pharmaindustrie, Militär).
• Systeme, die auf etablierten Technologien basieren (z. B. Datenbankmigrationen oder Neuentwicklung von Legacy-Anwendungen auf einer neuen Plattform ohne Änderung der Funktionalität).
• Wenn Stakeholder einen klaren Plan, detailliertes Reporting und strenge Kontrolle benötigen.

Was ist Agile Softwareentwicklung?

Agile Softwareentwicklung ist ein iterativer und inkrementeller Ansatz, der Flexibilität, Zusammenarbeit und Kundenfeedback in den Mittelpunkt stellt. Sie wurde Anfang der 1990er Jahre entwickelt. Das am weitesten verbreitete Framework zur Umsetzung der Prinzipien des Agile Manifesto ist Scrum

Anstatt ein Projekt in einem einzigen, sequentiellen Prozess abzuschließen, teilt Agile die Arbeit in kleine, handhabbare Iterationen, sogenannte Sprints, auf. Jeder Sprint liefert einen funktionalen Teil des Produkts, wodurch Teams sich an sich ändernde Anforderungen anpassen und durch regelmäßige Reviews und Feedback kontinuierlich verbessern können.

Agile legt Wert auf Individuen und Interaktionen, funktionierende Software, Kunden-Zusammenarbeit und Anpassung an Veränderungen – mehr als auf starre Prozesse oder umfangreiche Dokumentation.

(Beck et al., 2001; Sommerville, 2015)

Andere bekannte genutzte Frameworks

• Kanban 
• Lean Development
• Extreme programing
• Dynamic Systems Development Method
• Feature Driven Development
• Crystal

Wie haben wir mit Agile Development begonnen?

Hybrid zwischen Waterfall und Agile

Am Anfang nutzten wir eine Mischung aus Agile und Waterfall – eher einen Hybrid-Ansatz.

Die Kunden waren noch nicht mit Agile vertraut und vertrauten ihm oft nicht vollständig, daher entschieden wir uns für einen Kompromiss. Wir einigten uns auf einen festen Zeitplan und ein ungefähres Budget basierend auf den spezifizierten Anforderungen. Der Hauptunterschied zu unserer vorherigen Waterfall-Methode war die enge Zusammenarbeit mit den Kunden, ein zentrales Prinzip von Agile.

Wir teilten die Lieferung in Sprints auf, hielten alle zwei Wochen Demos mit dem Kunden ab und arbeiteten daran, die Anforderungen mindestens einen Sprint im Voraus zu spezifizieren. Die Zusammenarbeit und die Kundenzufriedenheit mit dem Endprodukt verbesserten sich deutlich; jedoch wuchs das Product Backlog während des Projekts weiter, was den Zeitplan ebenfalls verlängerte. Der Nachteil dieses Modells war der hohe Aufwand für Reporting und die Rechtfertigung jeder zusätzlichen Arbeitsstunde. Es war immer noch nicht die echte Win-Win-Partnerschaft, die wir erreichen wollten.

Wir erkannten, dass unsere nächsten Projekte vollständig agil umgesetzt werden mussten. Wir überarbeiteten unsere Verträge, und im Laufe der Zeit wurde die Agile-Methodik sowie ihre Vorteile von unseren Kunden deutlich besser verstanden und geschätzt.

Warum Agile?

Bei Moravio legen wir von Beginn eines Projekts großen Wert auf Ehrlichkeit und Transparenz gegenüber unseren Kunden. Anstatt feste Termine und Preise zu versprechen, geben wir grobe Schätzungen basierend auf ersten Ideen oder Spezifikationen.

Gleichzeitig arbeiten wir eng mit jedem Kunden zusammen, um die Bedürfnisse der Endnutzer zu verfeinern und den Projektumfang so anzupassen, dass er innerhalb des verfügbaren Budgets bleibt.

• Wir sind überzeugt, dass klare Kommunikation und enge Zusammenarbeit mit unseren Kunden entscheidend für den Erfolg eines Projekts sind.
• Unser Ziel ist stets, das bestmögliche Ergebnis für unsere Kunden zu erreichen. Deshalb arbeiten wir kontinuierlich mit ihnen zusammen, um die Anforderungen zu verfeinern und den Umfang bei Bedarf anzupassen. So stellen wir sicher, dass wir ein qualitativ hochwertiges Produkt liefern, das den Bedürfnissen der Kunden entspricht und gleichzeitig das Budget einhält.
• Wir erkennen an, dass sich Projektanforderungen im Laufe der Zeit entwickeln können, und bleiben verpflichtet, uns diesen Änderungen durch fortlaufende Zusammenarbeit anzupassen. Durch das Verfeinern der Anforderungen und das flexible Anpassen des Umfangs liefern wir konsequent hochwertige Lösungen, die den Erwartungen unserer Kunden entsprechen und gleichzeitig die Budgeteffizienz wahren.

Unser Hauptziel ist es,

unseren Kunden herausragende Qualität zu liefern, gestützt auf unsere umfassende Erfahrung, Expertise und unser unerschütterliches Engagement für jeden Sprint. Wir sind überzeugt, dass wir durch enge Zusammenarbeit mit unseren Kunden und kontinuierliches Verfeinern der Anforderungen der Endnutzer hochwertige Lösungen liefern können, die ihren Erwartungen entsprechen.

Darüber hinaus verpflichten wir uns dazu, unseren Kunden die volle Kontrolle über ihre Projekte zu gewährleisten. Sie sollen jederzeit die Freiheit haben, einen anderen Softwareanbieter zu wählen, falls sie mit unseren Leistungen unzufrieden sein sollten (natürlich unter Berücksichtigung der vereinbarten Kündigungsfristen).

Unser Erfolg als Softwareentwicklungsunternehmen hängt letztlich von der Zufriedenheit unserer Kunden ab. Deshalb arbeiten wir daran, dass jedes Projekt, das wir durchführen, zu einem positiven Ergebnis für beide Parteien führt.

Wie wir arbeiten

Unter den Frameworks der Agile-Methodik nutzen wir hauptsächlich Scrum, obwohl wir für einige Projekte auch Kanban anwenden. Typischerweise arbeiten wir in kurzen, zweiwöchigen Iterationen (Sprints), in deren Verlauf wir die Ergebnisse am Ende jedes Sprints präsentieren, gemeinsam mit dem Kunden besprechen und weiter verfeinern. Wir sammeln Feedback, wandeln es in umsetzbare Aufgaben um und priorisieren diese in Abstimmung mit dem Kunden

Wenn ein Kunde plötzlich die Richtung ändern muss, ist das kein Problem – in Agile sind wir nicht an feste Verträge oder starre Prozesse gebunden. Wir klären einfach die neuen Anforderungen mit dem Kunden und planen die Änderungen gegebenenfalls für den nächsten Sprint ein.

Vorteile der agilen Entwicklung

• Flexibilität und schnelle Anpassung an sich ändernde Anforderungen.
• Schnelle Rückkopplung von Stakeholdern nach jedem Sprint.
• Klare Transparenz des Fortschritts für Teammitglieder und Stakeholder.
• Höhere Team-Beteiligung und Motivation.
• Hohe Produktqualität durch häufiges Testen der implementierten Features.

Engpässe der agilen Entwicklung

• Risiko von Scope Creep – Prioritäten können sich in jedem Sprint ändern.
• Erfordert erfahrene, selbstorganisierte und funktionsübergreifende Teams.
• Kann bei Projekten mit festem Umfang oder bei der Koordination mehrerer Teams weniger effektiv sein.
• Weniger vorhersehbare Zeitpläne und Kosten – die flexible Natur erschwert die Abschätzung von Endkosten und Lieferterminen zu Projektbeginn.

Zusammenfassung der Unterschiede zwischen der Waterfall- und der Agile-Methodik

Warum bevorzugen wir bei Moravio Agile gegenüber Waterfall im Projektmanagement?

• Weil uns wirklich wichtig ist, was wir entwickeln, und wir Wert auf das Endprodukt legen.
• Wir bevorzugen enge Zusammenarbeit mit unseren Kunden, um funktionale und sinnvolle Lösungen zu schaffen, statt endlose Verhandlungen über jede Minute im Projekt zu führen.
• Wir schätzen Agilität und Flexibilität mehr als das blinde Festhalten am ursprünglichen Plan.

Werkzeuge, die wir für Agile & Waterfall verwenden:

• Jira - ein benutzerfreundliches Tool mit Boards, geeignet für alle Arten von Projekte. 
• Product Discovery von Atlassian - intuitiv und leicht in die Entwicklungsboards integrierbar.
• Für kleinere Projekte haben wir früher Trello verwendet.
• Gitlab - gelegentlich als vom Kunden bereitgestelltes Tool zur Verwaltung bestimmter Projekte genutzt.

Im Allgemeinen bevorzugen wir es, die Werkzeuge zu verwenden, die wir am besten kennen, sind jedoch immer bereit, uns bei Bedarf an die bevorzugten Lösungen unserer Kunden anzupassen.

Weitere Softwareentwicklungsmethoden

Laut dem 17. „State of Agile“-Bericht von 2023 nutzen 71 % der befragten Unternehmen Agile in ihrem Softwareentwicklungszyklus. Es werden jedoch auch andere Methoden verwendet, darunter:

• V-Modell
• Rapid Application Development
• Spiralmodell
• Inkrementelle Entwicklung

Wie verändert KI das Management der Softwareentwicklung?

Über traditionelle Methoden hinaus verändert KI die Arbeitsweise von Waterfall und Agile heute grundlegend. Sie revolutioniert, wie Projektanforderungen erfasst und verwaltet werden. KI ermöglicht eine einfachere Zusammenfassung und Analyse von Daten sowie die automatische Erstellung von Dokumentationen (sogenannte spec-driven development)

KI spielt auch eine wachsende Rolle im Anwendungsdesign – zum Beispiel durch die automatische Generierung von Wireframes aus Text-Prompts, wodurch Design für jeden zugänglich wird. Sie kann sogar einfache funktionierende Anwendungen direkt aus der Dokumentation erstellen.

In verschiedenen Rollen hilft KI Teams, konsistenter, effizienter und produktiver zu arbeiten. Sie kann Entwicklungstasks aus Dokumentationen ableiten, konkrete Code-Implementierungen vorschlagen und bei automatisierten Tests sowie der Validierung realer Anwendungen unterstützen.

Aus methodischer Sicht hilft KI beim Vergleich von Agile vs. Waterfall, einige der traditionellen Einschränkungen des Waterfall-Modells zu überwinden – insbesondere beim Erfassen von Anforderungen und bei der Dokumentation. Diese Prozesse werden dadurch schneller und flexibler. Vertrags- und Änderungsmanagement-Restriktionen bestehen zwar weiterhin, ihr Einfluss hängt jedoch weitgehend von effektiver Kommunikation und Zusammenarbeit mit den Kunden ab.

Wie jedes Werkzeug kann auch KI missbraucht werden. Es besteht ein zunehmendes Risiko, dass Menschen sich zu stark auf die Technologie verlassen und aufhören, kritisch über ihr Handeln nachzudenken. Beispielsweise könnten Teams automatisch große Mengen an Anforderungen oder Code generieren, die unnötig, unklar oder nicht mit den tatsächlichen Projektanforderungen verbunden sind – nur um etwas zu produzieren, das oberflächlich „poliert“ aussieht.

Ähnlich verhält es sich bei KI-generierten Designs: Werden sie nicht richtig überprüft, können sie zu Missverständnissen zwischen Designern, Entwicklern und Kunden führen. Dies kann Kommunikationslücken, Inkonsistenzen und zusätzlichen Mehraufwand später im Prozess verursachen

Dasselbe gilt für automatisch generierten Code – wenn er unnötig oder zu komplex ist, kann er ernsthafte Engpässe und Probleme im Entwicklungsprozess schaffen. Nur weil etwas einfach und automatisch erstellt werden kann, bedeutet das nicht, dass es auch erstellt werden sollte.

KI sollte Kreativität, Effizienz und Verständnis unterstützen – nicht ersetzen. Es ist entscheidend, menschliche Aufsicht, kritisches Denken und Zusammenarbeit aufrechtzuerhalten, um sicherzustellen, dass KI ein leistungsstarker Assistent bleibt und nicht zu einem unkontrollierten Entscheidungsträger wird.

Wie sehen wir die Zukunft bei Moravio?

Bei Moravio folgen wir nicht strikt der Agile- oder der Waterfall-Methodik. Die Wahl hängt immer vom Projekttyp, den Bedürfnissen des Kunden und den allgemeinen Erwartungen ab. Beide Ansätze können zu hervorragenden Ergebnissen oder zu Herausforderungen führen – je nach den jeweiligen Umständen.

Wirklich entscheidend sind Zusammenarbeit und Klarheit. Wenn ein Kunde eine klare Vorstellung davon hat, was er schaffen möchte, oder offen dafür ist, diese Vision gemeinsam mit uns zu verfeinern, läuft der Prozess reibungslos – unabhängig von der gewählten Methodik.

Am Ende hängt der Erfolg, wie bei den meisten Dingen im Leben, von den Menschen ab – von offener Kommunikation, gegenseitigem Vertrauen und der Qualität der Partnerschaft.

Quellen: 

Somerville (2015), Software Engineering, 10th GLO https://dn790001.ca.archive.org/0/items/bme-vik-konyvek/Software%20Engineering%20-%20Ian%20Sommerville.pdf 

Agile frameworks: https://www.wrike.com/agile-guide/faq/what-is-fdd-in-agile/

Softwareentwicklungs-Methodologien: https://www.itransition.com/software-development/methodologies