Scrum ist tot – was jetzt wirklich funktioniert

Scrum ist tot. Zumindest hört man diese Aussage immer häufiger. Teams klagen über zu viele Meetings. Führungskräfte sehen kaum messbaren Business Impact. Product Owner verwalten Backlogs, während Entscheidungen weiterhin außerhalb des Teams fallen. Gleichzeitig setzen Unternehmen stärker auf Kanban, hybride Modelle und produktorientierte Organisationsformen. Das Problem ist jedoch selten Scrum selbst. Gescheitert ist vor allem die Vorstellung, dass ein Framework automatisch Agilität erzeugt. Wer heute erfolgreich agil arbeiten will, braucht weniger Methodentreue und mehr Fokus auf Wert, Flow, Kundenfeedback und echte Entscheidungsfähigkeit. Dieser Beitrag zeigt, was von Scrum weiterhin funktioniert, was Unternehmen besser ändern sollten und welche Ansätze heute überzeugender sind.

Nein. Scrum ist nicht tot. Aber Scrum als standardisiertes Organisationsrezept für jedes Team und jedes Problem hat ausgedient.

Der offizielle Scrum Guide ist weiterhin gültig. Seine aktuelle Fassung stammt aus dem Jahr 2020. Scrum beschreibt sich darin bewusst als leichtgewichtiges und unvollständiges Framework für komplexe Probleme. Im Mittelpunkt stehen Empirie, Transparenz, Überprüfung, Anpassung und die regelmäßige Lieferung von Wert.

Das klingt erstaunlich zeitgemäß.

Viele Probleme, die Unternehmen heute mit Scrum verbinden, stehen gar nicht im Scrum Guide:

Das ist nicht Scrum. Es ist häufig klassische Steuerung mit agilen Begriffen.

Die entscheidende Frage lautet deshalb nicht: Was kommt nach Scrum?

Sie lautet:

Welche Arbeitsweise hilft unserem Team, schneller zu lernen und verlässlich mehr Wert zu liefern?

Die Kritik kommt nicht aus dem Nichts. Sie trifft reale Probleme vieler Organisationen.

Der 18. State of Agile Report zeigt eine deutliche Verschiebung. Unternehmen richten agile Arbeit stärker auf messbare Ergebnisse aus. Gleichzeitig verwenden mittlerweile 74 Prozent der befragten Organisationen hybride, kombinierte oder selbst entwickelte agile Modelle. Agile verschwindet also nicht. Unternehmen lösen sich aber zunehmend von starren Framework-Vorgaben.

Dafür gibt es mehrere Gründe.

In manchen Teams bedeutet Scrum:

Montag Planning.
Jeden Morgen Daily.
Mittwoch Refinement.
Freitag Review und Retrospektive.

Der Kalender ist agil. Die Organisation dahinter bleibt unverändert.

Entscheidungen dauern weiterhin drei Wochen. Fachkräfte arbeiten gleichzeitig in fünf Projekten. Releases benötigen mehrere Freigaben. Der Product Owner darf über kaum etwas selbst entscheiden.

Mehr Scrum Events lösen diese Probleme nicht.

Viele Teams messen:

Keine dieser Kennzahlen beantwortet automatisch, ob Kunden oder Unternehmen einen Mehrwert erhalten.

Ein Team kann seine Velocity steigern und trotzdem Funktionen entwickeln, die kaum jemand benötigt.

Scrum erwartet selbstmanagende und funktionsübergreifende Teams.

In der Praxis fehlen häufig:

Das Team soll agil sein, ist aber von zahlreichen externen Stellen abhängig.

Dann optimiert Scrum nur einen kleinen Ausschnitt der Wertschöpfung.

Ein Produktteam mit kontinuierlichem Eingang kleiner Anforderungen arbeitet anders als ein Team, das alle zwei Wochen ein zusammenhängendes Produktinkrement entwickelt.

Support, Wartung, Plattformbetrieb oder Serviceorganisationen haben häufig:

Ein erzwungener Sprint-Rhythmus kann dort zusätzliche Planung erzeugen, ohne den Arbeitsfluss zu verbessern.

Die stärksten Ansätze beginnen nicht mit einem Framework. Sie beginnen mit dem Problem, das gelöst werden soll.

Sie kombinieren mehrere Prinzipien.

Die erste Veränderung ist die wichtigste:

Weg von „Was haben wir geliefert?“ hin zu „Was hat sich dadurch verbessert?“

