Agilität

Scrum oder Kanban: Welche agile Methode passt zu Ihrem Team?

Von Codevista InnovationsVeröffentlicht am 12. Oktober 2026Aktualisiert am 15. Oktober 20268 Min. Lesezeit

Scrum organisiert die Arbeit in Sprints von höchstens einem Monat, mit drei Verantwortlichkeiten (Product Owner, Scrum Master, Developers) und festen Events; Kanban steuert einen kontinuierlichen Fluss ohne vorgeschriebene Rollen und begrenzt die laufende Arbeit. Wählen Sie Scrum, wenn ein Team ein Produkt entwickelt und ein Ziel über einige Wochen schützen kann, und Kanban, wenn Anfragen unangekündigt eintreffen (Support, Wartung, Betrieb). Scrumban verbindet beides.

Was ist der Unterschied zwischen Scrum und Kanban?

Beide Ansätze teilen die agilen Prinzipien: Arbeit sichtbar machen, in kleinen Schritten liefern, sich auf Basis von Fakten verbessern. Sie unterscheiden sich im Grad der Struktur. Scrum ist ein Rahmenwerk, beschrieben im Scrum Guide: Verantwortlichkeiten, Events und Artefakte sind festgelegt. Kanban ist eine Methode zur Steuerung des Arbeitsflusses: Man visualisiert den aktuellen Prozess, begrenzt die laufende Arbeit und verbessert ihn Schritt für Schritt.

• Takt: Sprints fester Länge (ein Monat oder weniger) gegenüber einem kontinuierlichen Fluss ohne verpflichtende Iterationen.
• Rollen: Product Owner, Scrum Master und Developers gegenüber keiner neuen vorgeschriebenen Rolle.
• Events: der Sprint und darin Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospective, gegenüber Ritualen, die das Team selbst wählt.
• Begrenzung der Arbeit: das, was in den Sprint aufgenommen wird, gegenüber WIP-Limits je Prozessschritt.
• Messung: Erreichen des Sprint-Ziels (Velocity ist nur eine verbreitete Praxis) gegenüber Lead Time, Durchsatz und Alter der Aufgaben.
• Änderungen: geschütztes Sprint-Ziel, Umfang mit dem Product Owner neu verhandelbar, gegenüber neuen Prioritäten, die angenommen werden, sobald ein Platz frei wird.

Sprints oder kontinuierlicher Fluss: Takt, Rollen und Events

Was der Scrum Guide vorschreibt

Der Sprint ist der Container für alle anderen Events. Seine Länge ist fest und beträgt höchstens einen Monat; viele Softwareteams entscheiden sich für kürzere Sprints. Im Sprint Planning werden das Sprint-Ziel und die Arbeit festgelegt, die darauf einzahlt. Im Daily Scrum, auf 15 Minuten begrenzt, überprüfen die Developers ihren Fortschritt in Richtung dieses Ziels und passen ihren Plan an. Das Sprint Review ist eine Arbeitssitzung mit den Stakeholdern über das Ergebnis und die nächsten Schritte, keine bloße Vorführung. Die Sprint Retrospective befasst sich mit der Arbeitsweise.

Der Product Owner ist dafür verantwortlich, den Wert des Produkts zu maximieren und das Product Backlog zu managen, einschließlich der Reihenfolge der Prioritäten. Der Scrum Master ist für die Einführung von Scrum und für die Effektivität des Scrum Teams verantwortlich. Die Developers, also alle, die am Inkrement arbeiten, unabhängig von ihrem Beruf, verpflichten sich, in jedem Sprint ein nutzbares Inkrement zu liefern, das die Definition of Done erfüllt. Laut Scrum Guide umfasst ein Scrum Team in der Regel zehn oder weniger Personen.

Was Kanban offenlässt

Kanban organisiert das Team nicht um. Man bildet die tatsächlichen Arbeitsschritte ab (zu analysieren, in Arbeit, im Review, geliefert), schreibt die Regeln für den Übergang zwischen den Spalten auf und wählt dann seine Rituale: tägliches Treffen vor dem Board, regelmäßiges Review des Flusses. Diese Flexibilität ermöglicht einen schnellen Start, wird aber zum Risiko, wenn sich niemand für die Verbesserung verantwortlich fühlt.

WIP-Limits, Kennzahlen und Änderungen während des Sprints

