Scrum oder Kanban: Welche Methode zu welcher Arbeit passt

Scrum passt zu Arbeit, die auf ein Produktziel zuläuft und sich in Sprints von höchstens einem Monat schneiden lässt, Kanban zu Arbeit, die unregelmäßig eintrifft und laufend fertig werden soll. Die Entscheidung folgt der Art des Arbeitseingangs und dem Bedarf an Rückmeldung. Wer sie an sieben Prüffragen trifft, vermeidet den häufigsten Fehler in Einführungen: dieselbe Methode für jede Art von Arbeit.

Dieser Beitrag vergleicht beide Methoden nach ihren Primärquellen, dem Scrum Guide in der Fassung von 2020 und dem Kanban Guide von 2020, und liefert eine Kriterientabelle und eine Prüfliste sowie einen Weg zur Einführung. Er richtet sich an Geschäftsführer und Bereichsleiter, die entscheiden müssen, womit ein Team morgen arbeitet, und die dafür eine begründete Antwort brauchen.

Was unterscheidet Scrum und Kanban?

Scrum gibt einen Rahmen vor, der Rollen, Ereignisse und Artefakte umfasst, Kanban gibt ein Steuerungsprinzip für den Arbeitsfluss vor. Der Scrum Guide beschreibt drei Verantwortlichkeiten: Product Owner, Scrum Master und Developers. Dazu kommen fünf Ereignisse, nämlich der Sprint als Rahmen sowie Sprint Planning, Daily Scrum, Sprint Review und Sprint Retrospective. Die drei Artefakte Product Backlog, Sprint Backlog und Inkrement verbinden sich je mit einer Verpflichtung: das Product Goal, das Sprint Goal und die Definition of Done. Ein Sprint dauert höchstens einen Monat, und am Ende steht ein Inkrement, das im Sinne der Definition of Done fertig ist.

Der Kanban Guide von 2020 beschreibt drei Praktiken: den Arbeitsfluss definieren und sichtbar machen, die Arbeitselemente im Fluss aktiv steuern und den Fluss verbessern. Dazu gehört eine Obergrenze für angefangene Arbeit, das Work-in-Progress-Limit. Der Guide kennt weder Rollen noch feste Zeitabschnitte. Er arbeitet mit vier Messgrößen: der aktuellen Menge angefangener Arbeit, der Durchlaufzeit, dem Durchsatz und dem Alter eines Arbeitselements. Der Zusammenhang dieser Größen folgt dem Gesetz von Little aus dem Jahr 1961: Die durchschnittliche Menge angefangener Arbeit entspricht dem Durchsatz multipliziert mit der durchschnittlichen Durchlaufzeit. Wer mehr gleichzeitig anfängt, wartet bei gleichem Durchsatz länger auf jedes einzelne Ergebnis. Wie sich Flusskennzahlen im Alltag lesen lassen, beschreibt der Beitrag zu Flow Metrics.

Beide Methoden gehen von Transparenz und regelmäßiger Überprüfung aus, und beide verlangen, dass ein Team seine Arbeit sichtbar macht. Der Unterschied liegt im Rhythmus. Scrum nimmt sich jeden Sprint ein Ziel vor und prüft es am Ende, Kanban liefert, sobald ein Element fertig ist, und prüft den Fluss fortlaufend.

Wann passt Scrum und wann Kanban?

Scrum passt, wenn ein Team ein Produkt oder eine Leistung entwickelt, deren Ziel sich in Etappen annähern lässt und deren Ergebnis ein Auftraggeber regelmäßig beurteilen kann. Kanban passt, wenn Arbeit in unregelmäßigen Mengen und mit wechselnder Dringlichkeit eintrifft, etwa im Betrieb, im Support oder in der Wartung von Anlagen und Systemen. Der Arbeitseingang entscheidet, weil ein Sprint eine Planbarkeit voraussetzt, die dort fehlt, wo am Dienstag ein Störfall die Planung vom Montag entwertet.

