Kanban oder Scrum: Welche Agile-Variante ist die Richtige für dein Unternehmen?

Hier stellen wir die wichtigsten Überlegungen vor, die du bei deiner Wahl zwischen Scrum und Kanban anstellen solltest. Außerdem helfen wir den Unentschlossenen auf die Sprünge.

Max Rehkopf Von Max Rehkopf
Themen durchsuchen

Zusammenfassung: Kanban ist ein Projektmanagement-Framework, bei dem zur Verwaltung von Workflows auf visuelle Aufgaben gesetzt wird. Scrum hingegen ist ein Projektmanagement-Framework, das Teams dabei unterstützt, ihre Arbeit anhand bestimmter Werte, Prinzipien und Methoden zu strukturieren und zu verwalten.

Agile sind die Ideale und Prinzipien, die uns als Richtschnur dienen. DevOps ist eine Möglichkeit, die Prozesse zwischen Softwareentwicklungs- und Operations-Teams zu automatisieren und zu integrieren. Kanban und Scrum bieten unterschiedliche Methoden zur Implementierung von Agile und DevOps.

Die Unterschiede zwischen Scrum- und Kanban-Verfahren lassen sich leicht ausmachen. Doch das ist nur eine oberflächliche Betrachtung. Die Verfahren unterscheiden sich zwar, doch die Prinzipien dahinter sind größtenteils identisch. Beide Frameworks helfen dir, bessere Produkte (und Services) reibungsloser zu entwickeln.

Wo sind wir stehen geblieben?

Agile ist ein strukturierter und iterativer Ansatz für das Projektmanagement und die Produktentwicklung. Er trägt der Unberechenbarkeit in der Produktentwicklung Rechnung und bietet sich selbst organisierenden Teams eine Methode, um auf Änderungen zu reagieren, ohne aus dem Konzept zu kommen. Heute stellt Agile kaum noch einen Wettbewerbsvorteil dar. Niemand kann es sich leisten, ein Produkt über Monate oder gar Jahre in einer Blackbox zu entwickeln. Da ist es wichtiger denn je, seine Sache gut zu machen.

Bei Kanban dreht sich alles um das Visualisieren von Aufgaben, das Begrenzen laufender Arbeiten und das Maximieren der Effizienz (oder des unterbrechungsfreien Arbeitens). Kanban-Teams konzentrieren sich darauf, ein Projekt (oder eine User Story) möglichst schnell abzuschließen. Dazu verwenden sie ein Kanban Board und verbessern kontinuierlich ihren Arbeitsfluss.

Scrum-Teams arbeiten an der Fertigstellung eines potenziell auslieferbaren Zwischenergebnisses. Dazu verwenden sie festgelegte Intervalle, sogenannte Sprints. Ihr Ziel ist das Erstellen von Lernschleifen, um Kundenfeedback schnell zu sammeln und einzubeziehen. Scrum-Teams bringen ihre Arbeit voran, indem sie bestimmte Rollen einnehmen, spezielle Artefakte erstellen und regelmäßig Zeremonien abhalten. Eine gute Definition von Scrum findest du im Scrum-Leitfaden.

Egal, für welches Projektmanagement-Framework du dich entscheidest: Wir bieten dir Jira-Vorlagen für einen schnellen Einstieg. Unsere Scrum-Vorlage und unsere Kanban Board-Vorlage können kostenlos verwendet werden.

 

Scrum

Kanban

Ursprung

Scrum

Softwareentwicklung

Kanban

Lean Manufacturing

Idee

Scrum

Lernen aus Erfahrungen, Selbstorganisation, Priorisierung und Nachdenken über Erfolge und Misserfolge zur ständigen Verbesserung

Kanban

Verwenden von Grafiken um den laufende Arbeiten zu verbessern

Rhythmus

Scrum

Regelmäßige Sprints mit fester Länge (d. h. zwei Wochen)

Kanban

Kontinuierlicher Fluss

Best Practices

