Agile vs Wasserfall — Methoden-Entscheidung für den Mittelstand 2026

Die Frage „Agile oder Wasserfall?“ ist im Jahr 2026 keine ideologische mehr, sondern eine wirtschaftliche. Mittelständische Unternehmen, die ein internes Tool, ein Kundenportal oder ein produktives SaaS bauen lassen, stehen vor einer Methoden-Entscheidung, die direkt über Budget-Sicherheit, Time-to-Market und das Verhältnis zum Dienstleister bestimmt. Wer pauschal „wir machen Agile“ einkauft, kann denselben Schaden anrichten wie jemand, der pauschal auf einen 200-seitigen Lasten-Hefte-Wasserfall setzt — beides ist Methoden-Fetisch ohne Bezug zur Projekt-Realität. Dieser Artikel ordnet die wichtigsten Methoden des Jahres 2026 für den deutschen Mittelstand ein: klassisches Wasserfall, Scrum, Kanban, Hybrid-Modelle, SAFe für skalierende Strukturen, Shape-Up als geräuscharme Alternative — und vor allem die Vertrags- und Tool-Realität, die jede Methode in der Praxis prägt. Für die Gesamteinordnung siehe unseren Leitfaden zur Softwareentwicklung im Mittelstand.

Methoden-Realität 2026 jenseits der Lehrbuch-Definitionen

Wer 2026 in mittelständischen IT-Projekten unterwegs ist, sieht selten reine Methoden. Die Lehrbuch-Beschreibungen von Scrum, Kanban oder Wasserfall existieren in Schulungs-Folien — in der gelebten Praxis arbeiten die meisten Teams in Mischformen, die historisch gewachsen sind, an Vertrags-Vorgaben angepasst und an die jeweilige Unternehmens-Kultur kalibriert wurden. Diese Realität ist nicht schlecht, sondern sinnvoll. Die Behauptung, ein Team „mache kein richtiges Scrum“, ist meistens ein Hinweis darauf, dass das Team pragmatisch geworden ist.

Drei Beobachtungen prägen die Methoden-Landschaft im deutschen Mittelstand. Erstens hat sich die ursprüngliche Polarität zwischen Wasserfall und Agile zu einem Spektrum von Hybrid-Modellen aufgelöst — fast jeder Auftrag enthält Phasen-Logik im Großen und iterative Sprints im Kleinen. Zweitens haben sich Vertrags-Modelle weiterentwickelt: Cap-and-Collar, Festpreis mit Change-Mechanismus und schlanke Time-and-Material-Verträge mit Sprint-Reviews sind realistische Alternativen zum klassischen Festpreis. Drittens ist die Tool-Unterstützung deutlich besser geworden — Linear, Jira, Notion und GitHub Projects bieten unabhängig von der gewählten Methode tragfähige Workflows.

Die wichtigste Frage ist nicht „welche Methode?“, sondern „welche Unsicherheit haben wir?“. Projekte mit klarem, stabilem Scope, externer Zertifizierungs-Pflicht oder vertraglich fixierten Endabnahmen profitieren von Phasen-Logik. Projekte mit unklaren Anforderungen, sich entwickelnden Kunden-Erwartungen oder explorativem Produkt-Charakter brauchen iteratives Lernen. Diese Trennung ist nüchterner als jede Methoden-Debatte.

Wasserfall — wann noch sinnvoll

Wasserfall ist nicht tot. Es ist sogar in bestimmten Konstellationen die rationalste Wahl. Die folgenden drei Szenarien sind die typischen Anwendungsfälle, in denen wir im Beratungs-Alltag des Jahres 2026 weiterhin zu einem klassischen Phasenmodell raten.

Regulierte Branchen mit Norm-Pflichten. Medizintechnik nach IEC 62304, Bahn-Software nach EN 50128, Luftfahrt nach DO-178C, Energie nach IEC 62443 — in all diesen Domänen verlangen die Normen lückenlose Nachvollziehbarkeit zwischen Anforderung, Design, Implementierung und Test. Iteratives Vorgehen ist nicht verboten, aber jede Iteration produziert komplette Dokumentations-Pakete, was den vermeintlichen Geschwindigkeits-Vorteil von Agile aufhebt. Ein gut geführtes Wasserfall-Projekt mit V-Modell-Anteilen ist hier wirtschaftlich oft überlegen.