Ein Produktteam sollte nicht nur wissen, welche Features es entwickelt. Es sollte verstehen, welches Ergebnis diese Arbeit erzeugen soll.

Beispiel:

Nicht:

„Self-Service-Funktion entwickeln.“

Sondern:

„Den Anteil vollständig digital abgeschlossener Servicevorgänge innerhalb von sechs Monaten von 35 auf 60 Prozent erhöhen.“

Dadurch verändert sich die Priorisierung.

Plötzlich zählt nicht mehr, wie viele Features das Team fertigstellt. Entscheidend ist, welche Maßnahmen das gewünschte Ergebnis beeinflussen.

Auch die aktuellen Entwicklungen im agilen Umfeld gehen klar in diese Richtung. Der State of Agile Report 2025 beschreibt Outcomes und Wert als zentrale Steuerungsgrößen moderner Agilität.

Scrum funktioniert besonders gut, wenn ein stabiles Team dauerhaft Verantwortung für ein Produkt oder einen klaren Wertstrom übernimmt.

Genau daran scheitert es in vielen Projektorganisationen.

Ein typisches Muster sieht so aus:

Fachbereich formuliert Anforderungen.
Projektteam setzt sie um.
IT übernimmt die Lösung.
Betrieb betreibt sie.
Ein anderes Team kümmert sich später um Änderungen.

Jede Übergabe kostet Zeit und Information.

Moderne Product Operating Models versuchen diese Grenzen zu reduzieren. Teams übernehmen stärker die Verantwortung von der Idee über Discovery und Entwicklung bis zu Betrieb und Weiterentwicklung. Scrum.org beschreibt diese Verbindung von Strategie, Menschen, Strukturen sowie Discovery, Delivery und Support inzwischen ausdrücklich als Teil eines Agile Product Operating Model.

Das bedeutet nicht, dass jedes Unternehmen sein Organigramm abschaffen muss.

Aber Teams sollten möglichst:

Das ist häufig wichtiger als die Frage, ob ein Sprint exakt zwei Wochen dauert.

Klassisches Scrum beantwortet vor allem die Frage, wie komplexe Arbeit empirisch umgesetzt wird.

Moderne Produktentwicklung stellt zusätzlich eine vorgelagerte Frage:

Sollten wir diese Lösung überhaupt bauen?

Deshalb verbinden leistungsfähige Teams Discovery und Delivery.

Discovery darf dabei nicht zu einer neuen vorgelagerten Analysephase werden.

Ideal ist ein kontinuierlicher Kreislauf:

Problem verstehen → Hypothese entwickeln → testen → umsetzen → messen → lernen

Damit verändert sich auch die Rolle des Product Owners. Er verwaltet nicht nur Anforderungen. Er verantwortet gemeinsam mit dem Team die Frage, welche Arbeit den größten Wert erzeugt.

Eine der sinnvollsten Ergänzungen zu Scrum kommt aus Kanban.

Kanban betrachtet stärker den tatsächlichen Arbeitsfluss.

Vier besonders wichtige Flow-Metriken sind:

Diese vier Metriken gehören auch im aktuellen Kanban Guide zu den grundlegenden Flow-Kennzahlen.

Sie beantworten wesentlich praktischere Fragen als Velocity:

Scrum und Kanban schließen sich dabei nicht aus.

Ein Scrum Team kann Sprints, Sprint-Ziele und Reviews beibehalten und gleichzeitig WIP begrenzen und Flow messen.

Gerade diese Kombination funktioniert in vielen Unternehmen besser als reines Scrum.

Die Zeit der Glaubenskriege zwischen Scrum, Kanban und klassischem Projektmanagement sollte vorbei sein.

Die bessere Frage lautet:

Welche Steuerungslogik passt zur Arbeit?

Hybrid bedeutet dabei nicht, beliebige Methoden zusammenzuwerfen.

Jedes Element sollte ein konkretes Problem lösen.

PMI beschreibt diese Entwicklung inzwischen ausdrücklich als „fit for purpose“. Untersuchungen zeigen zudem, dass agile, klassische und hybride Ansätze vergleichbare Projektergebnisse erzielen können, wenn sie passend zum Kontext eingesetzt werden.

Wer Scrum abschaffen will, sollte zuerst prüfen, welche Bestandteile tatsächlich Probleme verursachen.

Viele Kernelemente sind weiterhin sehr wertvoll.

Ein Team braucht eine gemeinsame längerfristige Richtung.