Scrum

Sprint-Planung, Sprint, Daily Scrum, Sprint-Review, Sprint-Retrospektive

Kanban

Visualisierung von Arbeitsabläufen, Work-in-Progress-Grenzen, Workflow-Management, Einbindung von Feedbackschleifen

Rollen

Scrum

Product Owner, Scrum Master, Entwicklerteam

Kanban

Keine Rollen erforderlich

Teamkollegen arbeiten an einem Scrum Board | Atlassian Agile Coach

Scrum: Ein strukturierter agiler Ansatz

Scrum-Teams legen sich verbindlich darauf fest, am Ende eines Sprint ein nützliches Arbeitsinkrement auszuliefern. Scrum basiert auf Erkenntnissen: Kleine Arbeitsinkremente helfen dabei, von Kunden zu lernen und eine bessere Entscheidung über das weitere Vorgehen zu treffen. So sieht Scrum im Detail aus:

Scrum-Rhythmus

Mit Scrum macht deine Arbeit schnelle Fortschritte und ist nach Sprints von zwei bis maximal vier Wochen abgeschlossen. Dabei werden feste Start- und Endtermine bestimmt. Durch den engen Zeitrahmen müssen komplexe Aufgaben in kleinere Storys unterteilt werden und Teams können schnell neue Erkenntnisse gewinnen. Eine zentrale Frage dabei ist: Kann dein Team brauchbaren Code so schnell ausliefern?

Ein Sprint umfasst die Sprint-Planung, den Sprint-Review sowie Meetings, die sogenannten Retrospektiven, und wird abgerundet durch tägliche Scrum-Meetings (Stand-ups). Diese Scrum-Zeremonien sind unkompliziert und werden fortlaufend durchgeführt.

Scrum-Rollen

In Scrum gibt es drei klar definierte Rollen.

  • Der Produktinhaber (Product Owner) vertritt die Wünsche des Kunden, verwaltet das Produkt-Backlog und hilft dem Entwicklerteam, die zu erledigenden Aufgaben zu priorisieren.
  • Der Scrum Master unterstützt das Team dabei, sich stets an den Scrum-Prinzipien zu orientieren.
  • Das Entwicklerteam bestimmt, welche Aufgaben zu erledigen sind, liefert Zwischenergebnisse und ist gemeinsam für die Zielerreichung verantwortlich.

Und wer verwaltet das Scrum-Team? Niemand. Scrum-Teams organisieren sich selbst. Es gibt keine Hierarchie unter den Mitgliedern, sie haben lediglich verschiedene Zuständigkeiten. Ein gemeinsames Ziel schweißt das Team zusammen: ein Produkt zu liefern, das dem Kundennutzen entspricht.

Gängige Metriken

Scrum-Metriken sind Datenpunkte, die Scrum-Teams nutzen können, um die Effizienz und Effektivität zu verbessern. Sie können Daten für die Entscheidungsfindung liefern und Teams dabei unterstützen, die Effizienz bei der Planung und Ausführung zu steigern. Während der Sprint-Planungsphase können Teams Metriken wie Sprint-Ziele, Team-Velocity, Team-Kapazität und Aufgabenart heranziehen. Auch bei Stand-ups können Metriken Teams dabei helfen, den Fortschritt bei Sprint-Zielen zu messen, einen Sprint-Burndown zu überprüfen, die Arbeitslastverteilung zu verstehen und vieles mehr.

Änderungsphilosophie

Teams möchten verstehen, wie viel sie innerhalb der Grenzen des Sprint-Zeitraums erreichen können. Sie verpflichten sich, am Ende des Sprints die gewünschten Ergebnisse auszuliefern. Dabei reagieren Scrum-Teams jedoch auch auf Kundenfeedback und passen Sprints an, um den Kundenmehrwert zu erhöhen. In der Sprint-Retrospektive sollten Scrum-Teams besprechen, wie sie Änderungen künftig einschränken können, um das potenziell auslieferbare Zwischenergebnis nicht zu gefährden. Wenn ein Team den Umfang häufig mitten im Sprint ändert, kann es sein, dass Aufgaben ausgewählt wurden, die nicht richtig verstanden werden. Es könnte auch bedeuten, dass das Team betriebliche/nicht planbare Aufgaben übernimmt, die sich mit der Planung überschneiden.

