"Scrum vs. Kanban – Die falsche Debatte"

Dezember 2025 9 Min. Lesezeit Meinung + Method Review

Alle paar Monate entdeckt das Agile-Internet die Debatte Scrum versus Kanban neu. Blogbeiträge werden geschrieben. LinkedIn-Threads füllen sich mit Kommentaren. Practitioners beziehen Stellung. Die Debatte läuft meistens als Wettbewerb ab: Was ist besser? Die Antwort, die selten in die Debatte findet, lautet: Die Frage selbst ist falsch.

---

Der Einstieg: Ein falscher Wettbewerb

Scrum und Kanban sind keine konkurrierenden Frameworks. Sie lösen unterschiedliche Probleme. Sich zwischen ihnen zu entscheiden ist nicht so, als würde man zwischen zwei Routen zum gleichen Ziel wählen. Es ist eher wie die Wahl zwischen einer Karte und einem Kompass – nützlich in verschiedenen Situationen, ergänzend im richtigen Kontext, und keines davon dem anderen universell überlegen.

Die Debatte Scrum versus Kanban hält sich, weil sie mitreißender ist als die zutreffende, aber weniger befriedigende Antwort: Es kommt darauf an. Auf die Art der Arbeit, die Reife des Teams, die Kultur der Organisation und das Problem, das man eigentlich lösen will. Diese Antwort generiert kein LinkedIn-Engagement. Also geht die Debatte weiter.

Dieser Artikel wird keinen Gewinner ausrufen. Er versucht klarzumachen, wofür jeder Ansatz tatsächlich gedacht ist – und dabei zu helfen, darüber nachzudenken, welcher Ansatz zum eigenen Kontext passt, statt welcher das Internet-Argument gewinnt.

---

Die Realität: Was jeder Ansatz wirklich ist

Scrum: Ein Framework für komplexe Produktentwicklung

Scrum ist ein Framework für die Entwicklung von Produkten in komplexen, unsicheren Umgebungen, in denen sich Anforderungen weiterentwickeln und Lernen zählt. Sein Kernmechanismus ist der Sprint – eine feste Time-Box, die einen regelmäßigen Rhythmus aus Planung, Umsetzung, Inspektion und Anpassung erzeugt. Das Sprint Goal gibt jeder Iteration einen definierten Zweck. Das Sprint Review schafft einen regelmäßigen Feedback-Loop mit Stakeholdern. Die Retrospective schafft einen regelmäßigen Loop für die Teamentwicklung.

Scrum hat eine klare Haltung. Es schreibt bestimmte Rollen, bestimmte Events und bestimmte Artefakte vor. Das ist kein Zufall – die Einschränkungen schaffen Fokus und erzwingen Gespräche, die sonst vielleicht vermieden würden. Die Sprint-Time-Box zum Beispiel erzwingt eine Priorisierungsentscheidung: Was ist gerade am wichtigsten? Die Product-Owner-Rolle erzwingt Verantwortlichkeit: Eine Person ist für die Richtung des Produkts verantwortlich.

Scrum funktioniert gut, wenn: Anforderungen wirklich unsicher und wahrscheinlich veränderlich sind, Kundenfeedback wesentlich für die Produktrichtung ist, das Team ein Produkt mit einem klaren Owner entwickelt, und regelmäßige Planungs- und Inspektionszyklen Mehrwert schaffen.

Scrum funktioniert schlecht, wenn: die Arbeit keine Produktentwicklung ist, das Team einen kontinuierlichen Strom verschiedenartiger Anfragen bearbeitet ohne klare Sprint-Grenzen, oder das Team zu reif und selbstgesteuert ist, um von Scrums Gerüst zu profitieren.

Kanban: Eine Methode zur Flow-Steuerung

Kanban ist kein Framework für Produktentwicklung. Es ist eine Methode zur Steuerung und Verbesserung des Arbeitsflusses durch ein System. Die Ursprünge liegen in der Lean-Fertigung – konkret im Toyota-Produktionssystem – und seine Kernmechanismen sind Visualisierung, Flow-Management und WIP-Limits.

