„Scrum vs. Kanban“ ist eine beliebte Frage, aber die falsche. Scrum ist ein Framework für die Organisation von Produktentwicklung. Kanban ist ein Managementansatz für den Fluss von Arbeit. Beide lassen sich nur sinnvoll vergleichen, wenn klar ist, auf welcher Ebene der Vergleich stattfindet. Bei der Entwicklung Ihrer Individualsoftware, schätzen wir beide Methoden.
Warum der Vergleich Scrum vs. Kanban eine klare Trennung braucht
Der offizielle Scrum Guide beschreibt Scrum als Framework mit festen Rollen, Events und Artefakten.[^1] Dagegen beschreibt der offizielle Kanban Guide Kanban als Prinzipiensammlung, welche somit deutlich weniger Struktur vorschreibt.[^2]
Ein fairer Vergleich braucht deshalb zwei Schritte. Zuerst verstehen Sie beide Ansätze einzeln, dann legen Sie die passenden Kriterien für Ihr Projekt an. Agile Webentwicklung bildet dabei den gemeinsamen Rahmen, in dem sich beide Ansätze bewegen.
Warum klassische Softwareentwicklung an ihre Grenzen stieß
Bevor Scrum und Kanban entstanden, folgten die meisten Softwareprojekte einem festen Ablauf mit aufeinanderfolgenden Phasen für Anforderungen, Entwurf, Entwicklung, Test und Auslieferung. Dieses Modell nennt sich „Wasserfall“, weil jede Phase erst abgeschlossen sein muss, bevor die nächste beginnt.
Das Problem zeigte sich meist erst spät. Kunden sahen die erste funktionierende Software oft erst nach Monaten oder Jahren, wenn sich Anforderungen längst geändert hatten. Fehler aus der Konzeptphase fielen häufig erst beim Testen auf, wenn eine Korrektur bereits teuer war.
Welche Probleme starre Phasen verursachten
Durch dieses Vorgehen traten drei Probleme besonders häufig auf. Erstens bekamen Kunden zu spät ein sichtbares Ergebnis, um frühzeitig gegenzusteuern. Ebenfalls verteilte sich Verantwortung auf viele Dokumente und Übergaben, ohne dass jemand das Gesamtergebnis konkret verantwortete. Drittens machte die feste Reihenfolge der Phasen jede spätere Änderung aufwendig und teuer.
Genau diese Erfahrung prägte die frühen 1990er Jahre in der Softwarebranche. Teams suchten nach Wegen, bereits früher echtes Feedback zu erhalten, statt dieses erst am Projektende zu erfahren.
Scrum entstand also als direkte Antwort auf die Schwächen des Wasserfallmodells.[^1]
Wie Scrum die Probleme des Wasserfalls konkret löst
Jedes Element von Scrum beantwortet eines der drei Probleme aus dem Wasserfallmodell. Der sogenannte „Sprint" sorgt dafür, dass Kunden alle paar Wochen ein echtes Ergebnis sehen, statt erst am Projektende.
Das „Increment" ist dieses Ergebnis: ein nutzbares Stück Software am Ende jedes Sprints. Es ersetzt die lange Wartezeit auf ein fertiges Gesamtprodukt durch regelmäßige, überprüfbare Zwischenstände.
Die drei Rollen lösen das zweite Problem, die verteilte Verantwortung. Der „Product Owner" entscheidet, was Priorität hat. Der „Scrum Master" sorgt für einen funktionierenden Prozess. Die „Developers" liefern das Increment. So bleibt jede Entscheidung eindeutig zugeordnet, anders als bei den vielen Übergaben im Wasserfallmodell.
Rollen, Events und Artefakte im Überblick
Scrum definiert drei Rollen, die gemeinsam ein Scrum-Team bilden. Jede Rolle trägt eine eigene Verantwortung. Keine Rolle entscheidet allein.
Der Sprint bildet den festen Rhythmus, typischerweise zwei bis vier Wochen lang. Um ihn herum stehen feste Events wie Sprint Planning, Daily Scrum, Sprint Review und Retrospektive.
Die wichtigsten Elemente im Überblick:
- Rollen: Product Owner, Scrum Master, Developers
- Events: Sprint, Sprint Planning, Daily Scrum, Sprint Review, Sprint Retrospektive
- Artefakte: Product Backlog, Sprint Backlog, Increment
Warum feste Sprints Planbarkeit schaffen
Ein fester Sprint-Rhythmus macht Fortschritt vorhersehbar. Stakeholder wissen genau, wann sie das nächste Increment sehen und bewerten können.
Diese Planbarkeit hat aber ihren Preis. Neue Anforderungen warten in der Regel bis zum nächsten Sprint. Spontane Änderungen mitten im Sprint sind nicht vorgesehen.
Was Kanban leistet und wofür es gebaut wurde
Kanban organisiert nicht Rollen oder Zyklen, sondern den Fluss der Arbeit selbst. Statt fester Struktur gibt es Prinzipien, die sich an ein bestehendes System anpassen lassen.
Wie Kanban aus der Fertigung in die Softwareentwicklung kam
Kanban stammt ursprünglich nicht aus der Softwareentwicklung. Der Ingenieur Taiichi Ohno entwickelte das Prinzip in den 1950er Jahren bei Toyota, um Produktion enger an tatsächliche Nachfrage zu koppeln.
Der Softwareentwickler David J. Anderson übertrug diese Idee ab 2004 auf Wissensarbeit, zuerst in einem Team bei Microsoft.[^2] Anders als Scrum ersetzte Kanban dabei nicht den bestehenden Prozess eines Teams. Es machte ihn nur sichtbar und verbesserte ihn Schritt für Schritt.
Kanban griff damit ein anderes Problem als Scrum auf. Teams mit stark schwankender Arbeitslast, etwa im Support oder in der Wartung, brauchen oft weniger feste Struktur als ein Sprint vorgibt. Feste Sprints hätten hier oft mehr Struktur erzwungen, als die Arbeit tatsächlich brauchte.
So funktioniert Kanban im Alltag
Kanban gibt kaum feste Strukturen vor. Es gibt keine Sprints, keine festen Rollen und keine vorgeschriebenen Meetings. Stattdessen macht Kanban sichtbar, wie Arbeit durch ein Team fließt, und hilft dabei, diesen Fluss Schritt für Schritt zu verbessern.
Das zentrale Werkzeug ist das Kanban Board. Es besteht aus Spalten, die die Arbeitsschritte eines Teams abbilden, zum Beispiel „Offen", „In Arbeit", „Review" und „Erledigt". Jede Aufgabe ist eine Karte, die von links nach rechts durch diese Spalten wandert.
Ein Beispiel aus der Webentwicklung: Ein Kunde meldet einen Fehler im Kontaktformular. Das Ticket landet als Karte in „Offen". Sobald ein Entwickler Kapazität hat, zieht er die Karte nach „In Arbeit", danach geht sie in „Review" und nach dem Deployment in „Erledigt". Es gibt keinen Sprintstart und kein Sprintende. Neue Aufgaben kommen jederzeit hinzu und werden bearbeitet, sobald Platz ist.
Warum WIP-Limits Engpässe sichtbar machen
Damit dieser Fluss funktioniert, setzt Kanban sogenannte WIP-Limits (Work in Progress). Sie legen fest, wie viele Karten maximal gleichzeitig in einer Spalte liegen dürfen. Liegt das Limit für „Review" etwa bei drei, darf keine vierte Karte hinein, bis eine der drei abgeschlossen ist.
Genau hier zeigt sich die Stärke von Kanban: Stauen sich Karten vor dem Review, sieht das Team sofort, wo es hakt. Statt neue Aufgaben anzufangen, hilft es gezielt beim Review aus. So werden Engpässe nicht erst in einer Auswertung nach Wochen sichtbar, sondern direkt im täglichen Arbeiten.
Wie beide Ansätze in echten Softwareprojekten aussehen
Die folgenden zwei Beispiele zeigen, wie sich die Wahl in der Praxis auswirkt.
Ein Projektbeispiel mit festen Releases
Ein Team entwickelt eine neue Kernfunktion für eine Software, die zu einem festen Termin live gehen soll. Scrum passt hier gut, weil der Sprint-Rhythmus feste Meilensteine erzwingt.
Product Owner und Team planen gemeinsam, was in den nächsten Sprint passt. Nach jedem Sprint zeigt ein Review den tatsächlichen Fortschritt gegenüber der Planung.
Ein Projektbeispiel mit Support-Fokus
Ein anderes Team betreut den laufenden Support einer bestehenden Anwendung. Anfragen kommen unregelmäßig, mal mehrere am Tag, mal tagelang keine.
Kanban passt hier besser, weil es keinen festen Zyklus erzwingt. Neue Anfragen landen direkt im Flow, statt auf den nächsten Sprint warten zu müssen.
Wie Scrumban beide Ansätze verbindet
Scrumban kombiniert die Struktur von Scrum mit dem Fluss-Prinzip von Kanban. Teams behalten feste Sprints. Sie ergänzen sie aber um Elemente wie WIP-Limits.
Wann eine Kombination sinnvoller ist
Eine Kombination lohnt sich, wenn ein Team sowohl planbare Releases als auch unvorhersehbare Support-Arbeit bewältigen muss. Der Bitkom-Leitfaden zur Agilität in Organisationen beschreibt genau diesen Übergang zwischen beiden Ansätzen.[^3]
Fazit
Scrum und Kanban lösen unterschiedliche Probleme. Scrum entstand als Antwort auf die starren Phasen des Wasserfallmodells und strukturiert Produktentwicklung über Rollen, Events und Artefakte. Kanban entstand als Antwort auf unsichtbare, überlastete Arbeitsprozesse und optimiert den Fluss bestehender Arbeit über Prinzipien statt feste Struktur.
Ihr Projekt kommt nicht richtig voran? Häufig liegt das nicht am Team, sondern an einem Prozess, der nicht zur Art der Arbeit passt. Wir schauen uns Ihr aktuelles Vorgehen an und zeigen Ihnen, wo Engpässe entstehen und wie Sie diese lösen. Vereinbaren Sie jetzt ein unverbindliches Gespräch.
Fußnoten und Quellen
[^1]: Ken Schwaber und Jeff Sutherland, „The Scrum Guide", offizielle Ausgabe November 2020. https://scrumguides.org [^2]: Kanban University, „The Official Guide to The Kanban Method". https://kanban.university/kanban-guide/ [^3]: Bitkom e. V., Leitfaden „Agilität in Organisationen: Ein Leitfaden für die Praxis", 2020. https://www.bitkom.org/sites/default/files/2020-12/201124_lf_agilitat-in-organisationen.pdf [^4]: Bitkom e. V., Positionspapier „Innovation rechtssicher gestalten: Einsatz externer Spezialistinnen und Spezialisten", Januar 2025. https://www.bitkom.org/sites/main/files/2025-01/bitkom-positionspapier-innovation-rechtssicher-gestalten.pdf
