Worauf müssen Scrummer bei Kanban achten

Worum es geht

Scrum und Kanban werden oft in einen Topf geworfen. Versteht mich nicht falsch – beide zielen auf bessere Ergebnisse ab. Das Problem ist nur, dass diese Vermischung zu fundamentalen Missverständnissen führt.

Was ich konsistent beobachte ist, dass Scrum-Anwender Kanban oft nur als Visualisierungs-Tool für ihr Backlog sehen oder versuchen, es als nächstes agiles Framework "einzuführen". Dabei geht der eigentliche Hebel verloren: Kanban als evolutionäre Methode für organisatorischen Wandel zu nutzen.

Diese Episode klärt auf: Worauf musst du als Scrummer achten, damit du Kanban sinnvoll für deine Zwecke einsetzt – und dich nicht in den typischen Fallstricken verfängst?

Für wen?

Episoden-Insights

1. Paradigmenwechsel: Vom Arbeiter zum Arbeitsfluss

Scrum steuert empirisch über Timeboxes (Sprints) und fokussiert auf das Team als Einheit. Kanban dreht den Spieß um: Hier steht der Fluss der Arbeit (Workflow) im Zentrum. Metriken wie Durchlaufzeit oder Zykluszeit zeigen, wo sich Staus bilden – unabhängig von der Auslastung der Menschen.

"In Kanban steuern wir die Arbeit und nicht den Arbeiter."

Das bedeutet: Auch bei voll ausgelasteten Teams kann der Fluss stocken. Kanban hilft, diese Engpässe im System sichtbar zu machen und zu beheben, anstatt nur auf Teamvelocity zu schauen.

2. Change-Ansatz: Disruption vs. Evolution

Scrum ist ein Framework, das mit festen Rollen, Events und Artefakten einen klaren, disruptiven Cut zum alten Prozess macht. Das kann kraftvoll sein, stößt aber oft auf Widerstand.

Kanban startet genau dort, wo du heute stehst ("Start with what you do now"). Es werden keine Rollen vorgeschrieben und kein Prozess überstülpt. Stattdessen werden gemeinsam evolutionäre Verbesserungsregeln etabliert, die den aktuellen Workflow schrittweise optimieren. Das ist weniger bedrohlich und führt oft zu nachhaltigerer Veränderung.

"Scrum ist disruptiv, Kanban ist evolutionär."

3. Rollen: Vorgeschrieben vs. emergent

Scrum definiert klare Rollen (Scrum Master, Product Owner, Entwicklerteam) mit spezifischen Verantwortlichkeiten. In Kanban gibt es diese Vorgabe nicht.

Verantwortlichkeiten ergeben sich aus den Service Commitments und den vereinbarten Verbesserungsregeln. Das kann befreiend sein, denn es löst Teams von dem Druck, künstliche Rollenkonflikte ausfechten zu müssen. Führung bleibt notwendig, aber sie ist nicht an eine bestimmte "Master"- oder "Owner"-Rolle gebunden.

"Kanban hat keine Rollen. Und das ist gut so."

Dein nächster Schritt

Agile Begleiter neigen dazu, einen vertrauten Arbeitsmodus – oft Scrum – auf alle Situationen anzuwenden. Der Schlüssel zu effektiver agiler Begleitung liegt jedoch darin, sich mit unterschiedlichen Herangehensweisen auseinanderzusetzen. Nur so kannst du passgenau zum jeweiligen Kontext agieren. Denn wenn du mit einer Herangehensweise scheiterst, hast du mit einer anders gelagerten oft deutlich mehr Chancen.