Kanban ist bewusst nicht-präskriptiv in Bezug auf Rollen, Events und Artefakte. Es sagt: Macht euren aktuellen Prozess sichtbar, begrenzt die laufende Arbeit, steuert den Flow, macht Richtlinien explizit, implementiert Feedback-Schleifen und verbessert euch gemeinsam. Es sagt nicht, wie ihr euer Team organisieren sollt, wie lang euer Planungshorizont sein soll oder wer für was verantwortlich ist. Das ist ein Feature, keine Einschränkung.

Kanban funktioniert gut, wenn: Arbeit kontinuierlich und unvorhersehbar eintrifft, verschiedene Arbeitselemente unterschiedliche Prioritäten und Durchlaufzeiten haben, das Team eher einen Service erbringt als ein Produkt zu entwickeln, und das Hauptproblem die Flow-Effizienz ist und nicht die Planungsunsicherheit.

Kanban funktioniert schlecht, wenn: dem Team die Disziplin fehlt, WIP-Limits durchzusetzen, die Arbeit von strukturierter Planung und Zielsetzung wirklich profitieren würde, oder das Team nicht reif genug ist, sich ohne explizitere Struktur selbst zu steuern.

Die einfachste Diagnose: Arbeitet euer Team an einem Produkt mit einer definierten Richtung und sich entwickelnden Anforderungen – oder bearbeitet es einen kontinuierlichen Strom von Service-Anfragen? Produktentwicklung mit unsicheren Anforderungen ist Scrum-Terrain. Kontinuierliche Service-Lieferung mit Flow-Effizienz-Bedürfnissen ist Kanban-Terrain. Viele Teams tun beides – und genau dort beginnen sich die Frameworks zu ergänzen.

---

Der Checksum: Wo die Debatte schiefläuft

Falsche Annahme 1: Sie schließen sich gegenseitig aus

Die Debatte Scrum versus Kanban geht davon aus, dass man sich für eines entscheiden muss. In der Praxis nutzen viele Teams Elemente beider Ansätze – ein Phänomen, das manchmal Scrumban genannt wird, das je nach Implementierung entweder ein sinnvoller Hybrid oder ein verworrener Mittelweg ist.

Die nützlichere Frage lautet: Welches Problem versucht ihr zu lösen? Wenn ein Scrum-Team mit zu viel laufender Arbeit und chaotischer Sprint-Umsetzung kämpft, kann das Hinzufügen von Kanbans WIP-Limits innerhalb des Sprints helfen. Wenn ein Kanban-Team mit ziellosem Arbeiten und keinem Mechanismus für Reflexion und Verbesserung kämpft, kann das Hinzufügen von Scrums Sprint Retrospective und einem Planungsrhythmus helfen.

Frameworks sind keine Religionen. Sie sind Werkzeuge. Wer einen Hammer benutzt, muss keinen Schraubenzieher ausschließen.

Falsche Annahme 2: Eines ist agiler als das andere

Eine hartnäckige Variante der Debatte positioniert Kanban als „agiler” als Scrum, weil es weniger präskriptiv ist, oder Scrum als „agiler”, weil es explizite Inspektions- und Anpassungszyklen hat. Beide Positionen missverstehen das Agile Manifesto, das keines der Frameworks vorschreibt.

Die Werte und Prinzipien des Manifests können durch Scrum, Kanban, XP oder gar kein benanntes Framework bedient werden. Agilität ist eine Eigenschaft des Verhaltens einer Organisation – ihre Fähigkeit, zu inspizieren, sich anzupassen und Wert als Reaktion auf Veränderungen zu liefern. Es ist keine Eigenschaft des verwendeten Frameworks.

Falsche Annahme 3: Die Framework-Wahl ist die schwierige Teil

Teams investieren erheblich Energie in die Debatte Scrum versus Kanban und vergleichsweise wenig in die Dinge, die tatsächlich darüber entscheiden, ob einer der Ansätze funktioniert: die Qualität ihres Backlogs, die Klarheit ihrer Prioritäten, das Vertrauensniveau innerhalb des Teams, die Bereitschaft der Organisation, auf Impediments zu reagieren, und das Führungsverhalten, das Selbstorganisation entweder ermöglicht oder untergräbt.

