"Agile Waterfall: Die Sprache von Agile ohne die Autorität, agil zu sein"

April 2026 12 min Lesezeit Meinung

Es gibt eine Kategorie organisationaler Zustände, die keinen sauberen Namen hat, aber die die meisten Agile-Praktiker regelmäßig antreffen. Die Organisation führt Sprints durch. Sie hat Scrum Master und Product Owner. Sie spricht über Wertlieferung, empirischen Prozess und iterative Entwicklung. Sie hat Agile an der Wand und im Organigramm. Und sie trifft Entscheidungen so wie sie es immer getan hat: hierarchisch, langsam und basierend auf Vorabplänen, die existieren, bevor irgendeine Arbeit beginnt.

Nenn es Agile Waterfall. Das Vokabular ist Agile. Die Autoritätsstruktur ist es nicht.

---

Der Hook: Die teuerste Art der Transformation

Echte Agile Transformation ist schwierig und teuer. Sie erfordert die Veränderung nicht nur von Prozessen, sondern von Entscheidungsstrukturen, Autoritätsverteilungen und organisationalen Erwartungen darüber, wie Arbeit geschieht. Viele Organisationen wollen die Ergebnisse von Agile ohne die strukturellen Veränderungen, die diese Ergebnisse ermöglichen.

Das Ergebnis ist Agile Waterfall: eine Transformation, die den Vokabularerwerb abschließt, aber vor dem Autoritätstransfer haltmacht. Die Zeremonien existieren. Die Rollen existieren. Die Sprache ist korrekt. Aber der Product Owner kann den Backlog nicht neu priorisieren ohne eine Change Advisory Board-Genehmigung. Das Scrum-Team kann keine Architekturentscheidungen treffen ohne den Architecture Review Board zu durchlaufen. Das Team kann sich nicht auf einen Sprint-Scope festlegen, ohne dass der Projektmanager ihn gegen den ursprünglichen Projektplan validiert.

Keine dieser Autoritätsbeschränkungen ist mit Agile kompatibel. Alle sind Merkmale der Waterfall-Governance, die die Transformation überlebt haben, weil ihre Änderung politisch zu schwierig war. Die Organisation hat die Sprache von Agile und die Struktur von Waterfall behalten. Das ist keine teilweise Transformation. Es ist eine teure Farce.

---

Die Realität: Wo die Autoritätslücken liegen

Agile Waterfall ist nicht zufällig. Die Autoritätslücken konzentrieren sich an vorhersehbaren Stellen.

Der Product Owner, der nicht besitzen kann

Die Product Owner-Rolle, wie im Scrum Guide definiert, erfordert echte Autorität, den Backlog zu managen und Kompromissentscheidungen über die Produktrichtung zu treffen. In den meisten Organisationen, die Scrum eingeführt haben, ist diese Autorität auf mehrere Stakeholder, Genehmigungsprozesse und Lenkungsausschüsse aufgeteilt.

Der Product Owner ist in diesen Organisationen eine Facilitierungs- statt einer Entscheidungsrolle. Er sammelt Anforderungen, kommuniziert zwischen dem Entwicklungsteam und dem Unternehmen und repräsentiert Backlog-Items bei Zeremonien. Was er nicht tut, ist autoritative Entscheidungen darüber zu treffen, was das Produkt als nächstes tun soll. Diese Entscheidungen gehen an ein Komitee, an einen Projektlenkungsausschuss, an einen Senior Stakeholder, der in die Scrum-Adoption nicht einbezogen wurde.

Der Sprint, der kein Sprint ist

Ein Sprint ist in Scrum ein Event, in dem das Team sich zu einem Sprint-Ziel verpflichtet und die notwendigen Entscheidungen trifft, um es zu erreichen. In Agile Waterfall ist der Sprint ein zweiwöchiges Segment eines bereits existierenden Projektplans. Der Scope wurde vor Sprintbeginn im Projektplan festgelegt, der vor Entwicklungsbeginn genehmigt wurde. Das Team verpflichtet sich nicht zu einem Sprint-Ziel – sie verpflichten sich, die Items zu liefern, die der Projektplan für diesen Sprint vorsieht.

Das ist keine iterative Entwicklung. Es ist Waterfall-Entwicklung, die in zweiwöchige Chargen segmentiert und umbenannt wurde.

Die Architektur, die nicht verändert werden kann

Technische Entscheidungen erfordern in vielen Organisationen Architekturüberprüfungsprozesse, die auf einem anderen Zeitmaßstab als Agile-Entwicklung arbeiten. Eine architektonische Entscheidung, die aus der Sprint-Arbeit entsteht, erfordert einen formalen Überprüfungsprozess, der Wochen oder Monate dauert.

Das Team kann nicht auf das reagieren, was es lernt, weil die Governance-Struktur für technische Entscheidungen für eine Welt konzipiert wurde, in der Entscheidungen einmal zu Beginn von Projekten getroffen und ohne Überarbeitung implementiert wurden.

---

Die Checksum: Wie echte Autorität aussieht