Eine Entwicklungsabteilung, die ein neues Produkt aufbaut, gewinnt durch Sprints, weil jede Etappe eine Entscheidung über den nächsten Schritt erzwingt. Ein Service-Team, das täglich Anfragen mit wechselnder Priorität bearbeitet, gewinnt durch Limits für angefangene Arbeit, weil sie das Warten sichtbar machen und Eskalationen in eine Reihenfolge bringen. Warum Arbeit so oft liegt statt läuft, beschreibt der Beitrag zu Wartezeiten im Prozess.

Welche Methode passt zu welcher Art von Arbeit?

Vier Arbeitstypen kommen in Unternehmen am häufigsten vor, und jeder hat eine naheliegende Wahl. Produktentwicklung mit einem klaren Auftraggeber und einem Ziel für das Quartal verlangt eine Methode, die Prioritäten festlegt und Ergebnisse prüft, also Scrum. Betrieb und Support mit unvorhersehbarem Eingang verlangen eine Methode, die Reihenfolge und Wartezeit steuert, also Kanban. Projekte mit festem Endtermin und festem Leistungsumfang lassen sich in Etappen schneiden und mit Scrum steuern, sofern der Umfang innerhalb der Etappen verhandelbar bleibt. Auftragsabwicklung mit standardisierten Schritten, etwa Angebote, Bestellungen oder Reklamationen, folgt einem Durchlauf und eignet sich für Kanban.

Fachbereiche außerhalb der Softwareentwicklung profitieren von beiden Methoden: Ein Marketing-Team mit festem Kampagnenstart arbeitet in Sprints, ein Einkaufsteam mit laufenden Bestellanforderungen braucht ein Board mit Limits.

Gemischte Teams gibt es ebenfalls. Ein Produktteam, das neben der Weiterentwicklung auch Störungen im laufenden Betrieb behandelt, kann in Sprints arbeiten und einen festen Anteil der Kapazität für Störungen reservieren. Der Kanban Guide for Scrum Teams, den Scrum.org gemeinsam mit Daniel Vacanti und Yuval Yeret 2021 veröffentlicht hat, beschreibt diesen Weg: Ein Scrum-Team macht seinen Fluss sichtbar, begrenzt die angefangene Arbeit und misst Durchlaufzeit und Alter der Elemente, ohne die Ereignisse des Scrum Guide aufzugeben.

Sieben Prüffragen für die Wahl der Methode

Sieben Fragen führen zu einer begründeten Wahl, wenn ein Team oder ein Bereich gemeinsam darauf antwortet. Fällt die Mehrheit der Antworten auf eine Seite, wählt das Team diese Methode für die nächsten drei Monate und prüft die Wahl danach.

1. Kennt das Team zu Beginn eines Zeitabschnitts von zwei bis vier Wochen das Ziel für diesen Abschnitt? Ja spricht für Scrum, nein für Kanban.
2. Bleibt die Reihenfolge der Arbeit innerhalb eines Abschnitts stabil? Ja spricht für Scrum, ein täglicher Wechsel der Prioritäten spricht für Kanban.
3. Kann ein Auftraggeber oder Nutzer alle zwei bis vier Wochen ein Ergebnis beurteilen? Ja spricht für Scrum, nein oder nur selten für Kanban.
4. Ist die Arbeit in Elemente von ähnlicher Größe zu schneiden? Ja erlaubt Kanban mit Prognosen aus dem Durchsatz, auch Scrum profitiert davon.
5. Gibt es einen Eigentümer des Ergebnisses, der Prioritäten entscheidet und im Alltag erreichbar ist? Nur dann funktioniert Scrum, denn der Product Owner verantwortet die Reihenfolge im Product Backlog.
6. Sind Wartezeiten zwischen Abteilungen das Hauptproblem? Ja spricht für Kanban mit Limits an den Übergängen, weil Wartezeit dort sichtbar wird.
7. Braucht die Geschäftsführung einen Termin für ein Ziel? Ja spricht für Scrum mit Release-Planung, ein Durchsatz-basierter Forecast ist mit Kanban ebenfalls möglich.