Ein Scrum-Team mit einem klaren Product Owner, echter Psychological Safety und organisatorischer Unterstützung für Selbstmanagement wird ein Kanban-Team ohne diese Dinge übertreffen. Und umgekehrt. Das Framework ist eine verhältnismäßig kleine Variable in der Ergebnisgleichung.

„Scrum ohne Disziplin ist Chaos mit Zeremonien. Kanban ohne WIP-Limits ist eine To-do-Liste mit Spalten. Kein Framework funktioniert ohne die organisatorischen Bedingungen, die es zum Funktionieren braucht.” Markus – agile-checksum.com

---

Praxisbeispiele: Das richtige Werkzeug wählen

Wann Scrum die richtige Wahl war

Ein Produktteam bei einem Unternehmen im Bereich Healthcare-Technologie entwickelte eine neue Plattform für das Patientenmanagement. Die Anforderungen entstanden durch User Research und klinisches Feedback. Das Team hatte einen dedizierten Product Owner mit echtem Domänenwissen und Zugang zu Stakeholdern. Die Arbeit war wirklich komplex – technische Unsicherheit und Anforderungsunsicherheit waren beide hoch.

Scrum diente diesem Team gut. Der Sprint-Rhythmus erzwang regelmäßige Priorisierungsentscheidungen und verhinderte, dass das Team in technischen Sackgassen verschwand, ohne zu prüfen, ob die Richtung noch Sinn ergab. Das Sprint Review schuf einen regelmäßigen Feedback-Loop mit klinischen Stakeholdern, der wiederholt Anforderungen aufdeckte, die nicht antizipiert worden waren. Die Retrospective half dem Team, ihre Schätzungs- und Kollaborationspraktiken im Laufe der Zeit zu verbessern.

Nach achtzehn Monaten hatte das Team ein Produkt geliefert, das sich erheblich von der ursprünglichen Spezifikation unterschied – und erheblich nützlicher war. Scrums Inspektions- und Anpassungszyklen hatten es dem Produkt ermöglicht, sich als Reaktion auf das Gelernte weiterzuentwickeln.

Wann Kanban die richtige Wahl war

Ein IT-Operations-Team bei einem Fertigungsunternehmen bearbeitete einen kontinuierlichen Strom von Infrastrukturanfragen, Incident-Responses und Wartungsaufgaben. Arbeit traf unvorhersehbar und mit unterschiedlicher Priorität ein. Manche Anfragen waren dringend und mussten noch am gleichen Tag gelöst werden. Andere waren geplante Wartungsarbeiten, die Wochen warten konnten. Es gab kein Product Backlog, kein Sprint Goal und keine sinnvolle Möglichkeit, die Arbeit in zweiwöchige Sprints zu packen.

Ein früherer Versuch, diesem Team Scrum aufzuzwingen, hatte gescheitert – die Sprint-Grenzen waren künstlich, die Planungs-Events waren bedeutungslos, weil sich die Prioritäten täglich änderten, und das Team verbrachte mehr Zeit damit, die Scrum-Zeremonien zu managen, als die eigentliche Arbeit zu erledigen. Als es zu Kanban wechselte, war die Verbesserung sofort spürbar. WIP-Limits machten das Multitasking-Problem sichtbar, das zuvor unsichtbar gewesen war. Flow-Metriken gaben dem Team und seinen Stakeholdern aussagekräftige Transparenz über Durchlaufzeiten und Durchsatz. Das Team konnte auf dringende Anfragen reagieren, ohne seinen gesamten Planungszyklus zu stören.

Wann der Hybrid Sinn ergab

Ein Software-Team, das eine interne Datenplattform entwickelte, hatte Merkmale beider Kontexte. Es hatte eine Produktrichtung und einen Product Owner – Scrum-Terrain. Es hatte auch einen kontinuierlichen Strom von Datenqualitätsvorfällen und ad-hoc Stakeholder-Anfragen, die sich nicht sauber in die Sprint-Planung fügen ließen – Kanban-Terrain.

Die Lösung: ein modifiziertes Scrum-Framework mit einer expliziten Kanban-Lane für ungeplante Arbeit. Sprint Planning allocierte 70 % der Kapazität auf geplante Produktentwicklung. Die verbleibenden 30 % waren für die Kanban-Lane reserviert – ein separates Board mit WIP-Limits, wo ungeplante Anfragen triagiert und bearbeitet wurden, ohne das Sprint-Commitment zu stören. Sprint Retrospectives betrachteten beide Arbeitsströme.

