Kanban, Scrum und Scrumban

Während Scrum ein komplettes Framework ist, kann man Kanban eher als Methode bezeichnen.

Am besten kann man Scrum und Kanban erklären, indem man auf Gemeinsamkeiten und Unterschiede eingeht.

Beginnen wir mit den Gemeinsamkeiten

• Es gibt ein Backlog an Aufgaben, aus dem die Entwickler oder Umsetzer sich nach und nach jeweils ihre Aufgaben ziehen, die sie erledigen wollen. Man bezeichnet dies auch als Pull-Methode.
• Sowohl Scrum als auch Kanban streben eine Selbstorganisation des Teams an und am Ende soll ein testbares Inkrement erstellt werden.
• Bei beiden gibt es ein Task Board, welches den aktuellen Stand der Aufgaben visualisiert.
• Beide nutzen eine Art Limitierung von Aufgaben, diese ist allerdings unterschiedlich, worauf wir bei den Unterschieden eingehen werden.
• Beide haben bestimmte Meetings um über Feedback zu reden und Verbesserungen durchzuführen.

Die Unterschiede sind folgende:

• Bei Scrum gibt es die Rollen des Product Owners, des Scrum Masters und der Developer. In Kanban sind keine speziellen Rollen vorgeschrieben.
• während es bei Scrum durch die Sprintlänge eine Art Timebox gibt, hat Kanban dahingehend keine Einschänkungen. Scrum ist also Iterativ, Kanban kontinuierlich.
• Das Scrum Board enthält drei Spalten: Todo, Doing und Done. Im Kanban Board können die Spalten je nach Bedarf angepasst und ergänzt werden. Eine Spalte für Testing oder Review sind zum Beispiel keine Seltenheit.
• Im Scrum wird eine Limitierung der Aufgaben mittels fester Anzahl an User Stories im Sprint Backlog für den aktuellen Sprint geregelt – bei Kanban wird die Limitierung direkt an der Spalte des Boards vorgenommen. Dort kann eingestellt werden, dass z.B. maximal drei Aufgaben zur gleichen Zeit innerhalb der Spalte Doing liegen dürfen. Erst wenn mindestens eine davon abgearbeitet ist, kann eine nächste Aufgabe in die Spalte gezogen werden.
• Im Scrum Prozess wird das Sprint Board zu Beginn des Sprints befüllt und ist nach dem Sprint leer – erledigte Aufgaben können geschlossen werden, unerledigte Aufgaben kommen zurück ins Product Backlog. Sie werden dann in einem der nächsten Sprints wieder eingeplant.
• Ein Kanban Board ist in dem Sinne nie leer bzw. nur, wenn das Projekt beendet wurde. Aufgaben wandern stets und ständig durch das Board, sobald die Limitierung der einzelnen Spalten es zulässt.
• Während bei Scrum eine Schätzung der Komplexität der Userstories vorgeschrieben ist, um dadurch Sprints mittels der berechneten Velocity besser planen zu können, muss bei der Kanban-Methode nicht unbedingt geschätzt werden, allerdings kann die Lead Time genutzt werden.
• Die Meetingevents im Scrum sind fest vorgeschrieben. Im Kanban-Modus ist man mit den Meetings etwas freier.

Wann nutzt man nun Kanban und wann Scrum?

Die kontinuierliche Arbeitsweise von Kanban wird verwendet, wenn es nicht unbedingt darum geht ein Produkt zu entwickeln, welches Anforderungsabhängigkeiten enthält. In Supportabteilungen nutzt man deshalb eher Kanban. Die Fehlertickets der Kunden, die es zu lösen gilt, werden kontinuierlich vom Entwicklerteam gezogen, bearbeitet, gelöst und zurückgemeldet.

Sowohl fortlaufende als auch abgeschlossene Projekte mit vielen Anforderungen, die aufeinander aufbauen, sich einander bedingen und unterschiedlich priorisiert werden können, entwickelt man besser innerhalb des Scrum Prozesses. Durch die festen Sprintzyklen und der Transparenz zum Kunden sowie das immer wieder eingehende Kundenfeedback nach jedem Zyklus, kann man die Umsetzung und den Aufwand für die Entwicklung besser überschauen und überwachen. Auch bietet Scrum eine bessere Möglichkeit um auf Anforderungsänderungen flexibler zu reagieren, ohne in den aktuellen Sprint einzugreifen.

Und dann gibt es noch Scrumban – eine Kombination aus Scrum und Kanban.

Die Umsetzung von Scrumban wird unterschiedlich definiert. Grundsätzlich wird das Beste für das Unternehmen aus beiden Methoden vereint und genutzt.

Dafür wird zum Beispiel der Scrum Prozess genutzt, aber mit einem Kanban Board erweitert – Spalten sind dann nicht mehr nur To Do, Doing und Done, sondern evtl. noch Test oder Review und eine Limitierung je Spalte ist möglich zusätzlich zur Limitierung des Sprint Backlogs.

Es gibt aber auch die Kombination, dass die kontinuierliche Arbeitsweise von Kanban in das Scrum Framework integriert wird und der iterative Prozess der Sprints entfällt.

Fassen wir zusammen: Sowohl Scrum als auch Kanban haben Vor und Nachteile für bestimmte Anwendungsfälle. Jedes Unternehmen muss für sich entscheiden, mit welcher Methode es am besten fährt. Manchmal kann die Kombination mittels Scrumban auch die optimalste Wahl sein.