Weitere Scrum-Methoden findest du unter Was ist Scrum?

Teamkollegen arbeiten an einem Kanban Board | Atlassian Agile Coach

Kanban: Kontinuierliche Verbesserung, flexible Prozesse

Mit Kanban kannst du deine Arbeit visualisieren, Work-in-Progress (WIP) begrenzen und deine Aufgaben schnell zum Abschluss bringen.

Kanban eignet sich ideal für Teams, bei denen viele Anfragen mit unterschiedlicher Priorität und Größe eingehen. Während in Scrum-Prozessen der Umfang stark kontrolliert werden muss, kannst du in Kanban einfach dem Workflow folgen. Werfen wir einen Blick auf dieselben fünf Punkte, damit dir die Entscheidung leichter fällt.

Kanban-Rhythmus

Kanban basiert auf einer Struktur mit kontinuierlichem Workflow, der es Teams erlaubt, immer schnell zu reagieren und sich rasch neuen Prioritäten anzupassen. Aufgabenelemente –die als Karten dargestellt sind – werden in einem Kanban Board organisiert, wo sie eine Workflow-Phase (Spalte) nach der anderen durchlaufen. Gemeinsame Workflow-Phasen sind To Do (Zu erledigen), In Progress (In Bearbeitung), In Review (In Prüfung), Blocked (Gesperrt) und Done (Erledigt). Doch damit sind längst nicht alle Möglichkeiten ausgeschöpft.

Das Beste an Kanban sind die individuellen Spalten, die du der Arbeitsweise deines Teams anpassen kannst. Mein Team liefert Inhalte aus und unsere Spalten reichen (vereinfacht) von Backlog, Priorisiert und Fertige Entwürfe über Wird geschrieben und Wird entworfen bis hin zu Technische Prüfung und Ausgeliefert. In unserem Board sehen wir, dass wir rund einen Inhalt pro Woche ausliefern, und erkennen genau, wo unsere Engpässe liegen (der technischen Prüfung sei Dank).

Release-Methoden

In Kanban werden Updates veröffentlicht, sobald sie abgeschlossen sind. Es gibt weder einen festen Zeitplan noch bestimmte Fälligkeitstermine.

Theoretisch wird in Kanban kein fixer Zeitpunkt festgelegt, an dem eine Aufgabe abzuliefern ist. Wird eine Aufgabe früher (oder später) abgeschlossen, kann sie einfach veröffentlicht werden, ohne dass Release-Meilensteine wie etwa Sprint-Reviews abgewartet werden müssen.

Kanban-Rollen

Zuständig für das Kanban Board ist das gesamte Team. Manche Teams ernennen einen Agile Coach, aber im Gegensatz zu Scrum gibt es keinen "Scrum Master", der alles am Laufen hält. Es liegt in der gemeinsamen Verantwortung des ganzen Teams, an den Aufgaben im Board zusammenzuarbeiten und sie abzuschließen.

Zentrale Messgrößen

Vor- und Durchlaufzeit sind wichtige Messgrößen für Kanban-Teams. Für sie zählt die durchschnittliche Zeit, die ab Bearbeitung einer Aufgabe bis hin zum Abschluss erforderlich ist. Ein Kanban-Team ist erfolgreich, wenn es seine Durchlaufzeiten verbessern kann.

Das kumulative Flussdiagramm ist ein weiteres Analysetool, mit dem Kanban-Teams die Zahl der Aufgabenelemente pro Phase messen können. Dieses Diagramm gibt Aufschluss über die Engpässe, die gelöst werden müssen, um einen besseren Durchsatz zu erzielen.

