Scrum oder Kanban? So finden Sie die richtige Methode für Ihre Arbeit

Agile Managementmethoden sind in aller Munde. Die einen schwören auf Scrum, die Anderen meinen Kanban ist das einzig Richtige.

Wer hat nun Recht?

Betrachten wir nun die beiden Prozessmethoden und lernen deren Stärken und Schwächen kennen.

Ziel beider Methoden ist die Produktivität zu steigern. Dazu sollen Leerläufe und Doppelgleisigkeiten vermieden werden. Abläufe und Prozesse sollen ständig verbessert werden.

Scrum – ein Überblick

Bei Scrum wird ein starker Fokus auf die organisatorische Struktur des Teams gelegt. Scrum unterscheidet verschiedene Rollen.

Der Scrum-Master organisiert die Meetings. Er hat den Überblick über alle Vorgänge, beseitigt Probleme des Teams und regelt die Kommunikationsabläufe innerhalb des Teams und nach außen.

Für das Product Backlog ist der Product Owner zuständig. Er achtet darauf, dass die Anforderungen des Kunden erfüllt und nach seiner Priorisierung umgesetzt werden.

Das Team versucht in einzelnen Entwicklungsphasen (bei Scrum „Sprints“ genannt) die Anforderungen schrittweise umzusetzen. Es ist interdisziplinär zusammengestellt. Am Ende eines jeden Sprints sollte idealerweise ein auslieferbarer Teil des Projektes fertig gestellt sein.

Scrumboard in der Praxis

Kommunikation ist alles:

Sprint Planning Meeting

Zu Beginn jedes Sprints findet als Kick-Off das Sprint Planning Meeting statt. Grundsätzlich wird für dieses Meeting eine Timebox von 2 Stunden für jede Woche eines Sprints angenommen. Es dient dazu, das Arbeitspaket des Scrum-Teams für den kommenden Sprint (Sprint Backlog) festzulegen.

Daily Scrum Meeting

Wie der Name andeutet, findet das Daily Scrum Meeting an jedem Arbeitstag statt. Es dauert nicht länger als 15 Minuten (Time-Box) und dient dem Team dazu, sich abzustimmen und gegenseitig zu informieren.

  1. Welche Tätigkeiten habe ich seit dem letzten Daily Scrum gemacht?
  2. Was plane ich bis zum nächsten Daily Scrum zu tun?
  3. Hat mich bei der Arbeit etwas behindert („Impediments“)?

Sprint Review Meeting

Am Ende jedes Sprints präsentiert das Team dem Product Owner und allen interessierten Stakeholdern das Ergebnis seiner Arbeit live am System und holt Feedback (Meinungen, Verbesserungsvorschläge, Lob und Kritik) ein.

Sprint Retrospective Meeting

Das Team bespricht in diesem Meeting welche Punkte im letzten Sprint gut gelaufen sind, welche Verbesserungen notwendig sind und wie diese erreicht werden können.

Kanban – ein Überblick

Das Wort Kanban kommt aus dem Japanischen. Es setzt sich aus den Worten KAN (Visualisieren) und BAN (Karte) zusammen. Diese Managementmethode hat den großen Vorteil, dass jeder weiß für welche Arbeit er zuständig ist. Das mag zuerst banal klingen, doch für eine schnelle Durchlaufzeit der Prozessschritte ist dies fundamental.

Im Zentrum der Managementmethode steht eine Tafel – das Kanban-Board. Darauf werden der bestehende Workflow, die vorhandene Arbeit sowie Probleme visualisiert. Jede Karte auf dem Board repräsentiert dabei eine Aufgabe. Die Kärtchen durchlaufen wie ein CR-Ticket die verschiedenen Prozessschritte vom „Backlog“ bis zu „Done“.

Diese einfache Maßnahme führt zu viel Transparenz über die Verteilung der Arbeit, sowie bestehende Engpässe.

Als nächstes wird der Work in Progress (WIP) limitiert, also die Menge an parallelen Aufgaben. Dadurch wird zum einen das Multitasking reduziert, zum anderen bedeutet weniger WIP, dass jede einzelne Aufgabe schneller erledigt werden kann als vorher.