Das WIP-Limit (Work in Progress) ist der Kern von Kanban. Ist die auf drei Elemente begrenzte Spalte „Im Review“ voll, kommt dort nichts mehr hinein: Statt etwas Neues zu beginnen, hilft das Team, das Wartende fertigzustellen. Multitasking nimmt ab, Engpässe werden sichtbar. Little’s Law fasst die Intuition formal: In einem stabilen Fluss bedeutet bei gleichem Durchsatz mehr laufende Arbeit im Durchschnitt längere Durchlaufzeiten.

• Scrum: Zuerst zählt, ob das Sprint-Ziel erreicht und das Inkrement wirklich fertig ist. Velocity wird im Scrum Guide nicht vorgeschrieben; sie ist ein internes Prognosewerkzeug, keine Leistungskennzahl für den Vergleich zwischen Teams.
• Kanban: Lead Time (von der Anfrage bis zur Lieferung), Cycle Time (vom Start bis zur Lieferung), Durchsatz und Alter der laufenden Aufgaben beantworten die Frage jedes Auftraggebers: „Wann ist es fertig?“

Zu Änderungen ist der Scrum Guide eindeutig: Keine Änderung darf das Sprint-Ziel gefährden. Der Umfang kann mit dem Product Owner neu verhandelt werden, der als Einziger einen gegenstandslos gewordenen Sprint abbrechen darf. In Kanban wird über die Priorität entschieden, sobald ein Platz frei wird: Ein dringender Störfall kann vorgezogen werden, ohne dass eine Zusage gebrochen wird.

Scrum oder Kanban: Welche Methode für welches Team?

Das richtige Kriterium ist weder die Unternehmensgröße noch die Branche, sondern die Art der Anfragen, die beim Team ankommen.

• Scrum eignet sich für Teams, die ein Produkt mit einem Ziel entwickeln: eine SaaS-Plattform, eine Fachanwendung, einen neuen digitalen Service. Sie können am Ende jedes Sprints ein nutzbares Ergebnis zeigen und das weitere Vorgehen anpassen.
• Kanban eignet sich für kontinuierliche und unvorhersehbare Arbeit: Anwendungssupport, korrektive Wartung, IT-Betrieb, Vorgangsbearbeitung oder interne Anfragen an ein HR- oder Marketingteam.
• Scrumban eignet sich, wenn das Backlog stabil ist, Dringlichkeiten aber häufig auftreten.

In ein und derselben IT-Abteilung, in Casablanca wie anderswo, können beide nebeneinander bestehen: Das Team, das das Kundenportal neu aufbaut, arbeitet mit Scrum, das Team, das die Produktion betreut, mit Kanban. Liefern mehrere Scrum-Teams dasselbe Produkt, stellt sich die Frage nach skalierter Agilität mit SAFe; für Bereiche außerhalb der IT lesen Sie Agilität über die IT hinaus.

Scrumban: Wann sich Scrum und Kanban kombinieren lassen

Für Scrumban gibt es kein mit dem Scrum Guide vergleichbares Regelwerk: Es ist eine Praxis, die einen Teil der Struktur von Scrum beibehält und die Steuerung des Flusses hinzufügt. Zwei Ausgangspunkte sind verbreitet.

• Ein Scrum-Team, das Kanban ergänzt, behält Sprints, Rollen und Events bei, steuert sein Sprint Backlog aber mit WIP-Limits und verfolgt seine Cycle Time.
• Ein Kanban-Team, das einen Takt ergänzt, behält den kontinuierlichen Fluss bei, führt aber ein Review und eine Retrospektive zu festen Terminen ein.

Scrumban scheitert, wenn es als Vorwand dient, alles Unbequeme abzuschaffen: kein Ziel mehr, keine eingehaltenen Limits, keine Retrospektive. Kann das Team nicht mehr sagen, welche Regeln es befolgt, ist es kein Scrumban mehr.

Häufige Fehler mit Scrum und mit Kanban

Scrum-Antipatterns

• Der Product Owner nur dem Namen nach, ohne echte Befugnis, über Prioritäten zu entscheiden.
• Der Scrum Master als Sekretär, der Meetings organisiert, aber kein Hindernis beseitigt.
• Der Sprint ohne Ziel, eine bloße Aufgabenliste, die jede Dringlichkeit aus der Bahn wirft.
• Velocity als Leistungskennzahl, die dazu verleitet, Schätzungen aufzublähen.
• Die Retrospektive ohne Folgen, in der Sprint für Sprint dieselben Probleme wiederkehren.

