Agil vs. Wasserfall ist die Wahl zwischen zwei Wegen: erst alles planen und dann in einem Durchgang bauen (Wasserfall) oder in kurzen Zyklen bauen und den Plan anpassen, während man lernt (agil). Bei den meisten App- und Website-Projekten liegt die ehrliche Antwort dazwischen: eine feste Discovery- und Designphase, danach kurze Umsetzungszyklen mit einem klaren Budget. Dieser Leitfaden erklärt beide Methoden in einfachen Worten, vergleicht sie direkt, zeigt, was zu Websites, Apps und Markenarbeit passt, und endet mit den passenden Verträgen und einer Checkliste für die Wahl.
Was bedeuten agil und Wasserfall, einfach erklärt?
Bevor man sie vergleicht, hilft es, beide Begriffe vom Jargon zu befreien. Keiner ist eine Religion. Beide sind eine Art zu entscheiden, wann Sie sich darauf festlegen, was gebaut wird, und wie teuer es ist, später umzudenken.
Wasserfall: erst entscheiden, dann bauen
Beim Wasserfall läuft ein Projekt als Abfolge von Phasen. Anforderungen werden gesammelt und freigegeben, dann folgen Design, Umsetzung, Tests und Launch. Jede Phase beginnt, wenn die vorherige abgeschlossen ist, und ein Schritt zurück kostet Zeit und Geld.
Seine Stärke ist die Planbarkeit. Sie kennen Umfang, Preis und Termin, bevor die erste Zeile Code geschrieben ist. Seine Schwäche: Er setzt voraus, dass Sie zu Beginn alles wissen. Wenn ein echter Nutzer dem Produkt zum ersten Mal begegnet, kurz vor Schluss, ist es spät, um zu erfahren, dass ein zentraler Screen für ihn nicht funktioniert.
Agil: bauen, lernen, anpassen
Agil teilt die Arbeit in kurze Zyklen von meist ein oder zwei Wochen, oft Sprints genannt. Jeder Zyklus endet mit etwas Funktionierendem, das Sie sehen und testen können. Die Liste dessen, was als Nächstes gebaut wird (das Backlog), wird nach jedem Zyklus neu priorisiert, je nachdem, was man gelernt hat.
Seine Stärke ist die Anpassungsfähigkeit. Fehler zeigen sich früh, wenn sie noch günstig sind, und Sie können jederzeit mit etwas Nutzbarem aufhören. Seine Schwäche: Endgültiger Umfang und Kosten stehen zu Beginn nicht fest. Das macht manche Auftraggeber nervös, und eine schwache verantwortliche Person auf Kundenseite wird zum echten Risiko: Agil braucht jemanden auf Ihrer Seite, der jede Woche entscheidet.
Agil vs. Wasserfall im direkten Vergleich
Die Tabelle zeigt die praktischen Unterschiede, die Sie als Auftraggeber spüren, nicht die Theorie.
| Wasserfall | Agil | |
|---|---|---|
| Umfang | Zu Beginn festgelegt | Entwickelt sich von Zyklus zu Zyklus |
| Budget | Festpreis für einen festen Umfang | Fest pro Zyklus; die Summe folgt dem Umfang |
| Wann Sie Funktionierendes sehen | Kurz vor Schluss | Alle ein bis zwei Wochen |
| Kosten einer Änderung | Hoch, über Change Requests | Niedrig, im nächsten Zyklus aufgefangen |
| Ihr Zeitaufwand | Hoch zu Beginn und bei der Abnahme | Gleichmäßig, jede Woche |
| Dokumentation | Ausführlich, vorab geschrieben | Schlanker, laufend aktuell gehalten |
| Am besten, wenn | Die Anforderungen klar und stabil sind | Sich die Anforderungen beim Lernen ändern werden |
| Hauptrisiko | Das Falsche gut bauen | Umfang und Budget laufen davon |
Keine der beiden Spalten ist „besser“. Wasserfall tauscht Flexibilität gegen Sicherheit, agil Sicherheit gegen Flexibilität. Die richtige Wahl hängt davon ab, wie viel Sie bereits wissen.
Welche Methode passt zu Websites, Apps und Branding-Projekten?
Die Art des Projekts entscheidet mehr über die Methode als jede Vorliebe der Agentur. So ordnen sich die drei Projektarten ein, an denen wir am häufigsten arbeiten.
Websites
Eine Marketing- oder Unternehmenswebsite hat meist eine bekannte Form: eine Reihe von Seiten, ein Content-Management-System, Formulare, Sichtbarkeit in Suchmaschinen. Vieles davon lässt sich vorab planen, was für Discovery, Sitemap und Design zu einer Wasserfall-ähnlichen Struktur passt.
In der Umsetzung hilft Agilität. Inhalte kommen spät, eine Seite braucht einen neuen Abschnitt, der Kunde sieht die Startseite im Browser und möchte, dass der Hero-Bereich anders funktioniert. Wer in kurzen Zyklen auf einer Staging-Website baut, kann solche Änderungen ohne formellen Change Request für jede einzelne umsetzen. Wenn Sie budgetieren, schlüsselt unser Leitfaden Was kostet eine Website? auf, wohin das Geld in jeder Phase von Webdesign und Webentwicklung fließt.
Apps
Bei Apps, ob mobile App oder Webanwendung mit Konten, Daten und Geschäftslogik, scheitert reiner Wasserfall am häufigsten. Nutzer verhalten sich so, wie es keine Spezifikation vorhersagt, Plattformen ändern ihre Regeln, und das wertvollste Feature ist oft eines, das zu Beginn niemand aufgeschrieben hat.
Bei einer App ist agil fast der Standard. Eine erste nutzbare Version (das Minimum Viable Product) geht so früh wie möglich an echte Nutzer, und die nächsten Zyklen richten sich nach deren Verhalten. Wasserfall hat trotzdem seinen Platz für die festen Teile: das Datenmodell, Sicherheitsanforderungen, Integrationen mit bestehenden Systemen und alles, was eine Aufsichtsbehörde lesen wird.
Markenarbeit
Markenidentität ist etwas ganz anderes. Sie durchläuft Strategie, Konzept und Handwerk, und jeder Schritt hängt von der Entscheidung davor ab. Ein Logo lässt sich nicht sinnvoll „sprinten“: Eine Identität wird als Ganzes gewählt, aus wenigen durchdachten Richtungen.
Deshalb folgt Markenarbeit meist einer gestuften, Wasserfall-ähnlichen Abfolge mit Prüfpunkten, aber mit Raum, einen Schritt zurückzugehen, wenn ein Konzept nicht trägt. Als wir die Identität für Nothing To Eat entwickelt haben, standen das Zeichen und seine Konstruktion zuerst fest; die Website und ihre Screens kamen danach, aufgebaut auf bereits getroffenen Entscheidungen. Wenn Sie überlegen, wo Identität endet und Wahrnehmung beginnt, geht unser Beitrag Markenidentität vs. Markenimage weiter.
Hybride Ansätze, die funktionieren
Die meisten echten Projekte sind hybrid, ob man sie so nennt oder nicht. Die nützliche Frage ist, welche Teile fest und welche flexibel sind. Drei Muster tauchen immer wieder auf.
Feste Discovery, dann Sprints
Dieses Muster empfehlen wir am häufigsten. Die erste Phase ist eine Discovery mit festem Umfang und Festpreis: Ziele, Nutzer, Inhalte, technische Entscheidungen, eine Sitemap oder Feature-Map und die zentralen Screens im Design. Sie wissen genau, was sie kostet und was Sie bekommen.
Danach läuft die Umsetzung in Sprints entlang eines priorisierten Backlogs, mit einem Budget pro Sprint und einer Schätzung für das Ganze. Sie behalten Sicherheit, wo sie zählt (Richtung und Design), und Flexibilität, wo sie sich auszahlt (Umsetzung und Details).
Wasserfall mit agilem Kern
Manche Organisationen brauchen einen festen Vertrag und einen festen Launch-Termin: eine Behörde, ein Launch zu einem Ereignis, ein reguliertes Produkt. Hier ist die äußere Hülle Wasserfall, mit unterschriebenem Umfang und Meilensteinen, doch jeder Meilenstein wird intern in kurzen Zyklen mit Demos gebaut. Der Kunde sieht alle paar Wochen Funktionierendes, ohne dass der Vertrag seine Form ändert.
Agil mit festem Fundament
Bei einer App ist ein gängiges Muster, die Teile festzulegen, deren Änderung teuer ist (Architektur, Datenmodell, Sicherheit, Designsystem), und alles darüber agil zu halten. Features wandern frei im Backlog nach oben und unten, weil sich das Fundament nicht mit ihnen bewegt.
Welche Verträge passen zu welcher Methode?
Die gewählte Methode muss zum unterschriebenen Vertrag passen. Ein Widerspruch, etwa ein agiler Prozess in einem starren Festpreisvertrag, ist die häufigste Ursache für Streit, die wir sehen.
Festpreis
Ein Festpreis passt zu Wasserfall und zu Phasen mit festem Umfang wie Discovery oder Markenidentität. Die Agentur trägt das Risiko der Schätzung, deshalb muss der Umfang genau schriftlich festgehalten sein: Seiten, Funktionen, Korrekturschleifen, was enthalten ist und was nicht.
Alles außerhalb dieses schriftlichen Umfangs wird zum Change Request: ein kurzes Dokument, das die Änderung, ihre Kosten und ihre Auswirkung auf den Termin beschreibt, unterschrieben, bevor die Arbeit beginnt. Change Requests sind kein Trick. Sie halten einen Festpreis für beide Seiten fair.
Nach Aufwand
Abrechnung nach Aufwand passt zu agil. Sie zahlen die tatsächlich aufgewendete Zeit, meist pro Sprint oder pro Monat, zu einem vereinbarten Satz. Der Umfang kann sich frei bewegen, weil der Preis der Arbeit folgt.
Ihr Schutz ist Transparenz, keine feste Summe: ein Backlog, das Sie lesen können, eine Demo am Ende jedes Zyklus, ein laufender Stand gegenüber der Schätzung und das Recht, nach jedem Sprint mit allem bisher Gebauten aufzuhören. Eine Obergrenze pro Monat oder pro Phase ist eine vernünftige Forderung.
Festpreis pro Sprint
Ein Mittelweg ist ein Festpreis für jeden Sprint, mit festem Team und fester Dauer und einer flexiblen Liste dessen, was hineinkommt. Sie wissen, was jede Doppelwoche kostet; die Agentur weiß, wozu sie sich verpflichtet; der Inhalt jedes Sprints wird zu seinem Beginn vereinbart.
Wenn Sie nicht nur abwägen, wie Sie den Auftrag vertraglich regeln, sondern auch, wen Sie beauftragen, zeigt unser Vergleich Junge oder etablierte Agentur: Welche sollten Sie beauftragen?, was Sie beide fragen sollten.
Wie verändert KI die Abwägung?
Ein Teil des alten Arguments für Wasserfall waren die Kosten: Ein Richtungswechsel bedeutete, Arbeit von Hand neu zu machen. Das gilt heute weniger. Bei Odduel übernimmt KI einen Großteil der wiederkehrenden Produktion (Komponenten des Designsystems, Frontend-Code, erste Entwürfe, Testfälle, erste Übersetzungsentwürfe). So liefert ein Zyklus mehr Funktionierendes, und ein Richtungswechsel lässt sich günstiger auffangen.
Nicht günstiger wird das Urteilsvermögen. Strategie, Konzept, Art Direction, die Stimme der Marke und die finale Prüfung bleiben menschliche Arbeit, und dorthin fließt das Budget. Nach unserer Erfahrung verschiebt das mehr Projekte zu kurzen Zyklen: Wenn das Bauen schnell geht, ist es besser, früh echte Screens zu sehen, als eine Spezifikation zu perfektionieren, die kein Nutzer getestet hat. So führen wir Projekte in App-Entwicklung und UX/UI-Design von Barcelona und São Paulo aus.
Wie wählen Sie? Eine Checkliste
Beantworten Sie diese Fragen ehrlich. Je mehr Antworten auf der linken Seite liegen, desto eher passt Wasserfall; je mehr auf der rechten, desto eher agil.
- Anforderungen. Können Sie heute alles aufschreiben, was das Produkt können muss (Wasserfall), oder erfahren Sie das meiste von den Nutzern (agil)?
- Budget. Brauchen Sie eine feste Zahl, unterschrieben vor Arbeitsbeginn (Wasserfall), oder können Sie mit einem Monatsbudget und einem laufenden Stand arbeiten (agil)?
- Frist. Ist der Termin durch etwas außerhalb Ihrer Kontrolle festgelegt (Wasserfall-Hülle), oder ist er ein Ziel, das Sie gegen den Umfang abwägen können (agil)?
- Ihre Zeit. Kann jemand auf Ihrer Seite jede Woche Arbeit prüfen und entscheiden (agil), oder nur an wenigen Meilensteinen (Wasserfall)?
- Nutzer. Können Sie eine frühe Version echten Nutzern zeigen (agil), oder geht nichts hinaus, bevor alles fertig ist (Wasserfall)?
- Compliance. Braucht eine Aufsichtsbehörde, eine Vergaberegel oder ein Vorstand vorab eine vollständige Spezifikation (Wasserfall, zumindest für die äußere Hülle)?
- Art der Arbeit. Geht es um Markenidentität (gestuft), eine Marketing-Website (hybrid) oder eine App (agil mit festem Fundament)?
Sind Ihre Antworten gemischt, ist das normal. Wählen Sie einen hybriden Ansatz und entscheiden Sie Teil für Teil, was fest ist und was frei.
Häufige Fragen zur Agenturwahl
Ist agil immer teurer als Wasserfall?
Nein. Agil kann teurer wirken, weil die Summe zu Beginn nicht feststeht, doch Wasserfall-Projekte zahlen am Ende oft für Change Requests und Nacharbeit nach dem Launch. Agil gibt das Budget für das aus, was Nutzer wirklich brauchen, und Sie können aufhören, sobald das Produkt gut genug ist. Der echte Kostenunterschied entsteht dadurch, wie gut beide gesteuert werden.
Kann ein Festpreisvertrag agil sein?
Teilweise. Ein Festpreis pro Phase oder pro Sprint funktioniert gut mit agil, solange der Umfang darin jeweils zu Beginn vereinbart wird. Was scheitert, ist ein einziger Festpreis für eine feste Funktionsliste, kombiniert mit einem Versprechen von Flexibilität: Eines von beiden gibt nach, meist in einem Streit.
Welche Methode ist besser für einen Website-Relaunch?
Meist ein hybrider Ansatz. Discovery, Sitemap und die zentralen Seitendesigns profitieren davon, festgelegt und freigegeben zu werden; Umsetzung, Content-Pflege und Feinschliff profitieren von kurzen Zyklen auf einer Staging-Website. Die bestehende Website liefert vorab viel Wissen, was den festen Teil leichter planbar macht.
Wie lang ist ein Sprint in einem App-Projekt?
Die meisten Teams arbeiten mit ein oder zwei Wochen. Eine Woche hält das Feedback eng, lässt aber wenig Raum für größere Features; zwei Wochen sind der gängige Mittelweg. Wichtiger als die Länge ist, dass jeder Sprint mit etwas Funktionierendem endet, das Sie sehen und ausprobieren können.
Was muss ich in einem agilen Projekt beitragen?
Einen Product Owner auf Ihrer Seite: eine Person, die das Geschäft kennt, Prioritäten setzen kann und jede Woche verfügbar ist, um Arbeit zu prüfen und Fragen zu beantworten. Ohne diese Person wird agil langsam, weil das Team auf Entscheidungen wartet, die niemand treffen darf.
Haben Sie eine App oder Website im Sinn und sind unsicher, wie Sie sie aufsetzen sollen, beginnen Sie mit einer kurzen, festen Discovery: Sie liefert einen Preis für die Umsetzung, ein Design, auf das Sie reagieren können, und die Informationen, um die Methode sicher zu wählen. Sehen Sie, wie wir App-Entwicklung angehen, oder sprechen Sie mit uns über Ihr Projekt.