Im Kern von Kanban steht das Konzept von Flow. Das bedeutet, dass die Tickets möglichst gleichmäßig durch das System fließen sollen, ohne lange Wartezeiten oder Blockaden. Alles, was den Flow behindert, wird kritisch unter die Lupe genommen. Dafür kennt Kanban verschiedene Techniken, Metriken und Modelle. Werden diese konsequent angewendet, kann Kanban dazu führen, dass sich eine Kultur der kontinuierlichen Verbesserung  im Unternehmen etabliert.

Unterschiede zwischen Kanban und Scrum

Kanban Scrum
Iterationen sind optional. Es kann unterschiedliche Takte für Planung, Releases und Prozessverbesserung geben. Iterationen mit gleichen Längen sind vorgeschrieben.
Commitments sind optional. Das Team vereinbart, eine bestimmte Menge an Arbeit während der nächsten Iteration zu erledigen.
Die Durchlaufzeit (Cycle Time) wird als Basis-Metrik für Planung und Prozessverbesserung verwendet. Die Team-Geschwindigkeit (Velocity) ist die Basis-Metrik für Planung und Prozessverbesserung.
Cross-funktionale Teams sind optional. Experten-Teams sind erlaubt. Cross-funktionale Teams sind vorgeschrieben.
Keine Vorschrift bezüglich der Größe von Anforderungen. Anforderungen müssen so aufgeteilt werden, dass sie sich innerhalb einer Iteration erledigen lassen.
Work in Progress wird direkt limitiert. Work in Progress wird indirekt limitiert (durch die Menge an Anforderungen, die in einen Sprint passt).
Schätzungen sind optional. Schätzungen sind vorgeschrieben.
Neue Anforderungen können zu jedem Zeitpunkt an das Team gegeben werden, falls Kapazitäten frei sind. Während eines laufenden Sprints können keine neuen Anforderungen an das Team gegeben werden.
Gibt keine Rollen vor. Schreibt drei Rollen vor (Product OwnerScrum Master, Team).
Ein Kanban-Board kann von mehreren Teams und/oder Einzelpersonen geteilt werden. Ein Scrum-Board gehört einem einzelnen Team.
Ein Kanban-Board wird kontinuierlich weitergepflegt. Das Scrum-Board wird nach jedem Sprint gelöscht und neu aufgesetzt.
Priorisierung ist optional. Schreibt vor, dass alle Einträge im Backlog priorisiert sein müssen.

(Quelle Wikipedia)

Eine kleine Entscheidungshilfe:

Eher Kanban als SCRUM nutzen, wenn

  • die Organisation größere Veränderungen ablehnt und das Management stark um Konsens bemüht ist.
  • die Spezifikationen schon zu Beginn klar fixiert werden.
  • die Projektteams aus verschiedenen, nicht untereinander austauschbaren Spezialisten bestehen.
  • die Führungskultur eher „Befehl und Gehorsam“ als „Eigenverantwortung und Vertrauen“ entspricht.
  • das Hauptproblem im Projektmanagement durch „viel anfangen – wenig fertigstellen“ beschrieben ist.

Eher SCRUM als Kanban nutzen, wenn …

  • durch den Methodenwechsel nicht nur der Entwicklungsprozess, sondern auch das Entwicklungsergebnis (Produkt) verbessert werden soll.
  • Kunden oder andere Partner intensiv in die Entwicklung eingebunden werden sollen.
  • das Endprodukt zu Beginn der Entwicklung nur als unscharfe Vision existiert.
  • eine grundlegende Kultur von sich selbst organisierenden Teams eingeführt werden soll.

Fazit:

Scrum und Kanban eignen sich gut für Projekte mit unterschiedlicher Komplexität und Anzahl beteiligter Personen. Hinzu kommen der Reifegrad eines Teams und die besonderen Vorlieben aller Beteiligten. Kanban-Fans möchten sich nicht gerne auf ein so umfangreiches Regelwerk wie Scrum einlassen und mehr selbst definieren. Für eingefleischte Scrum-Anhänger sind genau diese festen Rituale das, was Scrum ausmacht. Je mehr Personen und Teams an einem Projekt beteiligt sind, desto mehr verhelfen feste Spielregeln zu einem geordneten Prozessablauf.

Quellen:

https://www.it-agile.de
https://de.wikipedia.org/wiki/
https://digitaler-mittelstand.de
http://www.agiles-projektmanagement.info
http://winfwiki.wi-fom.de

 

Bildquellen