Agiles Arbeiten ist längst in Unternehmen aller Größen angekommen. Doch sobald Menschen auf dieses Thema stoßen, taucht eine der häufigsten Fragen auf: Welcher Ansatz passt am besten zur Arbeit des Teams? Und manchmal auch ganz konkret: Scrum oder Kanban?
Beide Ansätze können die Team-Agilität fördern, beide steigern Transparenz und Zusammenarbeit, und beide sind längst bereits in IT wie auch in vielen anderen Bereichen im Einsatz. Trotzdem unterscheiden sie sich grundlegend, etwa in Grundideen, Struktur, Rhythmus und Flexibilität.
Wer die Unterschiede versteht, kann nicht nur die richtige Wahl für sein Team treffen, sondern auch typische Stolperfallen vermeiden.
Scrum: feste Verantwortlichkeiten und ein klarer Takt
Scrum entstand Anfang der 1990er-Jahre. Jeff Sutherland und Ken Schwaber entwickelten das Framework, inspiriert durch ein Harvard Business Review-Paper von Takeuchi und Nonaka („The New New Product Development Game“, 1986). Darin wurde Produktentwicklung als Teamsport beschrieben, bei dem interdisziplinäre Gruppen eng gemeinsam, wie bei einem Rugby-Scrum („Gedränge“), arbeiten.
Wer dem Scrum-Framework folgt, teilt Arbeit in kurze, feste Zyklen: sogenannte Sprints. Ein Sprint dauert meist ein bis maximal vier Wochen. Ziel ist es, am Ende jedes Sprints (manchmal auch Iteration oder Arbeitszyklus genannt) ein potenziell nutzbares Ergebnis zu liefern. Ein neuer Ansatz für viele: statt monatelang vor sich hin zu entwickeln, verpflichten sich Scrum-Teams, früh und häufig echte Ergebnisse zu liefern.
Charakteristisch für Scrum sind die klar definierten Verantwortlichkeiten im Team:
- Ein Product Owner im Scrum-Team vertritt die Interessen der Stakeholder und priorisiert die Arbeit.
- Ein Scrum Master im Scrum-Team achtet auf die Einhaltung des Frameworks und fördert die Zusammenarbeit und Optimierung dieser.
- Die Developerinnen und Developer planen ihre Sprints gemeinsam mit Product Owner und Scrum Master und setzen dann die Arbeit um.
Unterstützt wird dieses Zusammenspiel durch die regelmäßigen Events in Scrum: Planning, Daily, Review und Retrospektive. Sie geben dem Projekt einen festen Rhythmus, der wie ein “Herzschlag” wirkt (Aussage im Scrum Guide). Dadurch sind die Strukturen verlässlich, wiederkehrend und planbar. Durch die eingebaute Feedbackschleifen in jedem Zyklus hat das Team außerdem regelmäßige Gelegenheiten, immer besser in der Zusammenarbeit werden
Der große Vorteil: Scrum ist ideal, wenn Vorhanden besonders komplex sind und viel Austausch und Lernzyklen notwendig ist. Kurze Feedbackschleifen helfen, schnell zu reagieren und Anpassungen vorzunehmen. Wer tiefer einsteigen will, findet die Details im Scrum Guide.
Beispiel aus der Praxis: Ein Team entwickelt eine neue App. Mit Scrum können Features in zweiwöchigen Abständen direkt gemeinsam mit den Nutzern getestet und verbessert werden. Nutzerfeedback fließt dabei in den nächsten Sprint ein.
Kanban: der kontinuierliche Fluss
Kanban als Methode hat eine andere Geschichte und Eigenschaften als das Scrum-Framework. Die Wurzeln liegen weiter in der Vergangenheit. In den Jahrzehnten nach dem 2. Weltkrieg entwickelte Toyota ein Produktionssystem, das Materialflüsse über einfache Karten (Kanban = „Karte“ oder „Schild“ auf Japanisch) steuerte. Ziel war es, Überproduktion zu vermeiden und nur das zu produzieren, was gerade gebraucht wurde – ein frühes Pull-System.
In den 2000er-Jahren übertrugen Software-Teams diese Prinzipien auf Wissensarbeit. Einer der Pioniere war David J. Anderson, der Kanban als Methode für IT-Teams formulierte und populär machte.
Statt Arbeit in feste Zeitabschnitte zu pressen, setzt Kanban auf kontinuierlichen Fluss. Jede Aufgabe durchläuft verschiedene Phasen: häufig in etwa von „To Do“ über „In Progress“ (oder “In Process”) bis „Done“. Sichtbar wird das Ganze auf einem Kanban-Board, das heute meist digital geführt wird, etwa mit Tools wie Jira, Planner oder Trello.
Ein wichtiges Steuerungselement von Kanban-Teams sind die Work-in-Progress-Limits (WIP). Sie legen fest, wie viele Aufgaben gleichzeitig bearbeitet werden dürfen. So wird Überlastung vermieden und werden Engpässe sichtbar – und das Team konzentriert sich auf das Wesentliche.
Ein Vorteil von Kanban liegt in der Flexibilität der Methode. Neue Aufgaben können jederzeit hinzugefügt oder Prioritäten geändert werden, ohne dass ein kompletter Plan über den Haufen geworfen werden muss. Auch Support- oder Betriebsteams profitieren davon, wenn sie oft auf Ad-hoc-Anfragen reagieren müssen.
Beispiel aus der Praxis: Ein IT-Support-Team nutzt Kanban, um Tickets zu priorisieren. Sobald die Spalte „In Progress“ zu voll wird, ist klar: Es gibt einen Engpass, den das Team lösen muss.
Kanban und Scrum im Vergleich: Die Unterschiede im Überblick
Um die Unterschiede auf einen Blick sichtbar zu machen, lohnt sich ein direkter Vergleich:
| Merkmal | Scrum | Kanban |
| Arbeitsrhythmus | Feste Iterationen (Sprints) | Kontinuierlicher Fluss nach Pull-Prinzip |
| Teamstruktur & Austausch | Klare Verantwortlichkeiten im Team, festgelegte Events | Keine Rollen oder Meetings vorgeschrieben, nur einige Meetings empfohle. Rollen bleiben bei einem Umstieg auf Kanban erhalten |
| Steuerung und Messung | Steht dem Team frei – oft verwendet: Velocity, Burndown Charts o.ä. | Empfohlen: Metriken wie Cycle Time, Durchsatz, WIP-Limits |
| Flexibilität | Änderungen im Sprint eingeschränkt möglich (solange Sprintziel nicht gefährdet und immer nach Absprache) | Anpassungen und Änderungen grundsätzlich möglich, mit Blick auf WIP-Limits und Kapazität |
| Mögliche Einsatzfelder | Produktentwicklung, komplexe Projekte | Produktentwicklung, Betrieb, Support |
Scrum bringt also vor allem iterative Lern- und Anpassungszyklen und damit eine gewisse Struktur, Kanban dagegen fokussiert sich mehr auf Flow und kapazitätsbasiertes Arbeiten.
Empfehlungen
Scrum kann die richtige Wahl, wenn ein Team ein komplexes Produkt entwickelt, etwa eine neue App oder ein größeres Feature. Hier braucht es klare Verantwortlichkeiten und einen festen Takt, um Orientierung zu geben. Die Sprint-Taktung hilft, sich auf kurzfristige Ziele zu konzentrieren, ohne das große Ganze aus dem Blick zu verlieren.
Kanban hingegen punktet besonders dann, wenn Aufgaben unregelmäßig und oft ungeplant hereinkommen. Support-Tickets, Wartungsaufgaben oder unvorhersehbare Betriebsanforderungen lassen sich in einem fließenden System viel leichter steuern. Das Kanban-Board schafft Transparenz, und die WIP-Limits verhindern, dass das Team sich verzettelt.
Fazit
Die Entscheidung zwischen Scrum und Kanban ist keine Glaubensfrage, sondern auch eine Frage der Voraussetzungen. Wer gerade von der Taktung 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.
In der Praxis zeigt sich: Viele Teams starten zunächst z.B. mit Scrum und nehmen sich später Elemente von Kanban hinzu – oder umgekehrt. Das ist ebenfalls legitim (solange sich alle Beteiligten im Klaren sind, wie zusammengearbeitet wird), um ein Arbeitsmodell zu finden, das zum Team, zum Produkt und zu den Rahmenbedingungen passt.
FAQ: Scrum oder Kanban?
Wann Scrum und wann Kanban?
Scrum eignet sich dann sehr gut, wenn ein Team von iterativen Abläufe und Lernzyklen profizieren kann, etwa bei komplexen Produktentwicklungen mit vielen Beteiligten. Kanban ist besonders sinnvoll, wenn Anforderungen häufig wechseln und Aufgaben flexibel gesteuert werden müssen, z. B. in Support- oder Betriebsteams.
Wann ist es schwierig, mit Kanban zu arbeiten?
Kanban kann an Grenzen stoßen, wenn die Arbeit eines Teams stark von anderen abhängt. Gerade ohne klaren Takt kann es passieren, dass die Koordination leidet. Lösungsansätze können darin liegen, die anderen Teams in das Kanban-System einzubinden.
Wann entscheidet man sich eventuell nicht für Scrum?
Scrum ist weniger geeignet, wenn neue Aufgaben unregelmäßig und kurzfristig auftreten, etwa im 24/7-Support. Auch sehr kleine Teams ohne klare Rollenverteilung profitieren oft nicht von den Scrum-Abläufen in ihrer Gänze. Unabhängig davon kommt es auch nicht selten es vor, dass Produktentwicklungs-Team dann zu Kanban wechseln, wenn sie von einem Neuentwickungs- eher in eine Art Betriebsmodus ihres Produkts übergehen.
Was gibt es darüber hinaus noch zu beachten?
Kanban bietet Flexibilität, aber weniger klare Verantwortlichkeiten und nicht unbedingt immer eine kurzzyklige Taktung. Das kann dazu führen, dass Themen wie Verantwortung, Priorisierung oder Feedback zu kurz kommen. Scrum bringt hierfür zwar ziemlich klare Vorschläge mit – allerdings kann dies ein größerer Umstellungsaufwand für alle sein. In der Folge wünschen sich viele Teams eine Anpassung der Arbeitsweise entgegen den Regeln im Scrum Guide und “verwässern” dadurch eventuell das Framework. Im besten Fall hat das Team eine gute Begleitung, so dass es zu seiner optimalen Arbeitsweise findet.
