Agil oder Wasserfall: So wählen Sie für Ihr Softwareprojekt

Beim Wasserfall wird das ganze Projekt zuerst geplant und danach in aufeinanderfolgenden Phasen umgesetzt. Agil plant in kurzen Zyklen und passt laufend an, was dazugelernt wird. Wählen Sie Wasserfall, wenn Umfang, Budget und Freigaben vor dem Start feststehen müssen. Wählen Sie agil, wenn Sie unterwegs Neues lernen werden, was bei einer neuen Website, App oder Plattform der Normalfall ist. Viele Schweizer Teams landen bei einer Mischform: fester Rahmen, iterative Umsetzung.

Dieser Leitfaden erklärt, was hinter beiden Methoden wirklich steckt, vergleicht sie an den Punkten, die Budget und Zeitplan beeinflussen, und gibt Ihnen einen praktischen Weg zur Entscheidung.

Das Wichtigste in Kürze

• Beim Wasserfall folgen die Phasen aufeinander (Anforderungen, Design, Umsetzung, Test, Release) und der gesamte Umfang wird vorab definiert. Agil liefert lauffähige Software in kurzen Sprints und setzt die Prioritäten dazwischen neu.
• Wasserfall passt bei stabilem, gut verstandenem Umfang und formellen Freigaben. Agil passt bei Produkten, bei denen Nutzende, Markt oder Anforderungen Ihnen noch etwas beibringen werden.
• Der teuerste Fehlschlag im Wasserfall ist die späte Erkenntnis: eine Änderung, die erst im Test auftaucht, kann wochenlange Designarbeit entwerten.
• Mischformen sind in der Schweiz verbreitet: Wasserfall für Umfang, Budget und Steuerung, agil für die Umsetzung selbst.
• Die Methode zählt weniger als die Menschen, die sie führen. Über das Ergebnis entscheiden meist Kontinuität erfahrener Leute und ehrliche Kommunikation.

Was Wasserfall und agil tatsächlich bedeuten

Wasserfall ist eine lineare, strukturierte Abfolge von Schritten, die innerhalb des Software-Lebenszyklus nacheinander abgeschlossen werden, so IBM describes it. Jede Phase endet, bevor die nächste beginnt. Eine Schweizer Zusammenfassung aus der Wissenschaft, vom UNIL’s executive education team, formuliert es gleich: aufeinanderfolgende Phasen, jede abgeschlossen, bevor die nächste startet.

Eine typische Beschreibung des Modells aus der Forschung, von Wohlin and colleagues, führt durch Anforderungsanalyse, Design und Umsetzung, Test, Release und Wartung. Zwischen den Phasen müssen Dokumente eine Qualitätsprüfung bestehen, ein sogenanntes Stage-Gate. An diesem Tor prüft das Team, ob die Anforderungen verstanden, abgestimmt und dokumentiert sind und ob die relevanten Anspruchsgruppen bekannt sind.

Agil ist iterativ. Statt am Anfang umfangreiche Anforderungen zu verfassen, zerlegen Teams das Produkt in Funktionen und bearbeiten sie in zeitlich begrenzten Sprints, so IBM describes it. Am Ende jedes Sprints zeigt das Team seine Arbeit den Anspruchsgruppen, und deren Rückmeldungen können die Roadmap verändern.

Wo Scrum hineinpasst

Oft werden agil und Scrum gleichgesetzt. Das ist falsch. Die Scrum Alliance erklärt, dass agil ein Sammelbegriff für Ansätze mit gemeinsamen Werten und Prinzipien ist, während Scrum ein häufig genutztes Rahmenwerk zur Organisation der Arbeit darstellt. Scrum wirkt auf Ebene eines Produktteams; agil als Haltung reicht in die ganze Organisation hinein. «Scrum vs. Wasserfall» vergleicht also ein agiles Rahmenwerk mit einer sequenziellen Methode. Kanban und andere sind ebenfalls agil.

Wie sie sich in der Praxis unterscheiden

Die Unterschiede zeigen sich an sechs Stellen, die Ihr Projekt direkt betreffen.

Aspekt	Wasserfall	Agil
Planung	Umfassend, zu Beginn	Grobe Roadmap, Details entstehen pro Sprint
Umfang	Vollständig definiert, bevor die Arbeit beginnt	Backlog wird an den Sprintgrenzen neu priorisiert
Lieferung	Ein Release am Ende	Lauffähige Software in jedem Sprint
Testen	Eigene Phase nach der Umsetzung	Laufend, innerhalb jedes Sprints
Änderungen	Formell gesteuert	Erwartet und aufgenommen
Einbezug der Anspruchsgruppen	Stark bei Anforderungen und Abnahme	Prüfung lauffähiger Software in jedem Sprint

