„Wir wollen agil(er) arbeiten, aber mit welchem Ansatz starten wir? Mit Scrum oder mit Kanban – oder ganz anders?“
Diese Frage höre ich oft in meiner Arbeit als Scrum Master und Agile Coach. Und die schlechte Nachricht: Es gibt keine pauschale Antwort, die für alle Teams passt.
Die gute Nachricht: Es gibt klare Kriterien und konkrete Situationen, die bei der Entscheidung helfen. Wer die richtigen Fragen stellt und die Rahmenbedingungen seines Teams kennt, kann eine fundierte Wahl treffen.
Die Entscheidung: Keine Glaubensfrage, sondern eine Frage der Voraussetzungen
In der Theorie klingen beide Ansätze gut. Scrum verspricht einen Rahmen mit logischem Aufbau und klaren Verantwortlichkeiten. Kanban bietet einen flexiblen Ansatz mit (bei guter Anwendung) besserem, kontinuierlichen Fluss. Beide wecken Hoffnungen auf weniger Abstimmungsmeetings. In der Praxis zeigt sich: Die Entscheidung hängt von sehr konkreten Faktoren ab.
Bevor wir uns die einzelnen Szenarien ansehen, lohnt sich ein Blick auf die wichtigsten Entscheidungskriterien. Dazu könnt ihr euch als Team folgende Fragen stellen:
Wie stabil ist euer Team?
Scrum-Teams profitieren davon, wenn sie fest und idealerweise auch schon eingespielt sind, mit klaren Verantwortlichkeiten und längerfristiger Perspektive. Wenn das Team oft wechselt oder Ressourcen generell unsicher sind, kann Scrum schlechter funktionieren und eventuell Kanban der passendere Ansatz sein.
Wie planbar ist eure Arbeit?
Scrum funktioniert besser bei klaren, gut gepflegten Product Backlogs und einer Planbarkeit für zumindest den Zeitraum einer Iteration (eines Sprints). Kanban eignet sich hingegen gut bei kontinuierlichem, aber unvorhersehbarem Input — etwa, wenn euer Team viel mit Support, Betrieb, Bugs und ähnliche Aufgaben, die ungeplant hereinkommen, beschäftigt ist.
Wie viel Zeit habt ihr für Abstimmung?
Scrum bringt feste Events mit sich: Planning, Daily, Review, Retrospektive. Auch wenn diese den Abstimmungsbedarf bereits auf ein notwendiges Minimum reduzieren sollen – wer selbst dafür wenig Zeit hat oder stark verteilt arbeitet, kann von einem Kanban-Setup mit weniger eingeplanter Meetingzeit bereits profitieren – wenn auch vielleicht mit Einbußen, da natürlich Abstimmungsmöglichkeiten verloren gehen.
Was wollt ihr erreichen?
Mehr Fokus, bessere Vorhersagbarkeit für die Zeiträume von ein oder zwei Sprints, klare Verantwortlichkeiten, effektive Zielsetzung- und -erreichung, Lernzyklen in komplexen Umgebungen? Dann eher Scrum.
Mehr Flow, kürzere Durchlaufzeiten, flexible Steuerung, effizientere Zusammenarbeit? Dann können Euch zwar beide Ansätze helfen, aber Kanban kann je nach Beantwortung der anderen Fragen schon sehr viele Vorteile bringen.
Wann Scrum die richtige Wahl ist
Scrum entfaltet seine Stärken besonders in folgenden Szenarien:
1. Komplexe Produktentwicklung mit vielen Beteiligten
Wenn ein Team an einem komplexen Produkt oder Feature arbeitet und regelmäßige Planung und Feedback wichtig sind, bietet Scrum den idealen Rahmen. Die Sprint-Struktur hilft, komplexe Anforderungen in überschaubare Häppchen zu zerlegen und schrittweise Ergebnisse zu liefern.
Beispiel aus der Praxis: Ein Start-up entwickelt eine neue Finanz-App. Das Entwicklungsteam arbeitet in zweiwöchigen Sprints. Jeder Sprint endet mit einem Review, bei dem das Team neue Features direkt mit ersten Nutzern testet. Das Feedback fließt in den nächsten Sprint ein. So kann das Team schnell lernen und Anpassungen vornehmen, ohne monatelang in die falsche Richtung zu entwickeln.
2. Feste Taktung
Scrum bringt einen stabilen Arbeitsrhythmus ins Vorhaben des Teams. Mit regelmäßigen Sprints (z.B. immer 2 oder 3 Wochen lang – mehr als 4 sollten es laut Scrum Guide nicht sein) und Reviews stellen sich Teams so auf, dass sie kontinuierlich Neues liefern, und der Fortschritt lässt sich besonders nach den ersten Sprints immer besser einschätzen. Das ist auch dann wertvoll, wenn externe Stakeholder auf Zusagen angewiesen sind.
Beispiel aus der Praxis: Ein E-Commerce-Unternehmen bereitet sich auf die Weihnachtssaison vor. Das Team muss bis Ende Oktober neue Payment-Optionen und verbesserte Checkout-Prozesse live bringen. Mit Scrum kann das Team in 2-Wochen-Sprints arbeiten, am Ende jedes Sprints den Fortschritt zeigen und transparent machen, ob der Termin gehalten werden kann. Wenn nicht, können sie gemeinsam mit ihren Stakeholdern schnell sprechen und, wenn notwendig, gegensteuern.
3. Cross-funktionale Teams mit hoher Autonomie
Scrum funktioniert am besten mit Teams, die gemeinsam Verantwortung übernehmen, schnell auf Feedback reagieren können und ihre Arbeit weitgehend selbst organisieren. Die klaren Verantwortlichkeiten im Team (Product Owner, Scrum Master, Developers) schaffen Orientierung, ohne Mikromanagement zu betreiben. Gleichzeitig verteilen sie die vielen verschiedenen Perspektiven der Teamarbeit auf unterschiedliche Schultern, so dass sich alle auf ihren Aufgabenbereich konzentrieren können.
Beispiel aus der Praxis: Ein Softwarehaus entwickelt eine neue CRM-Lösung. Das Team besteht aus Frontend-Entwicklern, Backend-Entwicklern, UX-Designern und QA-Testern. Alle sitzen im selben Scrum-Team als “Developers” und arbeiten gemeinsam an User Storys aus dem Backlog. Durch die Scrum Daily Events jeden Morgen sieht jeder, woran die anderen gerade arbeiten, ob sie Unterstützung brauchen, und ob es Abhängigkeiten geben könnte.
4. Notwendigkeit für regelmäßige Lern- und Verbesserungszyklen
Wenn sich das Produkt dank Kundenfeedback zwar inhaltlich weiterentwickelt und nur langsam Form annimmt, das Team aber trotzdem eine klare Struktur für Releases braucht, ist Scrum ein gut geeigneter Rahmen. Ganz wichtig dabei: Die Retrospektive am Ende jedes Sprints, die dafür sorgt, dass das Team nicht nur am Produkt, sondern auch an der eigenen Arbeitsweise feilt.
So startet Ihr mit Scrum:
- Team sowie Sprintplanung aufsetzen und Sprintdauer festlegen (z.B. 2-Wochen-Zyklen mit klaren Zielen)
- Backlog mit ersten User Storys erstellen und priorisieren (digital z.B. mit Atlassian Jira, Azure DevOps oder anderen Tools – gerne auch auf Zetteln an einem Whiteboard)
- Daily Scrums für die Team-Synchronisation aufsetzen
- Sprint-Reviews (mit Stakeholdern) und Retrospektiven (mit dem Team) für kontinuierliche Verbesserungen etablieren
- Backlog kontinuierlich verfeinern
Beispiel für Scrum-Board in Atlassian Jira mit Sprintziel (Cloud)
Wann Kanban eine gute Wahl ist
Die Wahl zwischen den Ansätzen ist nicht immer klar vorzugeben. Die Kanban-Methode zeigt aber ihre Stärken besonders in teilweise anderen Situationen:
1. Kontinuierlicher, unvorhersehbarer Arbeitsfluss
Wenn Aufgaben kontinuierlich und unvorhersehbar hereinkommen — ohne dass sich feste Iterationen sinnvoll planen lassen — ist Kanban ein idealer Ansatz. Die Methode sorgt für klaren Überblick und konzentriert sich darauf, dass die Arbeit fließt und Engpässe erkannt und beseitigt werden.
Beispiel aus der Praxis: Ein IT-Support-Team bearbeitet täglich zwischen 20 und 100 Tickets — von einfachen Passwort-Resets bis zu komplexen Systemausfällen. Mit Kanban visualisiert das Team alle offenen Tickets auf einem Board. Sobald die Spalte „In Progress“ zu voll wird, ist sofort klar: Es gibt einen Engpass. Das Team kann dann gemeinsam entscheiden, ob Prioritäten verschoben oder zusätzliche Ressourcen aktiviert werden müssen. Sie können auch Spaltenbegrenzungen (“WIP-Limits”) einführen, um ein Überlaufen zu vermeiden.
Beispiel-WIP-Limit (Einstellung in einem Kanban-Board in Atlassian Jira)
2. Wechselnde Prioritäten und häufige Ad-hoc-Anfragen
Wenn Anforderungen sich ständig ändern, bietet Kanban die Flexibilität, Aufgaben schnell neu zu priorisieren, ohne den Arbeitsfluss zu sehr zu stören. Vielleicht auch, weil das Team eher im Produkt-Betriebsmodus als an der Neuentwicklung arbeitet.
Beispiel aus der Praxis: Ein Migrationsteam überführt über 1.000 Kundendatensätze aus Altsystemen in eine neue Plattform — parallel zum laufenden Betrieb. Täglich kommen neue Anforderungen von Kunden, die dringend bestimmte Daten benötigen. Mit Kanban kann das Team flexibel reagieren: Dringende Aufgaben wandern nach oben im Backlog, werden gezogen, sobald Kapazität frei wird, und das Team behält durch WIP-Limits den Überblick.
3. Fokus auf Durchsatz (engl. Throughput) und kürzere Zykluszeiten (Cycle Times)
Wenn es darum geht, möglichst schnell möglichst viele Aufgaben abzuarbeiten — und weniger darum, komplexe Features schrittweise zu entwickeln — kann Kanban gut glänzen. Die Metriken Cycle Time (wie lange braucht eine Aufgabe vom Start bis zum Abschluss?) und Throughput (wie viele Aufgaben schaffen wir pro Woche?) helfen, die Effizienz zu steigern. Scrum-Teams, die hiervon ebenfalls profitieren möchten, finden dazu übrigens hier wertvolle Tipps.
Beispiel aus der Praxis: Ein Wartungsteam ist verantwortlich für kleinere Updates und Bugfixes an einer etablierten Software. Mit Kanban trackt das Team seine Cycle Time und stellt fest: Bestimmte Arten von Tickets dauern systematisch länger. Das Team führt eine neue Regel ein: Komplexere Tickets werden vorher in kleinere Teilaufgaben zerlegt. Ergebnis: Die durchschnittliche Cycle Time sinkt um 30%.
4. Teams mit wenig Zeit für Meetings
Kanban schreibt per se weder Rollen noch feste Meetings / Events vor. Teams, die stark verteilt arbeiten oder wenig Zeit für Besprechungen haben, können mit einem schlanken Kanban-Setup trotzdem von mehr Transparenz in ihrer Arbeit profitieren.
So setzt ihr euren Kanban-Ansatz um:
- Überlegt euch, wer euer Team darstellt und denkt dabei auch an euren Wertstrom – wo braucht ihr mehr Transparenz und bessere Arbeitsorganisation?
- Nutzt ein physisches Board oder digitale Tools wie Trello, Jira oder Asana
- Visualisiert alle Aufgaben und Phasen und überlegt euch einen sinnvollen Prozess für den Arbeitsfluss (z.B. „To Do“, „In Progress“, „Review“, „Done“)
- Beobachtet Arbeitsstaus und reagiert darauf
- Bonus: Messt regelmäßig Cycle Time und Throughput, um Verbesserungspotenziale zu erkennen
- Bonus: Definiert klare Work-in-Progress-Limits für jede Spalte, um Fokus zu behalten – am besten ist es, wenn das Team dies nach einiger Zeit von sich aus einfordert, weil die Notwendigkeit gesehen wird. Kanban lebt von evolutionärer Verbesserung aus dem Team heraus
- Bonus: Trefft euch immer wieder zu Retrospektiven, in denen ihr eure Arbeitsweise und Verbesserungen gemeinsam beleuchtet
Entscheidungshilfe Scrum oder Kanban: Der Quick-Check
Hier eine kompakte Übersicht, die bei der Entscheidung helfen kann:
Scrum passt gut, wenn:
- Ihr an komplexen Produkten oder Features arbeitet
- Regelmäßige, iterative Planung und Feedback wichtig sind
- Ihr Sprints braucht, um Ergebnisse fokussierter zu liefern
- Ihr in einem cross-funktionalen Team arbeitet
- Regelmäßige Events (Dailys, Retrospektiven) für euch sinnvoll sind
Kanban passt gut, wenn:
- Ihr mit anderen Abteilungen mehr Austausch sucht
- Aufgaben kontinuierlich und ungeplant hereinkommen und Prioritäten sich häufig ändern
- Ihr flexibel auf Ad-hoc-Anfragen reagieren müsst
- Das Team wenig Zeit für Besprechungen hat
- Ihr an Support, Wartung, Betrieb oder Migration arbeitet
Und was ist mit Kombinationen?
In der Realität halten sich Teams selten strikt an nur ein Framework. Viele kombinieren Elemente aus Scrum und Kanban, etwa Sprints mit Kanban-Boards, oder feste Events mit flexiblem Flow. Doch das ist ein eigenes Thema, dem wir uns im nächsten Artikel widmen werden.
Wichtig: Nicht dogmatisch entscheiden
Die Wahl zwischen Scrum und Kanban ist kein Bekenntnis fürs Leben. Viele Teams starten zunächst mit einem Ansatz und passen ihre Arbeitsweise im Laufe der Zeit an.
Beispiele aus der Praxis:
- Teams starten mit Kanban, weil es niedrigschwelliger ist und wechseln später zu Scrum, weil sie doch vom zielorientierten Arbeiten in Sprints profitieren können
- Produktentwicklungs-Teams arbeiten mit Scrum, wechseln dann zu Kanban, wenn sie von einem Neuentwicklungs- eher in eine Art Betriebsmodus ihres Produkts übergehen
- Teams bleiben bei Scrum, wenden aber Kanban-Praktiken wie WIP-Limits oder Cycle Time-Messung an
Das Wichtigste: Testet, sprecht drüber, lernt. Seid bereit, eure Arbeitsweise anzupassen, wenn sich die Rahmenbedingungen ändern. Sucht euch erfahrene Begleitung.
Fazit
Die Entscheidung zwischen Scrum und Kanban ist keine Glaubensfrage, sondern eine Frage der Voraussetzungen und Ziele. Wer von der Taktung und Struktur profitieren kann, fährt mit Scrum sehr gut. Wer dagegen besonders viel Flexibilität benötigt und mit wechselnden Prioritäten bei ständigem Anforderungseingang auf einen guten Arbeitsfluss setzen möchte, ist mit Kanban gut bedient.
Am Ende geht es nicht darum, das „richtige“ Framework zu finden, sondern ein Arbeitsmodell zu entwickeln, das zum Team, zum Produkt und zu den Rahmenbedingungen passt und das sich mit den Anforderungen weiterentwickelt.
Scrum oder Kanban sind keine “Patentrezepte” für Agilität, sondern Werkzeuge, die ihre Wirkung nur im passenden Kontext entfalten. Entscheidend ist nicht, welchem Ansatz ihr folgt, sondern wie gut eure Arbeitsweise zu eurem Team, euren Zielen und euren Rahmenbedingungen passt. Wer strukturiert lernen, planen und liefern will, findet mit Scrum einen starken Rahmen. Wer mit hoher Dynamik, wechselnden Prioritäten und kontinuierlichem Arbeitsfluss umgehen muss und dabei hohe Transparenz möchte, ist mit Kanban oft gut beraten. Erfolgreiche Teams bleiben dabei neugierig, reflektieren regelmäßig und entwickeln ihr Vorgehen weiter – statt sich starr an ein Modell zu klammern.
FAQ: Scrum oder Kanban. Wann passt welches Framework?
Kann man Scrum und Kanban gleichzeitig nutzen?
Ja, und das ist sogar sehr verbreitet. Viele Teams arbeiten in Sprints und nutzen ein einfaches Kanban-Board zur Visualisierung der Arbeit im Sprint, in dem sie auch WIP-Limits einsetzen. Andere kombinieren Scrum für geplante Feature-Entwicklung mit Kanban für ungeplante Support-Aufgaben. Wichtig ist nur, dass alle im Team verstehen, wie zusammengearbeitet wird.
Wie entscheide ich, wenn mein Team völlig neu ist?
Für neue Teams und/oder solche, die mit agilen Arbeitsweisen noch nicht sehr vertraut sind, kann Scrum mit seinen klaren Rollen und Events Orientierung geben. Allerdings sollte das Team nicht überfordert werden und verstehen, wie und warum es so arbeitet — dann ist es wichtig, dass das Team vom Scrum Master gut begleitet wird. Kanban kann eine Alternative sein, wenn das Team schon sehr selbstorganisiert arbeitet – oder auch, um dieses zunächst zu fördern. Hier kann auch zunächst mit dem Notwendigsten (Board, Arbeitsablauf) gestartet und dann nach und nach die Methode erweitert und verfeinert werden.
Was mache ich, wenn das Team sich nicht einigen kann?
Testet beide Ansätze für jeweils 4 Wochen und entscheidet dann gemeinsam. Dokumentiert dabei: Was lief gut? Was war schwierig? Was hat gefehlt? Diese Erfahrungswerte sind oft aussagekräftiger als theoretische Überlegungen.
Muss ich den Scrum Guide oder die Kanban-Prinzipien zu 100% umsetzen?
Gerade am Anfang ist es sinnvoll, sich an den Grundprinzipien zu orientieren und diese zunächst zu verstehen. Teams dürfen (und sollen) ihre Arbeitsweise anpassen, gerade bei Kanban ist diese Grundidee auch in die Methode eingebaut. Wer Dinge aus dem Scrum Guide weg lässt oder verändert, riskiert eine Verwässerung des Ansatzes, aber dennoch sollte jeder Start mit Scrum natürlich mit Bedacht und Umsicht vonstatten gehen. Wichtig ist nur: Reflektiert regelmäßig, ob eure Arbeitsweisen noch sinnvoll sind und wo es Verbesserungspotential gibt.
Wie erkenne ich, ob unser aktueller Ansatz noch passt?
Achtet auf Warnsignale: Fühlen sich Meetings und Austausche wie Zeitverschwendung an? Werden Sprintziele regelmäßig nicht geschafft oder sind sie kaum noch planbar aufgrund zu vieler Ad-Hoc-Themen? Staut sich die Arbeit an bestimmten Stellen? Gibt es häufige Konflikte über Prioritäten? Solche Anzeichen können bedeuten, dass die gewählte Arbeitsweise, aber oft auch die Ausgestaltung dieser, Optimierungsbedarf hat.
Was, wenn mein Unternehmen (oder bei externer Mitarbeit auch: Unternehmskunde) auf einen bestimmten Ansatz besteht?
Manche Unternehmen haben Standards (z.B. „alle agilen Teams bei uns arbeiten mit Scrum“). Das kann aber in manchen Situationen hinderlich sein. Versucht in diesem Fall, so viel Flexibilität wie möglich zu schaffen — zum Beispiel durch die Anpassung von Sprint-Längen oder durch die Kombination mit Kanban-Elementen.
