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 |
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?
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?
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.