Die Tabelle folgt dem Vergleich in Rework’s methodology guide. Zwei Punkte verdienen mehr Detail.

Planung und Dokumentation

Im Wasserfall dokumentieren Sie die Anforderungen von A bis Z, bevor die Entwicklung startet. Agil dokumentieren Sie vor allem das, was die ersten Sprints brauchen. Deloitte Switzerland zieht genau diesen Vergleich im Zusammenhang mit der IT-Transformation von Kernbankensystemen.

Ein verbreiteter Irrtum lautet, agil bedeute keine Dokumentation. PMI Switzerland berichtete von einem Praxisanlass, dass in den meisten Fällen kein im Wasserfall genutztes Dokument im agilen Vorgehen fehlt und agile Projekte teils sogar mehr produzieren. Agil kommen eigene Artefakte dazu, etwa Produkt-Backlog, Sprint-Backlog und Burndown-Chart. Was sich ändert, ist der Zeitpunkt der Dokumentation und wie viel früh entschieden wird.

Umgang mit Änderungen

Hier verläuft die eigentliche Trennlinie. TechTarget beschreibt den Wasserfall als torgesteuert: Teams können erst in die nächste Phase, wenn die aktuelle gemäss definierten Kriterien abgeschlossen ist. Agil können Rückmeldungen der Kundschaft künftige Sprints verändern, basierend auf dem, was frühere Sprints gezeigt haben.

Die Scrum Alliance weist auf die Folge für den Wasserfall hin: Nutzen erreicht die Endnutzenden erst am Projektende. Bis dann können Monate oder Jahre vergangen sein, und die Anforderungen wurden vielleicht nie überprüft. Grosse Änderungen können einen Neustart erzwingen oder das Projekt beenden, was Zeit und Geld kostet. Die Zusammenfassung der UNIL nennt denselben Nachteil: eine grosse Anpassung, die während des Tests entdeckt wird, kann wochenlange Designarbeit entwerten, was späte Änderungen teuer macht.

Ein Wasserfall-Beispiel, Schritt für Schritt

Der Wasserfall ist kein überholtes Relikt. Er ist eine sinnvolle Form für Arbeiten, deren Ziel bekannt ist. Der Schweizer Softwareanbieter Polynorm beschreibt eine classic Waterfall software introduction in sechs Phasen:

1. Grobkonzept
2. Detailkonzept
3. Softwareanpassungen gemäss Konzept
4. Datenmigration
5. Schulung
6. Go-live

Das Projekt wird detailliert geplant und danach gemäss Plan durchgeführt, wobei der Aufwand auf Kundenseite vor allem am Anfang und am Ende hoch ist. Dieses Muster passt etwa zur Einführung eines etablierten ERP-Moduls in einem Unternehmen, dessen Prozesse bereits definiert sind.

Beachten Sie, was das von Ihnen verlangt: Sie müssen Ihre Anforderungen von Beginn weg kennen. Wenn das zutrifft, gibt Ihnen der Wasserfall einen klaren Weg und wenige Überraschungen. Wenn nicht, ist der Plan eine Vermutung in selbstbewusster Sprache.

Ein agiles Beispiel

Stellen Sie sich eine Gründerin vor, die eine Buchungsplattform für einen Nischenmarkt aufbaut. Die erste Version braucht Konten, einen Kalender und Zahlungen. Alles andere ist Hypothese: Wollen Kundinnen und Kunden Erinnerungen, Gruppenbuchungen, Rechnungen?

In einem agilen Vorgehen liefert Sprint eins einen klickbaren Buchungsablauf. Die Gründerin zeigt ihn fünf möglichen Kundinnen und Kunden. Die Rückmeldungen schieben Gruppenbuchungen im Backlog nach oben und Erinnerungen nach unten. Sprint zwei baut die Zahlungen. Nach ein paar Sprints gibt es ein Produkt, das Menschen nutzen können, und das Geld floss in Funktionen, die echte Rückmeldungen gestützt haben. Ein Wasserfallplan hätte alle Funktionen vorab festgelegt und das Ergebnis Monate später gezeigt.

Der Preis dafür: Agil verlangt mehr von Ihnen. Jemand auf Ihrer Seite muss schnell entscheiden, an Reviews teilnehmen und die Prioritäten verantworten. Ein beweglicher Umfang braucht einen Budgetrahmen, der sich bewusst mitbewegt, nicht zufällig.

Wann agil sinnvoll ist und wann der Wasserfall besser passt

Nutzen Sie dies als Entscheidungshilfe, nicht als Regel.

Agil passt, wenn:

• Anforderungen unsicher sind oder sich mit Rückmeldungen der Nutzenden ändern werden.
• Sie ein neues Produkt, ein MVP oder eine Plattform bauen, bei der das Lernen der Sinn der Sache ist.
• Sie eine lauffähige Version in Wochen wollen, nicht am Ende eines langen Plans.
• Die Anspruchsgruppen für regelmässige Reviews verfügbar sind.
• Markt oder Konkurrenz sich schnell bewegen.

Wasserfall passt, wenn:

• Der Umfang stabil und gut verstanden ist, etwa beim Ersatz eines bekannten Systems.
• Ein Vertrag, eine Aufsichtsbehörde oder ein Beschaffungsprozess feste Lieferergebnisse und formelle Freigaben pro Phase verlangt.
• Die Phasen physisch voneinander abhängen, etwa bei Hardware, Datenumstellungen oder Schulungsplänen.
• Ihre Organisation einen Festpreis und ein einziges Abnahmedatum braucht.

Stellen Sie sich drei Fragen:

1. Wie sicher sind wir, was wir brauchen? Je unsicherer, desto agiler.
2. Was kostet uns eine späte Änderung? Ist sie günstig, ist agil sicher. Ist sie ruinös, planen Sie mehr im Voraus.
3. Wer entscheidet auf unserer Seite? Agil braucht eine Produktverantwortung mit echter Entscheidungsbefugnis. Fehlt sie, stocken die Sprints.

Für die meisten Startups und wachsenden Unternehmen, die Websites, Apps oder Plattformen bauen, kippt die erste Frage die Antwort Richtung agil. Die ehrliche Einschränkung: Schlecht gemachtes «agil», ohne Ziele und ohne Budgetrahmen, kann ins Ziellose abdriften. Das ist ein Problem der Disziplin, nicht der Methode.

Der hybride Ansatz und warum Schweizer Teams ihn nutzen

In der Praxis sehen Sie selten reine Formen. Hybrides Projektmanagement verbindet vorgelagerte Planung von Umfang und Budget im Wasserfallstil mit iterativer Umsetzung und liefert in aufeinanderfolgenden Phasen statt auf einen Schlag. Die UNIL’s executive education team hält fest, dass dies dort passt, wo die Führung einen Zeitplan, Meilensteine und ein gesteuertes Budget braucht, während die Teams damit rechnen, dass sich Details entwickeln.

Schweizer Belege weisen in dieselbe Richtung:

• Eine study presented at ICIS 2015 untersuchte über mehr als ein Jahr einen «Water-Scrum-Fall»-Ansatz bei einer grossen Schweizer Bank, über vier Teams und 17 Interviews hinweg. Der Wasserfall definierte die vorgelagerte Arbeit (Funktionalität, Budget, Organisation), Scrum setzte die Software um, und für die letzten Schritte wie die Auslieferung kehrte der Wasserfall zurück.
• Das Schweizer Fachmedium inside-it.ch reported on the same pattern: Grossprojekte nutzen den Wasserfall zur Koordination, während die einzelnen Teams weiterhin agil arbeiten.
• Die öffentliche Hand hat ihre eigene Methode. HERMES ist ein offener eCH-Standard, der in der Schweizer Bundesverwaltung sowie in zahlreichen Kantonen und Städten eingesetzt wird. Teams, die für öffentliche Stellen arbeiten, müssen iterative Umsetzung deshalb oft in eine vorgegebene Steuerungsstruktur einpassen.

Eine Mischform für kleine Vorhaben

Sie brauchen nicht die Steuerungsstruktur einer Bank, um davon zu profitieren. Eine praktische Variante für ein Startup oder KMU:

1. Rahmen (im Wasserfallstil): Ziel, Budgetobergrenze, wichtige Meilensteine und die Definition von «fertig» für das erste Release vereinbaren.
2. Umsetzung (agil): in kurzen Zyklen arbeiten, mit sichtbarem Backlog und einer Demo pro Zyklus.
3. Release und Übergabe (im Wasserfallstil): eine definierte Abnahme, Dokumentation und eine saubere Übergabe, damit Sie danach nicht vom Umsetzungspartner abhängig sind.

Das gibt Finanzen und Führung eine Grenze und dem Team Raum zum Lernen.

Häufige Fehler bei beiden Methoden

• Die Methode nach Mode wählen. Keine ist automatisch besser. Die Vorstellung, Wasserfall sei schlecht und agil gut, ist eine populäre Vereinfachung und verleitet Teams dazu, Rituale ohne Substanz zu übernehmen.
• Fixer Umfang, Festpreis und «agil» zugleich. Wenn alle drei festgezurrt sind, bleibt kein Spielraum zum Anpassen. Entscheiden Sie, was flexibel bleibt.
• Die Vorabklärung überspringen. Auch agile Projekte brauchen eine kurze vorgelagerte Phase: Ziele, Nutzende, Rahmenbedingungen, technische Risiken.
• Das Team mitten im Projekt wechseln. Beide Methoden hängen an Menschen, die den Zusammenhang verstehen. Ein halbfertiges System an neue Entwickler:innen zu übergeben, ist der Anfang von Neuentwicklungen.
• Kein Übergabeplan. Unabhängig von der Methode sollten Sie am Ende Code, Dokumentation und Zugänge in der eigenen Hand haben.