Engpässe können auch mithilfe von WIP-Grenzen (Work-in-Progress-Grenzen) bewältigt werden. Durch eine WIP-Grenze wird die Zahl der Karten in einer bestimmten Spalte zu einem konkreten Zeitpunkt eingeschränkt. Bei Erreichen der WIP-Grenze wird die entsprechende Spalte durch Tools wie Jira beschränkt und das Team kümmert sich gemeinsam darum, die jeweiligen Elemente weiterzuverarbeiten.

Änderungsphilosophie

Kanban-Workflows können sich jederzeit ändern. Neue Aufgabenelemente können dem Backlog hinzugefügt und bestehende Karten je nach Priorisierung gesperrt oder gelöscht werden. Wenn sich die Teamkapazitäten ändern, kann die WIP-Grenze außerdem neu eingestellt und Aufgabenelemente können entsprechend angepasst werden. Flexibilität ist bei Kanban das A und O.

Weitere Kanban-Methoden findest du unter Was ist Kanban?

Das Agility-Projekt von Atlassian | Atlassian Agile Coach

Scrum-Tools vs. Kanban-Tools

In der Agile-Community dreht sich die Diskussion nicht um Tools. Wir erleben oft, dass das Tool der Wahl das Framework bestimmt und das Framework die Prinzipien der Teamarbeit. Wir sind jedoch der Ansicht, dass der Weg der Entscheidungsfindung andersherum ablaufen sollte.

Sobald du mit bestimmten Scrum-Prinzipien vertraut und mit dem Scrum-Framework zufrieden bist, kannst du dich auf die Suche nach einem geeigneten Scrum-Tool machen. Dasselbe gilt für Kanban. Natürlich sind wir etwas voreingenommen: Aber wir finden, dass Jira, die Nummer eins der Softwareentwicklungstools agiler Teams, euch alles bietet, was ihr braucht.

Mit den spezifischen Projektarten für Scrum und Kanban kannst du die jeweiligen Framework-Prinzipien mit Jira umsetzen. Außerdem helfen dir am Anfang unsere Leitfäden So geht Scrum mit Jira und So geht Kanban mit Jira.

Kanban vs. Scrum: Keine leichte Entscheidung

Scrum und Kanban sind "agil wie aus dem Bilderbuch". Dass diese Methoden seit Langem bewährt sind, ist schwer zu leugnen. Mit anderen Worten: "Scrum und Kanban funktionieren für jedes Team".

Mit deiner Entscheidung musst du dich jedoch nicht so stark festlegen. Hunderte von Teams nutzen hybride Modelle, die sowohl von Scrum als auch von Kanban geprägt sind. Und das ist auch in Jira möglich. Dafür haben wir vom Team verwaltete Projekte entwickelt.

Mit vom Team verwalteten Projekten können Teams die agilen Features auswählen, die am besten zu ihnen passen – sei es nun Scrum, Kanban oder etwas von beidem. Du musst dich nicht von Anfang an auf ein Framework festlegen, sondern kannst dein Modell mit vom Team verwalteten Projekten nach und nach um weitere starke Funktionen erweitern, nachdem sich gezeigt hat, womit dein Team gut arbeiten kann (und womit nicht).

So kannst du dich ohne Bedenken für vom Team verwaltete Scrum- oder Kanban-Prozesse entscheiden und dir sicher sein, dass sich beide Vorlagen auf die Anforderungen deines Teams abstimmen lassen.

Ganz unabhängig von deiner Entscheidung solltest du die Methode deiner Wahl eine Zeit lang beibehalten. Bringe einige Aufgaben aus dem Backlog zum Abschluss und frage dann dein Team, was gut gelaufen ist und wo es gehakt hat. Wenn du Scrum und Kanban ausprobierst und diese Fragen stellst, bist du bereits auf dem richtigem Weg zu dem agilen Ansatz, der dich glücklich macht.

Related resources

Weiter geht's
Kanplan