Kanban-Antipatterns

• Das Board ohne Limits: Alles, was ankommt, wird begonnen; es ist nur eine Liste in Spalten.
• Limits, die jede Woche „ausnahmsweise“ überschritten werden und damit faktisch nicht existieren.
• Implizite Regeln: Niemand weiß, was „fertig“ bedeutet oder wer die nächste Anfrage auswählt.
• Kein Review des Flusses: Das Team ist seinem Board ausgeliefert, statt es zu verbessern.

Checkliste: So wählen Sie zwischen Scrum und Kanban

1. Lässt sich die Arbeit um ein Ziel bündeln, das über einen Sprint (höchstens einen Monat) ohne ständige Unterbrechungen gehalten wird? Wenn ja, ist Scrum ein guter Kandidat.
2. Ist ein großer Teil der Anfragen dringend und unvorhersehbar? Setzen Sie auf Kanban oder auf eine reservierte Kapazität im Scrumban.
3. Gibt es eine Person, die mit echter Befugnis über Prioritäten entscheiden kann? Scrum braucht sie von Anfang an.
4. Ist die Organisation bereit, Rollen und Meetings zu ändern? Wenn nicht, erlaubt Kanban den Einstieg mit dem bestehenden Prozess.
5. Wollen Ihre Auftraggeber vor allem wissen, wann etwas fertig ist? Flusskennzahlen beantworten genau das.
6. Arbeiten mehrere Teams an demselben Produkt? Dann brauchen Sie zusätzlich ein Rahmenwerk für skalierte Agilität.

Unabhängig von der Wahl: Schulen Sie das Team und diejenigen, die seine Prioritäten setzen, gemeinsam. Codevista Innovations bietet eine Scrum-Schulung und eine Kanban-Schulung an, in Präsenz überall in Marokko, hybrid oder remote; unser Qualifizierungsdossier für die CSF-Förderung der OFPPT, also die Contrats Spéciaux de Formation der marokkanischen Berufsbildungsbehörde, ist in Arbeit. Um die passende Schulung zu wählen oder auf Basis eines Kompetenzaudits ein maßgeschneidertes Programm zu entwickeln, kontaktieren Sie uns.

Häufige Fragen

Kann man während eines Projekts von Scrum zu Kanban wechseln?

Ja, das ist häufig, wenn ein Produkt von der Entwicklung in die Wartung übergeht. Behalten Sie das bestehende Board, ergänzen Sie WIP-Limits und explizite Regeln und lockern Sie die Sprints, sobald sich der Fluss stabilisiert hat. Halten Sie an einer regelmäßigen Retrospektive fest: Sie ist oft das erste Ritual, das wegfällt, obwohl gerade sie es ermöglicht, den Übergang zu korrigieren.

Eignet sich Kanban auch für ein Team außerhalb der IT?

Ja. Kanban setzt weder Code noch Software voraus: Es genügt Arbeit, die erkennbare Schritte durchläuft. Ein HR-Team, das Einstellungen betreut, ein Einkauf oder ein Marketingteam können ihren Fluss visualisieren, die laufende Arbeit begrenzen und ihre Durchlaufzeiten verfolgen. Für Bereiche außerhalb der IT ist es oft der einfachste Einstieg in die Agilität.

Braucht ein Kanban- oder Scrumban-Team einen Scrum Master?

Kanban schreibt keine Rolle vor, also auch keinen Scrum Master. In der Praxis muss jedoch jemand darauf achten, dass die WIP-Limits eingehalten werden, das Review des Flusses moderieren und die Verbesserungsmaßnahmen vorantreiben. Behält das Team im Scrumban die Scrum-Events bei, ist es weiterhin sinnvoll, einer Person die Verantwortung für deren Effektivität zu übertragen.

Welche Schulung ist die richtige: Scrum oder Kanban?

Diejenige, die der tatsächlichen Arbeit des Teams entspricht. Eine Scrum-Schulung richtet sich an Product Owner, Scrum Master oder die Developers eines Produktteams. Eine Kanban-Schulung richtet sich eher an Verantwortliche für Support, IT-Betrieb oder interne Services. In einer gemischten Organisation verhindert eine Schulung der Führungskräfte in beiden Methoden, dass die Methodenwahl zum Glaubenskrieg wird.