Festpreis-Verträge mit Behörden und Konzern-Einkauf. EVB-IT-Verträge, VOB-Bau-IT-Schnittstellen, große Konzern-Beschaffungen mit detailliertem Pflichtenheft — diese Konstellationen verlangen eine fixierte Scope-Definition vor Vertrags-Unterschrift, weil die Abnahme an einer dokumentierten Leistungs-Beschreibung hängt. In diesen Fällen ist Wasserfall keine Methoden-Wahl, sondern eine Vertrags-Folge.

Klar definierte Scope-Projekte mit geringer Unsicherheit. Datenmigrationen zwischen zwei bekannten Systemen, Schnittstellen-Implementierungen nach veröffentlichter API-Spezifikation, Rebuild eines existierenden Tools mit identischer Funktion — wenn der Scope tatsächlich klar ist und Anforderungen sich nicht ändern werden, ist Wasserfall einfach das billigere Vorgehen. Es spart die Overhead-Kosten von Sprint-Plannings, Reviews und Retrospektiven, die in diesen Konstellationen wenig Mehrwert liefern.

Wichtig: Wasserfall scheitert nicht, weil es Wasserfall ist, sondern weil es in Projekten mit unklaren Anforderungen eingesetzt wird. Wer die genannten Voraussetzungen prüft und ehrlich feststellt, dass der Scope tatsächlich fix ist, kann mit einem Phasen-Modell schneller und günstiger ans Ziel kommen als mit Pseudo-Agilität.

Klassisches Agile — Scrum, Kanban, Scrumban

Agile Vorgehensweisen sind im Mittelstand inzwischen Standard, aber in unterschiedlichen Ausprägungen. Drei Varianten dominieren:

Scrum bleibt das bekannteste Framework — zweiwöchige Sprints, Daily-Standup, Sprint-Review, Retrospektive, definierte Rollen Product Owner, Scrum Master und Entwicklungs-Team. Scrum funktioniert gut, wenn ein verfügbarer Product Owner mit Entscheidungsbefugnis vorhanden ist, das Team zwischen fünf und neun Personen umfasst und Anforderungen sich tatsächlich entwickeln. Im deutschen Mittelstand scheitert Scrum häufig nicht am Framework, sondern an der fehlenden Product-Owner-Rolle — wenn Fachbereich und Geschäftsführung erst nach jedem Sprint-Review entscheiden, was als nächstes gebaut wird, fehlt der Kern-Mechanismus.

Kanban ist die schlankere Alternative — kontinuierlicher Fluss von Tickets durch ein Board mit definierten Spalten und Work-in-Progress-Limits, ohne fixe Sprint-Längen. Kanban passt zu Wartungs-Teams, Operations-nahen Entwicklungen und Bug-Fix-getriebenen Projekten. Im Mittelstand ist Kanban oft die ehrlichere Methode, weil sie das tatsächliche Arbeits-Muster vieler IT-Abteilungen widerspiegelt.

Scrumban ist die pragmatische Mischung: Kanban-Fluss als Grundlage, ergänzt um zweiwöchige Review- und Retrospektive-Termine. Diese Variante ist in unserem Beratungs-Alltag mit Abstand die häufigste empfohlene Form für mittelständische Teams mit fünf bis fünfzehn Personen, weil sie den Strukturen von Scrum die Lern-Schleifen abnimmt, ohne den Mehraufwand vollständiger Sprint-Plannings.

Hybrid — Wasserfall im Großen, Agile im Sprint-Detail

Die in mittelständischen Konstellationen häufigste reale Methodik ist das Hybrid-Modell: ein Wasserfall-artiger Rahmen mit drei bis fünf großen Phasen — Discovery, Architektur, Build, Rollout, Hyper-Care — und innerhalb jeder Build-Phase iterative Sprints mit Sprint-Reviews und kontinuierlichem Feedback. Dieses Modell hat sich in der Praxis bewährt, weil es zwei reale Bedürfnisse vereinbart: Vertrags-Sicherheit für die Geschäftsführung und Lern-Flexibilität für das Team.