Ein Sprint sollte kein Container voller Tickets sein. Ein gemeinsames Ziel schafft Fokus und ermöglicht sinnvolle Entscheidungen während des Sprints.

Regelmäßiges Feedback auf echte Ergebnisse gehört zu den stärksten Elementen von Scrum.

Teams müssen ihre Arbeitsweise systematisch hinterfragen. Ohne regelmäßige Reflexion verfestigen sich schlechte Prozesse.

„Fast fertig“ ist einer der größten Feinde verlässlicher Lieferung.

Arbeiten, prüfen, lernen und anpassen bleibt für komplexe Probleme eine überzeugende Grundlogik.

Der Scrum Guide wurde 2020 sogar bewusst weniger präskriptiv gestaltet. Er soll ein minimal ausreichender Rahmen sein und ausdrücklich durch passende Techniken ergänzt werden.

Einige Praktiken halten sich hartnäckig, obwohl sie weder notwendig noch hilfreich sind.

Streiche oder hinterfrage insbesondere:

Die Leitfrage lautet immer:

Hilft diese Praktik dabei, schneller Wert zu erzeugen oder schneller zu lernen?

Wenn die Antwort dauerhaft Nein lautet, braucht sie eine sehr gute andere Begründung.

Bei einem Finanzdienstleister arbeitete ein Team bereits mit Scrum. Gleichzeitig führten ungeplante Aufgaben und ein unsteter Arbeitsfluss regelmäßig zu Schwierigkeiten.

Statt Scrum komplett abzuschaffen, ergänzte die Organisation das bestehende Modell um Kanban-Praktiken.

Das Team betrachtete den Flow genauer, passte seine Events an und machte laufende Arbeit transparenter. Die Kombination aus Scrum und Kanban verbesserte laut dokumentierter Fallstudie sowohl Zusammenarbeit als auch Kundenausrichtung und Teammoral.

Die wichtige Erkenntnis:

Nicht das Framework musste ersetzt werden. Es musste sinnvoll ergänzt werden.

Bei einem Anbieter einer Investmentplattform war agile Arbeit stark auf den IT-Bereich konzentriert. Das Unternehmen erkannte, dass die vorhandene Umsetzung nicht genügend Wert erzeugte.

Die Organisation startete deshalb keinen kompletten Methodenwechsel.

Stattdessen verband sie Scrum stärker mit:

Die dokumentierte Fallstudie berichtet unter anderem von einer Verbesserung der Backlog-Qualität um mehr als 30 Prozent.

Auch hier lag das Problem nicht darin, dass Scrum grundsätzlich ungeeignet war.

Das Problem war ein zu mechanischer Einsatz ohne ausreichenden Blick auf Wert und Wirkung.

Ein Industrieunternehmen kämpfte mit langen Entwicklungszyklen und Produkten, die teilweise nicht mehr ausreichend zum Kundenbedarf passten.

Statt Software-Scrum unverändert auf Hardware zu übertragen, passte das Unternehmen agile Prinzipien an seine Entwicklungsrealität an.

Kurze Lernschleifen, frühe Prototypen und ein stärkerer Fokus auf Kundenfeedback halfen dabei, Entwicklungszyklen zu verkürzen und schneller Erkenntnisse zu gewinnen.

Das Beispiel zeigt, warum „Scrum oder kein Scrum?“ oft die falsche Frage ist.

Entscheidend ist, welche Prinzipien den Wertstrom verbessern.

Wer seine bestehende Scrum-Organisation weiterentwickeln möchte, kann pragmatisch vorgehen.

Analysiere den Weg von einer Idee bis zum tatsächlichen Kundennutzen.

Wo entstehen Wartezeiten, Übergaben und Freigaben?

Jedes Team braucht einen nachvollziehbaren Verantwortungsbereich und messbare Outcomes.

Kann der Product Owner tatsächlich priorisieren?

Kann das Team technische Entscheidungen selbst treffen?

Welche Entscheidungen liegen unnötig außerhalb?

Visualisiere Work in Progress und reduziere parallele Aufgaben.

Beginne mindestens mit Cycle Time, Throughput, Work Item Age und WIP.

Behalte Events, die Transparenz, Feedback oder Verbesserung erzeugen.

Gestalte sie anders, wenn sie nur noch Rituale sind.

Ergänze Delivery-Metriken um Kennzahlen wie:

Auch aktuelle DORA-Forschung unterstreicht die Bedeutung von Nutzerorientierung, stabilen Prioritäten, kleinen Lieferumfängen und geeigneten Delivery-Metriken für leistungsfähige Technologieorganisationen.