Der Unterschied zwischen Agile und Agile Waterfall ist nicht Vokabular oder Zeremonie. Es ist, wo die Autorität, Entscheidungen über Arbeit zu treffen, tatsächlich liegt.

Echte agile Entwicklung erfordert Autorität auf drei Ebenen: Produktautorität (was gebaut werden soll), Prozessautorität (wie das Team arbeitet) und technische Autorität (wie das Produkt gebaut wird). In echtem Agile werden alle drei nahe an der Arbeit gehalten – durch den Product Owner, durch das Team und durch die Entwickler.

“Agile Waterfall ist das Ergebnis, wenn eine Organisation die Produktivität dezentralisierter Entscheidungsfindung will und die Kontrolle zentralisierter Entscheidungsfindung behält. Man kann nicht beides haben. Man bekommt keines von beiden.” Markus – agile-checksum.com

Das Autoritäts-Audit

Der einfachste Test für Agile Waterfall ist das Autoritäts-Audit. Identifiziere für jede der folgenden Entscheidungen, wer tatsächlich die Autorität hat, sie zu treffen:

1. Kann der Product Owner eine geplante Funktion ohne Eskalation aus dem Sprint entfernen?
2. Kann das Team seinen technischen Ansatz mitten im Sprint basierend auf neuen Informationen ändern?
3. Kann ein Entwickler die Implementierung von etwas ablehnen, das seiner Meinung nach erhebliche technische Schulden verursacht?
4. Kann der Scrum Master eine Zeremonie absagen, die keinen Wert erzeugt?
5. Kann das Team während eines Sprints zusätzlichen Scope von einem Stakeholder ablehnen?

Wenn die Antwort auf die meisten dieser Fragen “es hängt von der Genehmigung ab” oder “sie müssten das Management fragen” lautet, betreibt die Organisation Agile Waterfall.

---

Fallstudien aus der Praxis

Der Genehmigungs-Sprint

Eine Finanzdienstleistungsorganisation hatte Scrum in ihrer Technologieabteilung eingeführt. Jedes Team führte zweiwöchige Sprints mit allen Standardzeremonien durch. Als ich den Entscheidungsfluss für eine typische Produktänderung untersuchte, fand ich eine Governance-Schicht, die in der Agile-Adoptionsdokumentation vollständig unsichtbar war. Jede Änderung, die eine kundenseitige Funktion betrifft, erforderte die Genehmigung eines Change Advisory Boards, das sich zweiwöchentlich traf. Jede architektonische Änderung erforderte eine Architecture Review Board-Einreichung mit vier Wochen Vorlaufzeit.

Die Teams führten Agile-Zeremonien im Zwei-Wochen-Takt durch und trafen Entscheidungen in einem Vier-bis-Acht-Wochen-Governance-Zyklus.

Der Projektmanager unter anderem Titel

Ein Technologieunternehmen hatte vor drei Jahren zu Agile gewechselt. Die Rolle des Projektmanagers war in Product Owner umbenannt worden. Die Verantwortlichkeiten hatten sich nicht geändert. Als ich eine der Product Owner bat, ihre letzte Backlog-Neuprioritisierungsentscheidung zu beschreiben, beschrieb sie einen Prozess mit drei Stakeholder-Konsultationen, einer Business-Case-Aktualisierung, einer Lenkungsausschuss-Präsentation und einem zweiwöchigen Genehmigungszyklus. Die Neuprioritisierung war unkompliziert und wertvoll gewesen. Der Prozess hatte sechs Wochen gedauert.

---

Das Takeaway: Das Vokabular ist nicht die Transformation

Agile Vokabular zu übernehmen und gleichzeitig Waterfall-Autoritätsstrukturen beizubehalten, erzeugt ein teures und demoralisierendes Ergebnis.

Führe die Checksum für deine Transformation durch:

1. Wann hat dein Product Owner zuletzt eine bedeutende Produktentscheidung ohne Genehmigungsprozess getroffen? Wie lange hat es gedauert?
2. Wie lange dauert es von der Identifizierung eines technischen Problems durch das Team bis zur Autorität, es zu lösen?
3. Wenn du das Agile-Vokabular aus deiner Organisation entfernen würdest – die Sprints, die Zeremonien, die Rollennamen – wäre das tatsächliche Entscheidungsverhalten erkennbar anders als vor der Transformation?

Die Antwort auf die dritte Frage sagt dir alles.

---

Im Artikel verwendete Glossarbegriffe

• Agile Transformation – Der Prozess, durch den eine Organisation versucht, Agile-Werte und -Praktiken im gesamten Unternehmen einzuführen.
• Product Owner – Die Scrum-Verantwortlichkeit für die Maximierung des Produktwerts.
• Backlog – Eine geordnete Liste von allem, was im Produkt getan werden könnte.
• Technische Schulden – Die impliziten Kosten für Nacharbeit, die durch die Wahl einer pragmatischen Lösung über einen besseren Ansatz entstehen.
• Sprint – Ein Scrum-Event mit festem Zeitraum, in dem ein nutzbarer Produktzuwachs erstellt wird.