Scrum ist in vielen Unternehmen angekommen – als Standard, als Versprechen, als Hoffnungsträger. Und trotzdem erleben viele von Ihnen eine irritierende Diskrepanz: Die Rituale laufen, die Rollen sind benannt, die Termine stehen. Aber Wirkung entsteht zu selten. Statt schneller Lernschleifen gibt es Meeting-Routine. Statt echten Produktfortschritt gibt es Aktivität. Und statt Klarheit entsteht häufig das Gefühl: „Wir machen Scrum – aber es fühlt sich nicht lebendig an.“
Genau dafür gibt es ein drastisches, aber hilfreiches Bild: Zombie Scrum. Scrum sieht von außen intakt aus – aber das, was es eigentlich leisten soll, bleibt aus. Heute geht es darum, woran Sie Zombie Scrum erkennen, warum es so hartnäckig entsteht – und wie Sie darüber sprechen können, ohne in Schuldzuweisungen oder Methodenstreit zu geraten.
Dazu spreche ich heute mit Johannes Schartau. Johannes hat vor einigen Jahren den Zombie Scrum Survival Guide auf Englisch mitveröffentlicht – und wir haben damals schon einmal über Zombie Scrum gesprochen. Jetzt ist das Buch auf Deutsch erschienen, inklusive zusätzlicher Experimente in der deutschen Ausgabe. Das ist ein guter Anlass, neu draufzuschauen: Was hat sich in Organisationen verändert – und welche Muster sind erstaunlich stabil geblieben?
Viele Spaß beim Reinhören!
Hat Ihnen die Reihe gefallen? Dann abonnieren Sie unseren Podcast und holen Sie sich weiterhin wertvolles Praxiswissen direkt auf die Ohren!
⭐ ⭐ ⭐ ⭐ ⭐
Und noch eine Bitte zum Schluss: Wir freuen uns, wenn Sie unseren Podcast mit 5 Sternen Bewerten und in Ihrem Netzwerk weiterempfehlen. Vielen Dank!
Tina Ciotola
Mit Johannes Schartau
Johannes Schartau ist Berater, Trainer und Coach für agile Produkt- und Organisationsentwicklung bei Holisticon in Hamburg. Ihn interessiert, wie agiles Arbeiten über alle Rollen und Ebenen hinweg nachhaltig gelingen kann. Mit Liberating Structures, integraler und Komplexitätstheorie, sowie Humor und Empathie schafft er Räume für Gruppen, in denen sie selber wirksam werden können.
Hier geht es zum LinkedIn-Profil:
linkedin.com/in/johannes-schartau
Sprungmarken
Relevante Links
Alte Folge zur englischen Ausgabe (Feb 2021): https://www.theprojectgroup.com/podcast-projektmanagement/zombie-scrum/
Podcast-Zusammenfassung: #163 Zombie Scrum verstehen: Symptome, Ursachen und Ansatzpunkte für Veränderung
Zombie Scrum: Wenn Agilität nur noch wie Agilität aussieht
Im Gespräch mit Johannes Schartau geht es um ein Phänomen, das viele Organisationen nur zu gut kennen: Scrum ist eingeführt, die Rollen sind benannt, die Meetings finden statt, und trotzdem bleibt die eigentliche Wirkung aus. Von außen wirkt alles intakt. Im Inneren fehlt jedoch oft genau das, was Scrum lebendig machen soll: Lernen, Anpassung und echter Fortschritt.
Gerade darin liegt die Schärfe des Begriffs Zombie Scrum. Er beschreibt keinen bösen Willen und keine unfähigen Teams. Er beschreibt ein System, das sich weiterbewegt, aber kaum noch auf seine Umwelt reagiert. Rituale laufen weiter, obwohl sie ihren Zweck verloren haben. Produktinkremente entstehen, ohne echte Erkenntnisse zu liefern. Retrospektiven finden statt, ohne dass sich an den Bedingungen der Zusammenarbeit etwas ändert.
Das macht das Thema so relevant. Die Schwierigkeiten beginnen meist nicht erst dann, wenn Scrum sichtbar scheitert. Sie beginnen viel früher, etwa dann,
- wenn Teams Aktivität mit Fortschritt verwechseln,
- wenn Fachbereiche als Stellvertreter für Kunden auftreten,
- wenn Planungssicherheit verlangt wird, obwohl das Umfeld längst dynamischer geworden ist.
Genau in dieser Spannung wächst Zombie Scrum.
Scrum ist kein Selbstzweck, sondern ein Mittel für komplexe Probleme
Der zentrale Gedanke ist überraschend schlicht: Scrum ist nicht dafür da, möglichst viele Meetings sauber durchzuführen. Scrum ist dafür da, in unsicheren und dynamischen Umfeldern handlungsfähig zu bleiben. Der eigentliche Zweck liegt darin, mit Komplexität umzugehen, Informationen schnell zu erzeugen und die nächsten Schritte auf Basis von Realität statt auf Basis von Annahmen zu wählen.
Genau an diesem Punkt kippt die Praxis jedoch häufig. In vielen Organisationen wird Scrum eingeführt, ohne die Ausgangsfrage sauber zu klären: Welches Problem soll dieser Ansatz hier eigentlich lösen? Statt diese Frage ernsthaft zu bearbeiten, übernimmt man ein Vorgehensmodell, weil es modern wirkt, weil andere es auch tun oder weil es als Standard verkauft wurde. Damit fehlt von Anfang an die Verbindung zwischen Methode und Zweck.
Die Folge ist gravierend. Wenn unklar bleibt, warum Scrum überhaupt eingesetzt wird, konzentriert sich die Arbeit fast automatisch auf die äußere Form:
- Events werden eingehalten,
- Rollen formal besetzt,
- Artefakte gepflegt.
Aber all das geschieht losgelöst von der Frage, ob das Team dadurch tatsächlich besser mit Unsicherheit umgehen kann. Scrum wird dann zu einem Prozess, den man befolgt, nicht zu einem Rahmen, der Orientierung in komplexen Situationen gibt.
Tipp: Stelle zu Beginn jeder Scrum-Initiative nicht die Frage „Wie führen wir Scrum ein?“, sondern „Welches komplexe Problem wollen wir damit besser lösen?“
Der eigentliche Wert liegt in Information, nicht in Beschäftigung
Ein entscheidender Gedanke lautet: In komplexen Umfeldern ist Information besonders wertvoll. Wer nicht verlässlich vorhersagen kann, was funktionieren wird, muss schnell lernen. Genau deshalb steht im Zentrum von Scrum nicht die perfekte Vorabplanung, sondern das möglichst frühe Erzeugen von verwertbaren Erkenntnissen.
Das Produktinkrement ist dabei mehr als ein Arbeitsergebnis. Es ist ein Mittel, um Realität sichtbar zu machen. Erst wenn etwas Greifbares entsteht, das möglichst nah an der tatsächlichen Nutzung liegt, wird erkennbar, ob eine Annahme trägt oder nicht. Ohne diese Nähe zur Realität bleibt jedes Review harmlos. Dann wird über geleistete Arbeit gesprochen, aber nicht über Wirkung.
Viele Organisationen optimieren jedoch weiterhin auf Planerfüllung statt auf Erkenntnisgewinn. Dann zählt vor allem, ob spezifizierte Anforderungen rechtzeitig geliefert wurden. Ob diese Anforderungen richtig waren, rückt in den Hintergrund. Damit entsteht ein fundamentales Missverständnis: Man verwechselt das Abarbeiten eines Plans mit dem Lösen eines Problems.
Besonders sichtbar wird das, wenn Reviews vor allem diese Fragen beantworten:
- Ist alles fertig geworden?
- Wurde der Plan eingehalten?
- Sind die zugesagten Features umgesetzt?
Viel seltener geht es um die eigentlich wichtigere Frage: Was haben wir dadurch gelernt?
Tipp: Prüfe im Review nicht zuerst, was fertig geworden ist, sondern welche neue Information durch das Inkrement entstanden ist.
Wo Zombie Scrum entsteht: im Widerspruch zwischen Anpassung und Planlogik
Zombie Scrum entsteht selten durch einzelne Fehler im Team. Häufiger wächst es aus einem Widerspruch im Gesamtsystem. Einerseits sollen Teams flexibel, lernfähig und anpassungsbereit arbeiten. Andererseits verlangt das Umfeld weiterhin exakte Vorhersagen, feste Funktionszusagen und sichere Liefertermine. Beides gleichzeitig einzufordern, überfordert das System.
Dieser Konflikt zeigt sich besonders deutlich dort, wo Unsicherheit offiziell anerkannt, praktisch aber nicht akzeptiert wird. Dann sollen Product Owner so tun, als könnten sie bereits im Vorfeld genau wissen, was Kunden brauchen. Teams sollen iterativ arbeiten, aber ihre Sprints für Monate oder sogar Jahre vorplanen. Retrospektiven sollen Verbesserungen ermöglichen, ohne dass an Strukturen, Budgets oder Verantwortlichkeiten gerührt werden darf.
So entsteht die typische Zombie-Logik:
- Nach außen bleibt Scrum sichtbar.
- Im Inneren dominiert weiter die alte Steuerungslogik.
- Das Team bewegt sich, reagiert aber nicht wirklich auf neue Erkenntnisse.
Es arbeitet innerhalb eines Rahmens, der zwar agil genannt wird, aber die Grundlagen wirksamer Agilität nicht zulässt.
Tipp: Suche bei Scrum-Problemen nicht nur im Team, sondern immer auch im umgebenden Steuerungsmodell nach den eigentlichen Ursachen.
Die größte Distanz liegt oft zwischen Team und echtem Bedarf
Ein besonders wichtiger Punkt ist die Distanz zwischen wertschöpfenden Teams und dem Ort, an dem das eigentliche Bedürfnis entsteht. Je mehr Zwischenebenen zwischen Team und realem Nutzungskontext liegen, desto schwächer werden Feedback und Lernfähigkeit.
In vielen Organisationen ist genau das der Fall. Teams arbeiten an Anforderungen, die bereits durch mehrere Instanzen gefiltert wurden. Fachbereiche formulieren Bedarfe, priorisieren Lösungen und treten gegenüber der IT als Auftraggeber auf. Das Team liefert dann an interne Ansprechpartner, nicht an den realen Nutzungskontext. Damit entsteht eine Stellvertreterlogik: Feedback kommt, aber nicht unbedingt von dort, wo sich Wirkung tatsächlich zeigt.
Das Problem ist nicht, dass interne Ansprechpartner unnötig wären. Das Problem liegt darin, sie mit Kundenrealität zu verwechseln. Wenn eine interne Stelle zufrieden ist, bedeutet das noch nicht, dass die Lösung im Markt, im Betrieb oder bei Anwendern tatsächlich funktioniert.
Typische Folgen sind:
- Teams arbeiten lange an Lösungen, die später kaum genutzt werden.
- Anforderungen werden sauber umgesetzt, lösen aber das falsche Problem.
- Feedback kommt zu spät oder aus zweiter Hand.
Genau dort beginnt Verschwendung.
Tipp: Zeichne den Weg eines Features vom ersten Bedarf bis zur tatsächlichen Nutzung auf und markiere jede Station dazwischen. Oft wird erst dann sichtbar, wie groß die Distanz wirklich ist.
Selbstorganisation scheitert nicht nur am Team, sondern an fehlendem Spielraum
Selbstorganisation klingt in vielen Unternehmen attraktiv. In der Praxis bleibt sie jedoch oft ein Appell ohne Substanz. Teams sollen Verantwortung übernehmen, bekommen aber weder ausreichende Entscheidungsspielräume noch die Möglichkeit, systemische Hindernisse zu verändern.
Das führt zu einer frustrierenden Situation. Die Beteiligten spüren meist sehr genau, dass etwas nicht stimmt. Sie erleben unnötige Reibung, überladene Prozesse und schwache Feedbackschleifen. Gleichzeitig fehlt ihnen die Macht, an grundlegenden Bedingungen etwas zu ändern. So entsteht leicht Resignation: Man erkennt das Problem, hält den eigenen Einfluss aber für zu gering.
Besonders sichtbar wird das in Retrospektiven. Sie drehen sich oft um Symptome des letzten Sprints, nicht um die tieferen Muster des Systems. Dadurch bleiben sie oberflächlich. Statt die eigentlichen Wirkzusammenhänge zu betrachten, wird nur an Kleinigkeiten gefeilt. Das System bleibt intakt, der Frust ebenfalls.
Hilfreich wird Selbstorganisation erst dann, wenn Teams nicht nur ihre Aufgaben, sondern auch ihre Arbeitsbedingungen reflektieren dürfen. Dazu gehören größere Fragen wie:
- Woran merken wir überhaupt, ob unsere Arbeit wirksam ist?
- Wo verlieren wir Informationen?
- Welche Regeln helfen uns wirklich?
- Welche Routinen halten nur noch den Schein von Bewegung aufrecht?
Tipp: Nutze Retrospektiven nicht nur zur Rückschau auf den letzten Sprint, sondern auch zur Analyse der Bedingungen, unter denen der Sprint überhaupt stattfindet.
Führung entscheidet mit darüber, ob Scrum lebendig werden kann
Ein starkes Motiv ist die Rolle des Managements. Teams allein können Zombie Scrum selten auflösen, wenn zentrale Rahmenbedingungen unverändert bleiben. Besonders deutlich zeigt sich das bei Budgetierung, Zielsystemen und Governance.
Ein klassischer Konflikt entsteht dort, wo Budgets an fest zugesagte Lieferumfänge gekoppelt sind. Dann muss zu Beginn eines Jahres definiert werden, was bis wann geliefert wird, damit Mittel freigegeben werden können. Gleichzeitig erwartet die Organisation Anpassungsfähigkeit, weil sich Märkte, Technologien und Prioritäten schnell verändern. Dieser Widerspruch ist kaum auflösbar. Wer an festem Scope gemessen wird, hat wenig Anreiz, unterwegs neue Erkenntnisse ernst zu nehmen.
Demgegenüber steht ein anderer Gedanke: Teams oder Wertströme stärker auf Wirkung statt auf Lieferlisten auszurichten. Dann rückt nicht die Frage in den Mittelpunkt, welche Funktionen exakt umgesetzt wurden, sondern welche beobachtbaren Ergebnisse erreicht werden sollen.
Das verändert die Steuerung spürbar:
- Transparenz entsteht nicht über Mikromanagement,
- sondern über gemeinsam vereinbarte Zielbilder,
- überprüfbare Kennzahlen,
- und sichtbare Wirkung.
Damit steigt allerdings auch die Anforderung an Führung. Sie muss weniger in Details eingreifen und stärker Bedingungen gestalten. Führung wird dann zur Aufgabe, ein Umfeld zu schaffen, in dem Lernen, Sichtbarkeit und Anpassung überhaupt möglich werden.
Tipp: Führe Gespräche mit Führungskräften nicht zuerst über Scrum-Regeln, sondern über die Frage, welche Steuerungslogik lebendiges Lernen derzeit verhindert.
Was aus dem Gespräch hängen bleibt
Zombie Scrum ist kein Methodenfehler, sondern ein Warnsignal für das System
Im Schlussgedanken verdichtet sich die zentrale Botschaft: Scrum entfaltet nur dann Wirkung, wenn es wirklich auf Unsicherheit, Dynamik und Lernen ausgerichtet wird. Wo diese Logik fehlt, bleiben nur die Hüllen der Methode zurück. Dann gibt es Prozesse ohne Erkenntnis, Meetings ohne Richtung und Aktivität ohne Effekt.
Die eigentliche Herausforderung besteht deshalb nicht darin, Scrum äußerlich sauberer zu machen. Entscheidend ist, wieder näher an die ursprüngliche Frage heranzukommen: Wofür wird Scrum hier überhaupt gebraucht? Erst aus dieser Klärung ergeben sich die nächsten sinnvollen Schritte. Dann wird sichtbar,
- ob tatsächlich ein komplexes Problem vorliegt,
- welche Informationen fehlen,
- wo Distanz zum Bedarf entstanden ist,
- welche Rahmenbedingungen Veränderung blockieren.
Das macht den Begriff Zombie Scrum so nützlich. Er zeigt nicht auf einzelne Personen. Er macht sichtbar, dass ein System seine Lebendigkeit verloren hat. Genau darin liegt auch die Chance. Denn was sichtbar wird, kann besprechbar werden. Und was besprechbar wird, kann Schritt für Schritt verändert werden.
Im Gespräch mit Johannes Schartau wird deutlich, dass diese Veränderung selten durch den großen Umbruch beginnt. Sie beginnt eher mit einer ehrlichen Diagnose, einer besseren Frage und dem Mut, Wirkung wichtiger zu nehmen als Gewohnheit.
📥 Download-Tipp: Kennen Sie schon „The PPM Paradise”? In diesem kostenlosen E-Book erfahren Sie, wie das „Paradies für ein unternehmensweites Projektumfeld“ aussehen könnte, in dem jede:r das beruhigende Gefühl hat, immer alles im Griff zu haben – völlig unabhängig von der Technologie. Hier direkt runterladen: https://www.theprojectgroup.com/data/Downloads_eBooks/TPG_PPM_Paradise_eBook_-_TPG_TheProjectGroup.pdf
Weitere PPM-Infos