Heute Scrum, morgen SAFe, danach Product Operating Model.

Das Problem bleibt bestehen, wenn Entscheidungswege, Silos und Prioritäten unverändert bleiben.

Weniger Meetings sind nicht automatisch besser.

Reviews und Retrospektiven besitzen einen klaren Nutzen, wenn sie richtig durchgeführt werden.

Teams brauchen Richtung, Prioritäten und klare Grenzen.

Autonomie ohne Orientierung erzeugt keine Agilität.

Ein bisschen Scrum, ein Kanban-Board und ein klassischer Projektplan ergeben noch kein gutes hybrides Modell.

Jede Praktik braucht einen nachvollziehbaren Zweck.

Ein Team kann Tickets extrem schnell bearbeiten und trotzdem am Kunden vorbeiarbeiten.

Flow und Outcome gehören zusammen.

Scrum ist eine gute Wahl, wenn ein kleines, stabiles und funktionsübergreifendes Team ein komplexes Produkt entwickelt und regelmäßig aus Kunden- oder Stakeholderfeedback lernen kann.

Besonders stark ist Scrum, wenn:

Unter diesen Bedingungen besteht wenig Grund, Scrum aus modischen Gründen abzuschaffen.

Scrum stößt an Grenzen, wenn wesentliche Voraussetzungen fehlen.

Zum Beispiel:

Dann hilft häufig auch kein besseres Scrum Training.

Die Organisation muss ihre Strukturen verändern.

Der aktuelle Diskurs um Agile Product Operating Models macht genau diesen Punkt: Wertorientierte Teams benötigen nicht nur agile Praktiken, sondern passende Governance, Führung, Finanzierung und Organisationsstrukturen.

Ja. Die Grundprinzipien von Scrum sind weiterhin relevant. Unternehmen kombinieren Scrum jedoch zunehmend mit Flow, Product Management, Kanban und hybriden Ansätzen. Entscheidend ist heute stärker die passende Arbeitsweise für den jeweiligen Kontext.

Es gibt keinen einzelnen Nachfolger. Je nach Arbeit eignen sich Scrum, Kanban, Scrum mit Kanban, hybride Modelle oder produktorientierte Betriebsmodelle. Häufig ist eine gezielte Weiterentwicklung sinnvoller als ein kompletter Austausch.

Nicht grundsätzlich. Kanban eignet sich besonders für kontinuierlichen Arbeitsfluss und stark schwankende Anforderungen. Scrum eignet sich gut für komplexe Produktentwicklung mit regelmäßigen Lernzyklen und klaren Produkt- und Sprint-Zielen.

Ja. Scrum kann beispielsweise durch WIP-Limits und Flow-Metriken aus Kanban ergänzt werden. Dadurch bleiben die empirischen Feedbackzyklen von Scrum erhalten, während gleichzeitig der Arbeitsfluss besser gesteuert wird.

Ja, wenn sie Fokus sowie regelmäßige Überprüfung und Anpassung unterstützen. Wenn Arbeit dagegen permanent einläuft und künstlich auf Sprint-Grenzen zugeschnitten werden muss, kann kontinuierlicher Flow geeigneter sein.

Ein Scrum Master kann großen Wert schaffen, wenn er Teams und Organisationen tatsächlich bei Selbstmanagement, Verbesserung und der Beseitigung systemischer Hindernisse unterstützt. Als reiner Moderator für Scrum Events verliert die Rolle dagegen deutlich an Nutzen.

„Scrum ist tot“ ist eine gute Schlagzeile. Als Diagnose greift sie zu kurz.

Nicht Scrum ist das eigentliche Problem.

Problematisch sind Organisationen, die agile Begriffe eingeführt haben, aber weiterhin über Auslastung, Übergaben, Silos und zentrale Entscheidungen steuern.

Was heute wirklich funktioniert, ist weniger spektakulär:

Scrum kann ein sehr guter Teil dieses Systems sein. Es muss aber nicht das gesamte System sein.

PURE Consultant unterstützt Unternehmen dabei, bestehende Scrum- und Agile-Strukturen kritisch zu prüfen und zu einer Arbeitsweise weiterzuentwickeln, die zum tatsächlichen Kontext passt. Im Mittelpunkt stehen dabei nicht Framework-Treue oder zusätzliche Meetings, sondern bessere Zusammenarbeit, kürzere Lernzyklen und messbarer Business Impact.