Wie führt man Scrum oder Kanban ein?

Die Einführung gelingt in fünf Schritten, die für beide Methoden gelten und sich in der Reihenfolge unterscheiden.

1. Arbeit vermessen: Das Team erfasst vier Wochen lang, welche Arten von Arbeit eintreffen, wie viele Elemente es sind und wie lange sie liegen. Daraus entstehen die Antworten auf die Prüffragen.
2. Methode je Arbeitstyp wählen: Ein Team kann eine Methode führen, ein Bereich mehrere. Die Wahl wird schriftlich festgehalten, mit der Kennzahl, an der sie sich bewähren soll.
3. Rollen und Entscheidungsrechte klären: Bei Scrum werden Product Owner und Scrum Master benannt, bei Kanban wird festgelegt, wer die Limits ändern darf und wer Prioritäten entscheidet.
4. Beginnen: Bei Scrum startet das Team mit einem Sprint von zwei Wochen und einer Definition of Done, bei Kanban mit einem Board, das den tatsächlichen Ablauf zeigt, und einem Limit knapp unter der aktuellen Menge angefangener Arbeit.
5. Nach drei Monaten prüfen: Das Team vergleicht Durchlaufzeit und Durchsatz mit dem Ausgangswert und befragt die Abnehmer und entscheidet über Beibehaltung, Anpassung oder Wechsel.

Wer mit Kanban beginnt, findet den Einstieg im Beitrag zu Kanban einführen. Wer ein Jahr Scrum hinter sich hat und prüfen will, was davon geblieben ist, findet Anhaltspunkte im Beitrag zu Scrum im Mittelstand.

Häufige Fehler bei der Methodenwahl

Drei Fehler wiederholen sich. Erstens wählt ein Unternehmen eine Methode für alle Teams, weil ein einheitlicher Rahmen einfacher zu steuern scheint, und zwingt damit Support-Teams in Sprints und Entwicklungsteams in ein Board ohne Ziel. Zweitens wird Kanban als Scrum ohne Regeln verstanden, obwohl die Limits für angefangene Arbeit eine Disziplin verlangen, die viele Teams anspruchsvoller finden als einen Sprint. Drittens wird Scrum ohne Product Owner eingeführt, sodass niemand im Team die Prioritäten entscheidet und das Backlog zur Wunschliste wird. Die Definition of Done verhindert einen weiteren Fehler beider Methoden: Elemente, die als erledigt gelten, aber noch nicht im Betrieb ankommen.

Methodenwahl mit Niehues Consulting

Niehues Consulting ist eine Beratung für KI-Management und Organisationsdesign aus der Lieferperspektive mit Sitz in Düsseldorf. Gründer Marin Niehues baut Organisationen, die liefern, in Projekten von VC-finanzierten Scaleups bis zu DAX-40-Konzernen und in über 20 Ländern auf sechs Kontinenten. Im Leistungsfeld Delivery Management übernimmt er die Rolle des Delivery Managers, des Projektmanagers oder des Product Owners, im Organisationsdesign legt er Rollen fest und klärt Entscheidungswege.

Das Vorgehen folgt dem Niehues Delivery Model mit drei Phasen. Für die Methodenwahl zählen drei Prüffragen besonders: Wer entscheidet, wer liefert, wer nutzt? Welche Rollen und Entscheidungswege braucht der Betrieb? Welche Kennzahl zeigt nach 90 Tagen, dass die Lösung ankommt? Aus den Antworten entsteht je Team eine begründete Wahl, die an einem Ausgangswert gemessen wird. Umfang und Konditionen eines Vorhabens werden in der kostenfreien Erstberatung besprochen, die Sie über den Kontakt vereinbaren.