Es war kein Lehrbuch-Scrum und kein Lehrbuch-Kanban. Es war pragmatisch – darauf ausgelegt, dem tatsächlichen Kontext des Teams zu dienen, statt einer puristischen Definition eines der Frameworks zu genügen.

---

Ein Method Review: Ehrliche Stärken und Schwächen

	Scrum	Kanban
Am besten für	Komplexe Produktentwicklung mit sich entwickelnden Anforderungen	Kontinuierliche Service-Lieferung mit Flow-Effizienz-Bedürfnissen
Kernstärke	Regelmäßige Inspektions- und Anpassungszyklen	Flow-Transparenz und WIP-Management
Kernschwäche	Kann ohne Disziplin zu zeremoniellen Overhead werden	Kann ohne Planungsstruktur ziellos werden
Erfordert	Befähigten Product Owner, Team-Commitment zu Zeremonien	Team-Disziplin zur Durchsetzung von WIP-Limits, Flow-Messung
Scheitert, wenn	Organisation Zeremonien ohne Werte aufzwingt	WIP-Limits ignoriert oder nie gesetzt werden
Ergänzende Elemente	Kanban WIP-Limits innerhalb von Sprints, Flow-Metriken	Sprint Retrospectives, Planungsrhythmus, Ziele

---

Das Fazit: Die richtige Frage stellen

Hört auf zu fragen, welches Framework besser ist. Fangen Sie an zu fragen, welches Problem Sie lösen wollen und welcher Ansatz dieses Problem in Ihrem spezifischen Kontext bedient. Die Antwort wird klarer, nützlicher und deutlich weniger geeignet sein, ein sinnloses LinkedIn-Argument auszulösen.

Die wichtigsten Variablen bei der Framework-Wahl sind nicht die Frameworks selbst. Es sind die Natur Ihrer Arbeit, die Reife Ihres Teams und die organisatorischen Bedingungen, die den gewählten Ansatz entweder unterstützen oder untergraben werden. Stimmen diese, wird die Framework-Wahl deutlich weniger entscheidend. Stimmen sie nicht, wird kein Framework Sie retten.

Führen Sie den Checksum für Ihre Framework-Wahl durch:

1. Ist Ihre primäre Herausforderung Planungsunsicherheit und sich entwickelnde Anforderungen – oder Flow-Effizienz und unvorhersehbare Nachfrage?
2. Dient Ihr aktuelles Framework Ihrem tatsächlichen Arbeitskontext, oder wurde es adoptiert, weil es gerade in Mode, vorgeschrieben oder vertraut war?
3. Was ist die eine Sache, die Ihr aktueller Ansatz nicht gut macht – und gibt es etwas vom anderen Ansatz, das dem begegnen würde?

Das Ziel ist nicht, Scrum oder Kanban korrekt anzuwenden. Das Ziel ist, Kunden zuverlässig Wert zu liefern und sich kontinuierlich zu verbessern. Nutzen Sie, was diesem Ziel dient. Ändern Sie es, wenn es aufhört, es zu dienen.

---

In diesem Artikel verwendete Glossarbegriffe

• Scrum – Ein leichtgewichtiges Framework für die Entwicklung und Lieferung komplexer Produkte in unsicheren Umgebungen.
• Kanban – Eine Methode zur Steuerung des Arbeitsflusses mit Visualisierung und WIP-Limits.
• WIP-Limit – Work In Progress Limit, ein Kanban-Mechanismus zur Reduzierung von Multitasking und Verbesserung des Flows.
• Agile Manifesto – Das Dokument aus dem Jahr 2001, das die Werte und Prinzipien der agilen Softwareentwicklung definiert.
• Retrospective – Eine Scrum-Zeremonie zur Inspektion des Sprints und zur Identifikation von Verbesserungen.
• Product Owner – Die Scrum-Verantwortlichkeit für die Maximierung des Produktwerts.
• Psychological Safety – Die gemeinsame Überzeugung, dass es sicher ist, im Team interpersonelle Risiken einzugehen.