Hybrid funktioniert gut bei Custom-Software-Projekten mit definiertem Liefer-Umfang, bei denen die genaue Ausgestaltung im Detail aber offen bleibt. Typische Beispiele sind interne Tools mit klarer Zielsetzung, Kundenportale, Mitarbeiter-Apps und produktiv eingesetzte Fachverfahren. Die Phasen-Logik gibt der Geschäftsführung Meilenstein-Sicherheit, die agilen Sprints geben dem Team Anpassungs-Raum.

Die Grenze des Hybrid-Modells liegt in der Phasen-Trennung selbst: wer Anforderungen tatsächlich erst im Sprint-Verlauf entdeckt, gerät an die Grenzen jeder Discovery-Phase, weil das Lernen weitergeht. Hybrid funktioniert dann gut, wenn die Discovery-Phase ehrlich Unsicherheiten benennt und Architektur und Build-Phase mit Reserven kalkuliert werden. Detaillierter zur Custom-Software-Logik siehe unseren Artikel zu Custom-Software vs Standard.

SAFe für größere Mittelständler

Das Scaled Agile Framework — SAFe — ist die populärste Methodik für skalierte agile Entwicklung mit mehreren parallel arbeitenden Teams. SAFe definiert mehrere Ebenen: Team-Ebene mit klassischem Scrum oder Kanban, Programm-Ebene mit Agile Release Trains und Program Increments, optional Portfolio-Ebene mit Lean-Portfolio-Management. Für mittelständische Unternehmen mit 50 bis 200 Entwicklern und mehreren Produkt-Teams ist SAFe ein ernsthaftes Werkzeug.

Wann SAFe sinnvoll ist: ab etwa drei bis vier parallel arbeitenden Teams mit gegenseitigen Abhängigkeiten, gemeinsamen Releases oder geteilten Komponenten. Die Program-Increment-Plannings — meist alle acht bis zwölf Wochen mit allen Teams gleichzeitig — schaffen die Abstimmung, die einzelne Teams sonst informell und schlecht skalierbar leisten würden. SAFe ist kein leichtgewichtiges Framework, es bringt Rollen wie Release Train Engineer, System Architect und Product Manager mit eigenem Mehraufwand. Wer diese Rollen nicht echt besetzen kann, sollte SAFe nicht starten.

Wann SAFe nicht sinnvoll ist: für einzelne Teams oder kleine Strukturen mit zwei Teams. Hier erzeugt SAFe Overhead, ohne echte Probleme zu lösen. Auch für Teams mit hoher Autonomie und wenig Inter-Team-Abhängigkeit ist SAFe oft überdimensioniert. Die häufige Beobachtung „SAFe funktioniert bei uns nicht“ ist meist die Folge eines fehlerhaften Skalierungs-Anlasses, nicht der Methode selbst.

Shape-Up als Alternative

Shape-Up ist die von Basecamp entwickelte Methode mit sechs-Wochen-Zyklen und einer dazwischen liegenden Cool-Down-Phase von zwei Wochen. Vor jedem Zyklus wird in einer Shaping-Phase ein grobes Lösungs-Bild entwickelt, das Risiken benennt und einen Appetit — also ein Zeitbudget — fixiert. Im Zyklus selbst arbeitet ein kleines Team von zwei bis drei Personen autonom an einer Wette, ohne tägliche Stand-ups oder Sprint-Plannings. Der Zyklus endet entweder mit Lieferung oder mit ehrlichem Abbruch.

Shape-Up passt gut zu mittelständischen Software-Produkten mit kleinen, erfahrenen Teams, internen Werkzeugen ohne externen Kunden-Druck und produktiven SaaS-Lösungen mit klarer Roadmap. Die Methode reduziert Koordinations-Overhead erheblich und vermeidet das Sprint-zu-Sprint-Treadmill-Gefühl, das Scrum-Teams oft entwickeln.

