Scrum Is Dead — aber woran
ist es wirklich gestorben?
Amazon, Google, Netflix verabschieden sich von Scrum. Die Branche feiert den Tod des Frameworks. Aber die eigentliche Frage stellt niemand.
Es ist offiziell: Scrum ist tot. Zumindest wenn man den Schlagzeilen glaubt.
Amazon hat es aufgegeben. Google-Ingenieure sprechen von einer „Religion, die Reports über zukünftige Großartigkeit produziert statt großartige Software". Netflix und Microsoft experimentieren mit Kanban, OKRs und teamautonomen Modellen.
Die Anklageschrift liest sich überzeugend:
- Meeting-Overhead: Dailys, Sprint Planning, Retros, Grooming — ein voller Arbeitstag pro Woche für Rituale statt für Code. (Wer je ein dysfunktionales Daily erlebt hat, weiß genau, wovon ich rede.)
- Korrumpierte Metriken: Story Points, erfunden als Planungshilfe, mutiert zum Performance-Pranger. Teams blähen Punkte auf, um produktiv auszusehen.
- Skalierungskollaps: Was für sieben Leute funktioniert, kollabiert bei fünfzig Teams. Sprint-Synchronisation wird zum Vollzeitjob.
- Innovationsfeindlichkeit: Starre Zwei-Wochen-Zyklen ersticken spontane Kreativität. Gmail entstand in Googles 20%-Zeit. Nicht in Sprint 47.
Das sind reale Probleme. Aber sie erzählen nur die halbe Geschichte.
Die Todesursache, die niemand ausspricht
Scrum ist nicht an seinen Ritualen gestorben. Es ist daran gestorben, dass Organisationen es als Tool-Set behandelt haben — als Paket aus Zeremonien, Rollen und Artefakten, das man „einführt" wie eine neue Software.
Jira-Board aufsetzen. Scrum Master einstellen. Sprint-Takt konfigurieren. Fertig. Wir sind jetzt agil.
Nur: Agilität war nie ein Tool-Set. Die vier Werte des Agilen Manifests — Individuen über Prozesse, funktionierende Software über Dokumentation, Zusammenarbeit über Verträge, Reagieren auf Veränderung über Planverfolgung — das sind Mind-Set-Aussagen. Jede einzelne beschreibt eine Haltung. Keine Methode.
Was die meisten Organisationen getan haben, ist das Äquivalent davon, einem Kind eine Stradivari zu kaufen und sich zu wundern, warum es nicht Beethoven spielt.
Das Instrument ist da (Tool-Set). Aber wo sind Übung und Technik (Skill-Set)? Und wo ist das Verständnis dafür, was Musik überhaupt bedeutet (Mind-Set)?
Warum es scheitert: Das Drittel-Problem
Die 3-Sets-Methode\u2122 identifiziert drei Dimensionen, die bei jeder Veränderung zusammenwirken müssen: Tool-Set (Werkzeuge, Strukturen, Prozesse), Skill-Set (Fähigkeiten, Techniken, Wissen) und Mind-Set (Überzeugungen, Annahmen, mentale Modelle).
Dein Ergebnis ist gedeckelt durch dein schwächstes Set:
Das schwächste Set deckelt das Ergebnis
Liebigs Minimumgesetz als Richtungshinweis: Tool 5, Skill 5, Mind 2 (1-5-Skala) → Ergebnis hängt am Niveau 2. Brillanz im stärksten Set hebt den Deckel nicht. Heuristik, keine Formel.
Genau das passiert bei den meisten Scrum-Einführungen. Ich nenne es den Cargo-Cult der Agilität:
Diagnose: Cargo-Cult Scrum
Tool-Set: komplett
Jira, Confluence, Sprint-Board, Definition of Done, Burndown Charts — alles da, alles konfiguriert.
Skill-Set: oberflächlich
Teams kennen die Scrum-Theorie. Die Praxis von Selbstorganisation, empirischem Arbeiten und echtem Feedback? Nie trainiert.
Mind-Set: unberührt
Kontrolle statt Vertrauen. Fehler als Versagen. Velocity als KPI statt als Planungshilfe. Die Kultur hat sich keinen Millimeter bewegt.
Das Ergebnis? Vorhersehbar. Dailys werden zu Status-Reports für das Management. Retrospektiven können nicht ehrlich sein, weil Fehler bestraft werden. Velocity wird manipuliert, weil sie als Leistungsmessung missbraucht wird.
Die Rituale laufen. Aber sie sind hohl. Scrum als mechanisches Theater.
Was Big Tech wirklich tut (und warum es bei Ihnen nicht funktionieren wird)
Die Alternativen, die Amazon, Spotify und Co. einsetzen, sind aufschlussreich — aber nicht aus den Gründen, die die LinkedIn-Schlagzeilen suggerieren.
Shape Up (Basecamp): Sechs Wochen statt zwei. Klingt nach einem Tool-Set-Tausch. Ist es nicht. Der Kern ist Problem Shaping vor Execution — sicherstellen, dass das Team das Problem versteht, bevor es Lösungen baut. Das ist eine Mind-Set-Intervention.
Spotify-Modell: Squads wählen ihren eigenen Prozess. Das funktioniert nur in einer Kultur, die Vertrauen und Eigenverantwortung lebt — nicht auf Poster druckt. Die Ironie: Spotify selbst hat das „Spotify-Modell" inzwischen hinter sich gelassen. Ihre Kultur reifte — und der Prozess entwickelte sich mit ihr.
OKRs (Google): Outcome statt Output. Klingt großartig. Aber OKRs in einer kontrollorientierten Kultur werden genauso zu Performanz-Theater wie Story Points. Das Tool ändert sich. Die Dysfunktion bleibt.
Keine dieser Alternativen ist ein reines Tool-Set. Sie alle setzen ein bestimmtes Mind-Set voraus. Der Unterschied: Die Unternehmen, bei denen sie funktionieren, haben dieses Mind-Set bereits — oft durch jahrelange kulturelle Arbeit.
Sie wechseln nicht das Framework. Sie haben eine Kultur, in der verschiedene Frameworks funktionieren können. Das ist der einzige Unterschied, der zählt.
Fünf Wege, an agiler Transformation zu scheitern
- Cargo-Cult-Agilität. Tool-Set ohne Mind-Set. Die Rituale laufen, die Kultur bleibt Command-and-Control. Der häufigste Fall.
- Insel-Agilität. Agile Teams in einer nicht-agilen Organisation. Die Teams sind frustriert, weil ihre Umgebung jede Veränderung abwürgt.
- Speed-Agilität. Agilität mit Beschleunigung verwechseln. „Wir sind agil" bedeutet „wir liefern schneller" — nicht „wir lernen schneller". Ein gefährlicher Irrtum.
- Methoden-Dogma. Ein Framework für alles. SAFe fürs Startup, Scrum für den Betrieb, LeSS für die Forschung — alle gleich behandelt, keins passend.
- Bottom-Up ohne Top-Down. Teams werden agil geschult, das Management nicht. Ergebnis: agile Teams, die in nicht-agilen Strukturen ersticken.
Der Ausweg: Diagnose statt Framework-Hopping
Die Lösung ist nicht, Scrum durch das nächste Framework zu ersetzen. Das wäre derselbe Fehler in neuem Gewand — ein Tool-Set-Tausch, der das eigentliche Problem ignoriert.
Die Lösung ist eine ehrliche Diagnose: Welches Set ist der tatsächliche Engpass?
In meiner Erfahrung aus der Arbeit mit Organisationen über mehr als 20 Jahre in der IT ist der Engpass fast immer das Mind-Set — in etwa acht von zehn Fällen. Organisationen haben die Tools. Sie haben (zumindest grundlegende) Skills. Was ihnen fehlt:
Psychologische Sicherheit
Die Überzeugung, dass Fehler nicht bestraft werden. Ohne sie ist jede Retrospektive eine Farce.
Echte Autonomie
Nicht „ihr dürft entscheiden" mit dem Kleingedruckten „solange wir einverstanden sind".
Outcome-Denken
Erfolg messen an dem, was beim Kunden ankommt — nicht an der Geschwindigkeit der internen Maschinerie.
Double-Loop Learning
Nicht nur „machen wir es richtig?" — sondern „machen wir das Richtige?"
Raus aus dem Scrum-Friedhof
Wenn Ihre Organisation in dysfunktionalem Scrum feststeckt, ist der erste Schritt nicht ein Framework-Wechsel. Der erste Schritt ist eine Diagnose mit dem 3-Sets-Inventar (3SI): 24 Fragen, fünf Minuten, drei Dimensionen.
Das Ergebnis sagt nicht „Scrum ist schuld" oder „Sie brauchen SAFe". Es zeigt, welches Drittel Sie systematisch vernachlässigen. Und damit, wo die Intervention tatsächlich ansetzen muss.
Das Fazit, das niemand hören will
Scrum ist nicht tot. Scrum wurde in den meisten Organisationen nie wirklich lebendig.
Was gestorben ist, ist die Illusion, dass man Agilität einführen kann wie ein ERP-System — mit Projektplan, Rollout-Datum und Schulung für alle.
Die Unternehmen, die Scrum jetzt begraben, begraben ihren eigenen gescheiterten Versuch, eine kulturelle Transformation als Tool-Set-Upgrade zu behandeln.
Und wenn sie Shape Up, Kanban oder OKRs mit derselben Haltung einführen, werden sie in drei Jahren einen neuen Artikel schreiben:
„Shape Up Is Dead — Why Big Tech Is Ditching It."
Das Problem war nie das Framework. Das Problem ist das Drittel, das Sie nicht sehen wollen.
Die gute Nachricht: Sobald Sie das richtige Drittel identifiziert haben, wird der Weg nach vorne klar — und oft einfacher als eine weitere Framework-Migration.
Welches Drittel bremst Ihre Organisation?
Das 3-Sets-Inventar zeigt in fünf Minuten, wo der Engpass liegt — und was Sie als Erstes ändern sollten.
Diagnose starten