Wie wir bei Ampersand arbeiten

Wir sind ein kleines Zürcher Studio und verkaufen keine Methode; wir passen sie dem Projekt an. Unsere Haltung ist einfach: Erfahrene Entwickler:innen führen jedes Projekt vom ersten Gespräch bis zur Übergabe. So vermeiden wir neu geschriebene Anforderungen, Personalwechsel mitten im Projekt und Abhängigkeitsfallen. Genau diese Kontinuität macht ein iteratives Vorgehen erst möglich, weil die Leute, die Ihr Geschäft in Sprint eins verstanden haben, in Sprint zehn noch da sind.

Wenn Sie eine Website, App, Plattform oder Beratung planen: Auf der Preisseite finden Sie unsere Formate, darunter Beratungspakete wie Guidance für 799 CHF pro Monat und laufende Betreuung wie Run & monitor für 750 CHF pro Monat. Wenn Sie unsicher sind, ob Ihr Projekt einen festen Rahmen, eine iterative Umsetzung oder eine Mischung braucht, starten Sie mit einem Gespräch über unsere Website, wir helfen Ihnen beim Zuschnitt.

Kurze Entscheidungscheckliste

Antworten Sie mit Ja oder Nein:

• Können Sie heute jede Anforderung aufschreiben, und bleiben sie gleich?
• Verlangt eine Aufsichtsbehörde oder ein Vertrag Freigaben pro Phase?
• Ist das Budget fix und nicht verhandelbar?

Drei Mal Ja spricht für den Wasserfall. Nun die andere Seite:

• Werden echte Nutzende verändern, was Sie bauen?
• Kann jemand aus Ihrem Team die Arbeit alle ein bis zwei Wochen prüfen?
• Würde ein frühes, teilweises Release Ihnen etwas Wertvolles zeigen?

Drei Mal Ja spricht für agil. Gemischte Antworten sprechen für eine Mischform: Rahmen fixieren, innerhalb davon iterieren.

Häufige Fragen

Ist agil heute noch relevant?

Ja. Agil ist für viele Softwareteams die übliche Arbeitsweise und entwickelt sich über Rahmenwerke wie Scrum und Kanban weiter. Der Kerngedanke, aus lauffähiger Software zu lernen und nachzujustieren, zählt umso mehr, je schneller sich Märkte bewegen. Die Kunst liegt darin, agil mit Disziplin anzuwenden statt als Ritual.

Ist agil eine Projektmanagement-Methode?

Streng genommen ist agil ein Satz von Werten und Prinzipien, und Rahmenwerke wie Scrum setzen diese in die Praxis um. Laut Scrum Alliance handelt es sich um einen Sammelbegriff und nicht um eine einzelne Methode. Teams steuern damit Projekte, doch der Begriff ist breiter als jeder einzelne Prozess.

Worin unterscheidet sich Scrum vom Wasserfall?

Scrum arbeitet in zeitlich begrenzten Sprints mit neu priorisiertem Backlog und einer Prüfung lauffähiger Software am Ende jedes Sprints. Der Wasserfall schliesst aufeinanderfolgende Phasen gegen einen zu Beginn definierten Umfang ab. Scrum rechnet mit Veränderung; der Wasserfall steuert sie formell.

Kann ich agil und Wasserfall kombinieren?

Ja, und viele Organisationen tun das. Ein häufiges Muster: Umfang und Budget vorab planen, iterativ umsetzen und mit einem formellen Release und einer Übergabe abschliessen. Am besten funktioniert das, wenn sich alle einig sind, welche Teile fix sind und welche sich ändern dürfen.

Was ist günstiger?

Von Natur aus ist keines von beiden günstiger. Der Wasserfall kann effizient sein, wenn der Umfang wirklich stabil ist, während späte Änderungen teuer werden. Agil verteilt die Kosten über die Umsetzung und erlaubt Ihnen, zu stoppen oder umzulenken, wenn Rückmeldungen das nahelegen. Am günstigsten ist der Ansatz, der zur Sicherheit Ihrer Anforderungen passt.

Quellen

• IBM describes it
• UNIL’s executive education team
• Wohlin and colleagues
• Scrum Alliance
• Rework’s methodology guide
• Deloitte Switzerland
• PMI Switzerland
• TechTarget
• classic Waterfall software introduction
• study presented at ICIS 2015
• reported on the same pattern
• HERMES