Shape-Up passt schlecht zu Auftrags-Entwicklung mit klassischen Kunden-Verträgen, weil die typische Vertrags-Logik mit Sprint-Reviews und kontinuierlicher Berichterstattung im Sechs-Wochen-Modell schwer abbildbar ist. Auch in Organisationen mit vielen Stakeholdern und hohem Abstimmungs-Bedarf scheitert Shape-Up häufig am fehlenden formellen Reporting-Rhythmus. Für interne Produkt-Teams im Mittelstand ist es dennoch eine ernsthafte Alternative, die wir in spezifischen Konstellationen empfehlen.

Festpreis vs Time-and-Material vs Cap+Collar

Die Methoden-Wahl ist eng mit der Vertrags-Form verknüpft. Drei Modelle dominieren im Mittelstand:

Vertrags-Modell	Wann sinnvoll	Risiko-Verteilung
Festpreis mit fixiertem Scope	Klare Anforderungen, geringe Unsicherheit, Behörden- und EVB-IT-Kontext	Dienstleister trägt Liefer-Risiko, Kunde trägt Scope-Klarheits-Risiko
Time-and-Material mit Sprint-Reviews	Explorative Projekte, Produkt-Entwicklung, hohe Unsicherheit	Kunde trägt Aufwand-Risiko, Dienstleister liefert kontinuierlich
Cap-and-Collar mit Change-Mechanismus	Mittelweg — Budget-Obergrenze bei flexiblem Scope	Gemeinsam getragen, Priorisierung als Steuer-Hebel
Festpreis pro Sprint oder Inkrement	Mehrere unabhängige Liefer-Pakete, modulare Architektur	Risiko pro Inkrement isoliert, gut planbar

Aus unserer Praxis: das Cap-and-Collar-Modell hat sich für mittelständische Kunden mit Custom-Software-Bedarf als robusteste Lösung erwiesen. Die Geschäftsführung erhält eine harte Budget-Obergrenze, das Team behält Flexibilität im Detail-Scope, und die Priorisierung in Must-have, Should-have und Could-have wird zum gemeinsamen Steuer-Werkzeug. Reine Festpreis-Verträge funktionieren nur, wenn der Scope wirklich vor Vertrags-Beginn klar ist — was seltener der Fall ist, als die Vertrags-Verhandlung suggeriert.

Tools — Linear, Jira, Notion, Productboard, GitHub Projects

Die Tool-Frage ist methodisch oft weniger entscheidend als angenommen — alle relevanten Plattformen unterstützen die gängigen Methoden in irgendeiner Form. Wichtiger ist die kulturelle Passung und die bestehende Tool-Landschaft. Eine kurze Einordnung:

• LinearSchnellstes Tool für Entwickler-zentrierte Teams, sehr gute Tastatur-Bedienung und API. Passt gut zu kleinen produkt-getriebenen Teams. Weniger geeignet für Enterprise-Reporting und Multi-Projekt-Portfolio.
• JiraEtabliert in größeren Mittelständlern, breite Plugin-Landschaft, gute SAFe-Unterstützung. Wird oft schwerfällig, wenn zu viele Felder und Workflows konfiguriert sind. Solide Wahl für Hybrid und SAFe.
• NotionEher Dokumentations-Werkzeug mit Task-Funktionen, weniger ein echtes Projektmanagement-Tool. Gut für leichtgewichtige Teams und Discovery-Phasen, weniger für laufenden Sprint-Betrieb mit vielen Tickets.
• ProductboardSpezialisiert auf Produkt-Roadmap und Feature-Priorisierung. Sinnvoll als Ergänzung zu einem Entwickler-Tool, nicht als alleinige Lösung.
• GitHub ProjectsGut integriert in Git-Workflows, einfach zu konfigurieren, kostengünstig. Passt für entwickler-nahe Teams ohne komplexes Multi-Stakeholder-Reporting.

Anti-Patterns — Cargo-Cult-Scrum und Agile-by-Name-only

In jeder Methoden-Debatte gibt es typische Fehlgriffe, die wir im Mittelstand regelmäßig sehen. Vier Anti-Patterns sind besonders verbreitet:

Cargo-Cult-Scrum. Das Team führt Daily-Standups, Sprint-Plannings und Retrospektiven durch, ohne dass sich an Entscheidungs-Wegen oder Anforderungs-Flexibilität etwas ändert. Anforderungen werden weiterhin per Lasten-Heft im Voraus fixiert, der Product Owner hat keine Entscheidungsbefugnis, Sprint-Reviews dienen als Statusberichts-Termin statt als Anpassungs-Punkt. Resultat: agiles Vokabular auf einem Wasserfall-Skelett, mit dem schlechtesten beider Welten.

Agile-by-Name-only. Der Vertrag deklariert agiles Vorgehen, der Pflichtenheft-Anhang fixiert dennoch jede Funktion im Detail mit Abnahme-Kriterien. Im Konflikt-Fall greift das Pflichtenheft, Sprint-Reviews sind Theater. Mitarbeitende lernen schnell, dass die Methoden-Rhetorik nicht ernst gemeint ist.

SAFe ohne Skalierungs-Anlass. Ein Unternehmen mit zwei oder drei Teams führt SAFe ein, weil ein Berater es empfohlen hat. Die zusätzlichen Rollen — Release Train Engineer, System Architect — werden mit Doppel-Funktionen besetzt, das Program-Increment-Planning wird zur teuren Pflicht-Übung ohne Nutzen.

Shape-Up im falschen Kontext. Eine Auftrags-Entwicklung mit klassischem Kundenvertrag wird auf Shape-Up umgestellt, weil das Team es interessant findet. Der Kunde erwartet weiterhin Sprint-Reviews und Status-Reports, die Methode passt nicht zur Vertrags-Realität, Reibung entsteht.

Allen vier Anti-Patterns ist gemeinsam, dass die Methode kopiert wird, ohne ihren Mechanismus zu verstehen. Methoden lösen spezifische Probleme — wer diese Probleme nicht hat, braucht die Methode nicht.

Reepa-Empfehlung pro Projekttyp

Nach mehreren Jahren mittelständischer Entwicklungs-Projekte haben wir eine pragmatische Heuristik entwickelt, die als Ausgangspunkt für die meisten Konstellationen tragfähig ist:

• Migrations- und Schnittstellen-ProjekteKlassisches Phasenmodell mit Festpreis, klar definierten Liefer-Paketen und linearer Abnahme. Methoden-Overhead nicht nötig.
• Custom-Software für interne Tools (3-9 Monate)Hybrid mit Discovery-Phase, Cap-and-Collar-Vertrag und zweiwöchigen Sprints im Build. Geschäftsführungs-Sicherheit plus Team-Flexibilität.
• MVP-Entwicklung und Produkt-AufbauTime-and-Material oder Cap-and-Collar mit Scrumban-Rhythmus, klarer Priorisierung und kurzen Lern-Schleifen. Siehe auch unseren Artikel MVP in 90 Tagen.
• SaaS-Produktentwicklung im laufenden BetriebShape-Up mit Sechs-Wochen-Zyklen für kleine, erfahrene Teams oder Scrumban für größere Strukturen. Roadmap als Priorisierungs-Anker.
• Skalierte Mehr-Team-Strukturen (3+ Teams)Leichtgewichtiges SAFe oder eigenes Skalierungs-Modell mit Program-Increment-Logik. Quartalsweise Synchronisation.
• Regulierte Domänen mit Norm-PflichtenV-Modell oder Wasserfall mit Iterations-Schleifen innerhalb der Phasen. Nachvollziehbarkeit hat Vorrang vor Geschwindigkeit.

Diese Heuristik ersetzt keine Einzelfall-Analyse — Teamgröße, Vertrags-Kontext, Stakeholder-Landschaft und bestehende Tool-Landschaft müssen berücksichtigt werden. Sie zeigt aber, dass für die meisten Mittelstands-Konstellationen weniger als zehn Standard-Antworten existieren. Wer den eigenen Projekttyp ehrlich einordnet, kommt mit überschaubarem Methoden-Vokabular sehr weit. Für die ergänzende Frage, ob Inhouse oder externer Partner besser passt, siehe auch Nearshore, Offshore oder Inhouse.

Häufige Fragen