„Wir haben Scrum eingeführt – aber irgendwie passt es noch nicht ganz.“ Oder umgekehrt: „Kanban funktioniert gut, aber uns fehlt die Orientierung.“
Solche Rückmeldungen tauchen häufig erst einige Wochen nach der Einführung einer neuen Methode oder eines Frameworks auf. Am Anfang verbessert sich vieles: Die Transparenz steigt, Prioritäten werden klarer, Abstimmungen strukturierter. Doch mit der Zeit zeigt sich, dass nicht jede Aufgabe gleich gut funktioniert. Manche passen perfekt in Iterationen, andere lassen sich schlicht nicht planen.
Das liegt selten daran, dass das Team falsch arbeitet. Meist liegt es daran, dass im Projekt mehrere Arten von Arbeit gleichzeitig existieren. Genau an diesem Punkt beginnen viele Teams, Elemente aus Scrum und Kanban zu kombinieren.
Warum ein Framework allein oft nicht ausreicht
Scrum strukturiert komplexe Entwicklung. Kanban stabilisiert den kontinuierlichen Arbeitsfluss. In der Realität treten beide Gegebenheiten oft gleichzeitig auf. Ein Team entwickelt neue Funktionen und reagiert gleichzeitig auf Fehler, Rückfragen oder kurzfristige Anforderungen. Wird alles in Sprints organisiert und diese Planung geschützt und beibehalten (wie in Scrum gute Praxis ist), kann eine sofortige Reaktionsfähigkeit nicht gegeben sein. Wird alles frei behandelt, kann Chaos und Arbeitsstau entstehen. Weder Scrum noch Kanban geben abschließende Orientierung, wie sich dieses Spannungsfeld auflösen lässt – hier braucht es Kombinationsgeist mit Fingerspitzengefühl für die individuelle Situation eines Teams.
Beispiel aus der Praxis
Ein Softwareentwicklungs-Team arbeitet in zweiwöchigen Sprints an neuen Features. Gleichzeitig trudeln täglich Bugmeldungen und dringende Kundenanfragen ein. Die Folge: Der Sprint wird ständig gestört, Sprintziele werden regelmäßig verfehlt – nicht weil das Team schlecht arbeitet, sondern weil zwei unterschiedliche Arbeitstypen mit demselben Ansatz gesteuert werden.
Hybride Arbeitsweisen entstehen genau so häufig aus praktischer Notwendigkeit. Wie die grundsätzliche Entscheidung zwischen den beiden Ansätzen getroffen werden kann, zeige ich im Artikel Scrum oder Kanban: Wann passt welcher Ansatz?
Häufig geistert der Begriff “Scrumban” für die Kombination von Scrum mit Kanban umher – doch wofür steht dieser?
Was Scrumban eigentlich bedeutet
Scrumban ist kein eigenständiges Framework mit Zertifizierung und Regelwerk. Der Begriff entstand ursprünglich als Übergangsstrategie für Teams, die von Scrum zu Kanban wechseln wollten und hat sich seitdem als Beschreibung für eine ganze, eher undefinierter Klasse hybrider Arbeitsweisen etabliert.
Was Scrumban in der Praxis meint, oder zumindest meinen sollte (wenn der Begriff sorgfältig verwendet wird): Planung bleibt bestehen, aber Aufgaben bewegen sich kontinuierlich durch den Prozess. Iteration und Flow schließen sich nicht aus – sie werden bewusst verbunden. Eine gute Einführung in die Grundunterschiede zwischen beiden Ansätzen bietet übrigens der Vergleichsartikel Kanban oder Scrum.
Merksatz: Scrumban ist idealerweise kein Kompromiss zwischen zwei Methoden, sondern eine bewusste Entscheidung: Welche Arbeit braucht Struktur – und welche braucht Fluss?
Wie Scrumban konkret aussehen kann
In der Praxis zeigen sich wiederkehrende Muster. Hier sind drei, die besonders häufig auftauchen:
Muster 1: Sprints mit Kanban-Visualisierung
Ein Team plant weiterhin in zweiwöchigen Iterationen. Die Arbeit wird jedoch nicht nur als Sprintziel betrachtet, sondern als Fluss visualisiert. Das Board zeigt, wo Aufgaben stehen und wo sich Arbeit staut. WIP-Limits (Begrenzung der gleichzeitig erledigten Arbeit) verhindern, dass einzelne Arbeitsschritte überlaufen.
Der Vorteil: Die Planung bleibt stabil, Engpässe werden früher sichtbar – noch während des Sprints, nicht erst in der Retrospektive.
Beispiel aus der Praxis
Ein Produktteam nutzt ein Sprint-Board mit Atlassian Jira, setzt sich aber zusätzlich WIP-Limits pro Spalte. In der dritten Woche fällt auf: In der Spalte „In Review“ stauen sich regelmäßig 5–6 Aufgaben. Das Team reduziert den WIP-Limit auf 3 und etabliert ein tägliches kurzes Review-Pairing. Die durchschnittliche Umsetzungszeit sinkt in der Folge messbar, da sich der Fokus im Sprint auf einzelne Themen erhöht.
Muster 2: Zwei parallele Bereiche auf einem Board
Ein Entwicklungsteam arbeitet in Sprints, während Support- oder Betriebsarbeit kontinuierlich erfolgt. Beides läuft über ein gemeinsames Board – aber in getrennten Abschnitten (“Swimlanes”). Neue, ungeplante Aufgaben können so aufgenommen werden, ohne die gesamte Sprintplanung zu gefährden.
Der Effekt: Weniger Diskussionen über „unterbrochene Sprints“, mehr Klarheit über tatsächliche Kapazität. Das Team weiß von Anfang an und plant dies ein: Ein Teil der Kapazität gehört dem Unvorhergesehenen.
Beispiel aus der Praxis
Ein Kundenplattform-Team reserviert in jedem Sprint bewusst 20% der Kapazität für dringende Ad-hoc-Aufgaben. Diese laufen auf dem Board in einer eigenen Spur. Ergebnis: Die Feature-Entwicklung bleibt planbar, und Kundenanfragen werden trotzdem schnell bedient – ohne dass beides miteinander konkurriert.
Muster 3: Schlanke Meetings – aber kein Wegfall
Viele Teams behalten kurze tägliche Abstimmungen bei, reduzieren aber starre Routinen. Retrospektiven finden beispielsweise monatlich statt nach jedem Sprint und werden so effektiv abgehalten, dass zusätzliche Abstimmungen reduziert werden können. Planung bleibt erhalten, Feedbackzyklen ebenso – aber besser angepasst an den Rhythmus der Arbeit.
Wichtig: Das bedeutet nicht, Meetings einfach wegzulassen. Es bedeutet, sie an den Arbeitsfluss bestmöglich anzupassen. Für verteilte Teams ist das ein besonders relevanter Hebel – mehr dazu im Artikel 5 Tipps für Remote-Teams.
Quick-Check: Wann welche Anpassung sinnvoll ist
Hier eine Übersicht, die bei der Entscheidung helfen kann, ob und wie ein hybrides Modell mit Elementen aus Scrum und aus Kanban sinnvoll ist:
| Eher Scrum-Struktur behalten | Eher stärker in Richtung Flow |
| Viel planbare Feature-Entwicklung | Viel ungeplante, reaktive Arbeit |
| Stabile Teamzusammensetzung | Wechselndes Team oder unsichere Ressourcen |
| Klarer Produktfokus mit gepflegtem Backlog | Support, Betrieb oder Wartung dominieren |
| Regelmäßige Stakeholder-Reviews gewünscht | Schnelle Einzellieferungen wichtiger als Taktung |
| Team braucht Orientierung und Rhythmus | Team will maximale Flexibilität |
Kein Kriterium allein ist entscheidend. Wichtig ist der Gesamtblick: Wie viel der täglichen Arbeit ist planbar – und wie viel nicht? Alles, was nicht eindeutig beantwortet werden kann, sondern irgendwo dazwischen: Hier können Kombinationen der Elemente aus Scrum und Kanban besonders wirksam sein (Hinweis: Dazu am besten eine gute Begleitung in Form eines erfahrenen Coaches suchen).
Faustregel: Wenn mehr als 30% der täglichen Arbeit nicht aus dem Sprint-Backlog stammt, lohnt es sich zu prüfen, ob die aktuelle Arbeitsweise noch zur Realität des Teams passt.
Praxisbeispiel: Wenn Planung auf Realität trifft
Ein Unternehmen entwickelt eine neue Kundenplattform. Das Team arbeitet zunächst streng nach Scrum – jede Aufgabe im Sprint geplant, das Sprintziel fest definiert.
Nach einigen Wochen zeigt sich: Täglich kommen Sonderfälle. Kundendaten müssen kurzfristig angepasst werden, bestimmte Nutzer brauchen sofortige Lösungen. Die Sprintplanung wird regelmäßig gestört – obwohl das Team effizient arbeitet.
Das Team entscheidet sich nicht gegen Scrum, sondern für mehr Transparenz:
- Features bleiben geplant und laufen im Sprint wie bisher
- Dringende Aufgaben erhalten eine eigene Swimlane mit einem WIP-Limit von 2
- In der Sprintplanung wird bewusst ein Puffer von 15–20 % eingeplant
- Die Retrospektive analysiert regelmäßig das Verhältnis von geplanter zu ungeplanter Arbeit
Die Folge: weniger Konflikte über Prioritäten, ein realistischerer Blick auf den Arbeitsaufwand und ein Team, das endlich aufgehört hat, sich für „unterbrochene Sprints“ zu entschuldigen.
Wann eine Kombination aus Scrum und Kanban besonders sinnvoll wird
Eine Kombination hilft besonders, wenn mehrere Arbeitsmodi gleichzeitig existieren:
- Produktentwicklung plus Wartung
- Projektarbeit plus Support
- Planbare Releases plus kurzfristige Anforderungen
- Neuentwicklung plus laufender Betrieb
Je stärker ein Produkt in den Betrieb übergeht, desto häufiger entsteht diese Mischung. Strenges Festhalten am Framework wie zu Entwicklungsbeginn wirkt sich dann oft nicht flexibel oder nicht genug an die Situation angepasst aus.
Wichtig: Es geht nicht darum, Regeln etwa von Scrum einfach wegzulassen. Es bedeutet, verschiedene Arten von Arbeit sichtbarer zu machen und bewusst zu steuern.
Teams sollten sich regelmäßig folgende Fragen stellen:
- Welche unserer Arbeit ist planbar – und welche ist reaktiv?
- Wie viel Kapazität braucht jede Arbeitsart?
- Welche Meeting-Formate passen noch zu unserem Rhythmus?
- Wo entstehen Engpässe – und woran erkennen wir sie frühzeitig?
Nicht weniger Struktur ist das Ziel – sondern passende Struktur. Wer verschiedene Elemente einführt und kombiniert, sollte das explizit besprechen und dokumentieren, damit alle im Team dieselbe Vorstellung davon haben, wie zusammengearbeitet wird.
Fazit
“Scrum oder Kanban” ist selten die eigentliche Frage. Diese lautet vielmehr: “Welche Art von Arbeit haben wir gerade und was braucht sie?”
Planbare Entwicklung profitiert von Struktur. Kontinuierliche Aufgaben profitieren von Flow. Viele Teams brauchen beides gleichzeitig – und genau dafür bietet eine Kombi aus Scrum und Kanban einen pragmatischen Rahmen.
Hybride Arbeitsweisen sind kein Kompromiss und kein Zeichen dafür, dass etwas „gescheitert“ ist. Sie sind eine bewusste Entscheidung, die Arbeitsweise regelmäßig an Realität und Ziele anzupassen. Agilität entsteht nicht durch das Befolgen eines Modells, sondern durch reflektiertes Arbeiten.
FAQ – Scrum, Kanban und hybride Arbeitsweisen
Kann man Scrum und Kanban gleichzeitig nutzen?
Ja. Häufig planen Teams Features in Sprints und steuern ungeplante Aufgaben über ein kontinuierliches Board mit WIP-Limits. Entscheidend ist, dass beide Boardbereiche für das gesamte Team sichtbar und transparent sind und klar ist, nach welchen Regeln priorisiert wird.
Wann sollte ein Team darüber nachdenken, kombinierte Elemente aus Scrum und Kanban einzuführen?
Wenn regelmäßig ungeplante Aufgaben Sprintziele verdrängen oder Planung und Realität sichtbar auseinanderlaufen, kann die Ursache auch darin liegen, dass mehrere Arbeitstypen parallel existieren. Das ist dann kein Versagen des Frameworks, sondern ein Signal, dass die Arbeitsweise angepasst werden sollte.
Was ist “Scrumban” genau?
Das Konzept von “Scrumban” beschreibt eine mögliche Kombination aus strukturierter Planung (Scrum) und kontinuierlicher Flusssteuerung (Kanban), ohne ein eigenes starres Regelwerk zu definieren. Der Begriff ist eher beschreibend als normativ – er sagt, was Teams tun, nicht wie sie es exakt tun sollen.
Macht dies Scrum überflüssig?
Nein. Die Struktur bleibt erhalten. Sie wird lediglich ergänzt, um besser zur tatsächlichen Arbeitsweise zu passen. Scrum mit Kanban ist kein Ausstieg aus Scrum, sondern eine Erweiterung.
Sollte man direkt mit der Kombination aus Scrum und Kanban starten?
In der Regel hilft es, zunächst ein Framework kennenzulernen und zu verstehen, wie und warum es funktioniert. Eine Kombination entsteht sinnvoll, sobald echte Arbeitsmuster sichtbar werden – und das Team eine fundierte Basis hat, von der aus es bewusst anpasst.
Wie messe ich, ob mein Ansatz funktioniert?
Achtet auf konkrete Signale: Werden Sprintziele häufiger erreicht? Sinkt die Cycle Time (Umsetzungsdauer) für ungeplante Aufgaben? Gibt es weniger Konflikte über Prioritäten? Werden Retrospektiven wieder produktiver? Das sind verlässlichere Indikatoren als das Gefühl, „agiler“ zu sein.
