Was ist "Scrumban"?

Scrumban ist ein hybrides agiles Rahmenwerk, das die Strukturelemente von Scrum mit den Flussprinzipien von Kanban kombiniert. Der Begriff wurde 2009 von Corey Ladas geprägt und beschreibt einen Ansatz, der das Timeboxing und die Rollenverteilung von Scrum mit den Work-in-Progress-Limits (WiP-Limits) und der Pull-Steuerung von Kanban verbindet. Scrumban entstand aus der praktischen Erfahrung, dass weder reines Scrum noch reines Kanban in allen Arbeitskontexten optimal funktioniert, und bietet eine flexible Alternative für Teams, die Elemente beider Methoden nutzen möchten (vgl. Demarmels 2021, S. 2).

Grundprinzipien

Scrumban kombiniert zwei zentrale Mechanismen der agilen Arbeit: Timeboxing aus Scrum und WiP-Limits aus Kanban. Beim Timeboxing wird die Arbeit in feste Zeitabschnitte (Sprints oder Iterationen) gegliedert, an deren Ende ein Review und eine Planung stehen. Die WiP-Limits begrenzen die Anzahl der gleichzeitig bearbeiteten Aufgaben und verhindern so eine Überlastung des Teams. Diese Kombination ermöglicht es, die Vorhersagbarkeit von Scrum mit der Flexibilität von Kanban zu vereinen.

Ein wesentliches Merkmal von Scrumban ist das Pull-Prinzip: Neue Aufgaben werden nicht zu Beginn eines Sprints als festes Paket zugewiesen, sondern vom Team gezogen, sobald Kapazität frei wird. Dies reduziert Leerlaufzeiten und ermöglicht eine gleichmäßigere Auslastung. Das Pull-Prinzip steht in direkter Verbindung zur Pull-Produktion im Lean Management: In beiden Fällen wird die Arbeit durch den nachgelagerten Bedarf gesteuert, nicht durch einen vorgelagerten Plan.

Aufbau und Vorgehensweise

Das Scrumban-Board visualisiert den Arbeitsfluss typischerweise in Spalten wie „To Do“, „Doing“ und „Done“. Jede Spalte kann mit einem WiP-Limit versehen werden, das die maximale Anzahl paralleler Aufgaben festlegt. Der Product Owner pflegt ein priorisiertes Backlog, aus dem das Team eigenständig Aufgaben zieht. Im Unterschied zu reinem Scrum gibt es keine starre Sprint-Planung, bei der alle Aufgaben für die nächste Iteration vorab festgelegt werden.

Die Sprintlänge in Scrumban ist häufig länger als in reinem Scrum oder wird ganz aufgegeben zugunsten eines kontinuierlichen Flusses mit regelmäßigen Planungs- und Review-Terminen. Teams, die von Scrum zu Scrumban wechseln, behalten oft die Sprint-Retrospektive bei, da sie einen strukturierten Rahmen für die Reflexion und Verbesserung der Zusammenarbeit bietet.

Die Retrospektive als Verbesserungsmotor

Die Retrospektive ist ein zentrales Element in Scrumban und bildet die Brücke zum KVP. Am Ende jeder Iteration reflektiert das Team über seine Arbeitsweise und identifiziert Verbesserungspotenziale. In einer Scrumban-Simulation mit LEGO-Bausteinen konnte gezeigt werden, wie Teams nach einer Retrospektive ihre Zusammenarbeit deutlich verbesserten und signifikant mehr Punkte erzielten als in Runden ohne Reflexion (vgl. Demarmels 2021, S. 2). Diese Erfahrung veranschaulicht eindrücklich, wie wichtig strukturierte Reflexionsphasen für die Leistungsfähigkeit agiler Teams sind.

Der Retrospektive-Prozess in Scrumban ähnelt dem PDCA-Zyklus: Die aktuelle Arbeitsweise wird überprüft (Check), Verbesserungsmaßnahmen werden vereinbart (Act), in der nächsten Iteration umgesetzt (Do) und erneut evaluiert. Diese Parallele macht Scrumban besonders anschlussfähig an bestehende Lean-Praktiken in produzierenden Unternehmen, die den PDCA-Zyklus bereits als Grundmuster der Verbesserung nutzen.

Einsatzbereiche

Scrumban eignet sich besonders für Arbeitskontexte, in denen die Anforderungen nicht vollständig planbar sind und sich während einer Iteration ändern können. Typische Einsatzbereiche sind IT-Support-Teams, Wartungs- und Instandhaltungsteams, Produktentwicklungsprojekte mit hoher Unsicherheit sowie Teams, die sowohl geplante Projekte als auch ungeplante Anfragen bearbeiten müssen. In produzierenden Unternehmen findet Scrumban zunehmend Anwendung in administrativen Bereichen wie der Instandhaltungsplanung, dem Projektmanagement und der Produktentwicklung.

Der Ansatz ist auch als Brücke für Teams geeignet, die von Scrum auf Kanban oder umgekehrt umstellen möchten. Durch die schrittweise Anpassung der Sprintlänge und der WiP-Limits kann das Team seinen optimalen Arbeitsmodus finden, ohne die gesamte Arbeitsweise auf einen Schlag zu ändern.

Praxistipp: Starten Sie mit einem einfachen Scrumban-Board mit drei Spalten und einem WiP-Limit von zwei Aufgaben pro Person. Beginnen Sie mit kurzen Iterationen von zwei Wochen inklusive Retrospektive. Passen Sie das System schrittweise an, verlängern oder verkürzen Sie die Iteration und justieren Sie die WiP-Limits basierend auf den Erfahrungen des Teams.

Abgrenzung zu Scrum und Kanban

Reines Scrum arbeitet mit festen Sprints, definierten Rollen (Product Owner, Scrum Master, Entwicklungsteam) und einem Sprint-Backlog, das während der Iteration nicht verändert wird. Reines Kanban verzichtet auf Timeboxing und feste Rollen, steuert den Arbeitsfluss ausschließlich über WiP-Limits und das Pull-Prinzip. Scrumban positioniert sich zwischen diesen beiden Polen: Es behält Timeboxing und regelmäßige Reviews bei, lockert aber die starre Sprint-Planung und führt WiP-Limits als zusätzlichen Steuerungsmechanismus ein. Die Rollen können flexibel gehandhabt werden, der Scrum Master kann etwa die Rolle eines Flow-Managers übernehmen, der auf die Einhaltung der WiP-Limits und die Optimierung des Durchflusses achtet.

Quellenangaben

Demarmels, S. (2021): Agile Spiele, Scrumban mit Retrospektive, in: YOKOTEN 03/2021, S. 2.

Verwandte Konzepte

• Kanban, Visuelles Steuerungssystem mit WiP-Limits und Pull-Prinzip, das in Scrumban integriert wird.
• Pull-Produktion, Bedarfsgesteuertes Prinzip, das sowohl Kanban als auch Scrumban zugrunde liegt.
• PDCA, Verbesserungszyklus, der sich in der Retrospektive von Scrumban widerspiegelt.
• KVP, Kontinuierlicher Verbesserungsprozess, den die Retrospektive in Scrumban systematisch unterstützt.
• Lean Management, Managementphilosophie, deren Pull-Prinzip und Verschwendungsminimierung in Scrumban einfließen.
• Shopfloor Management, Führung vor Ort, die durch agile Elemente aus Scrumban ergänzt werden kann.