Scrum und Kanban im Vergleich

Wer für non-IT Entwicklungsprojekte verantwortlich ist, wird sich irgendwann mit den Alternativen zum traditionellen Projektmanagement befassen – und sehr schnell auf die Begriffe:

  • Scrum und
  • Kanban

stoßen. Ins Auge springt gleich, dass in beiden Methoden große Tafeln (Whiteboards, Wände) eine wichtige Rolle spielen. Auf den Tafeln kleben Haftnotizen – die irgendwie in Spalten organisiert sind. Die  Haftnotizen entsprechen dabei Aufgaben – erledigten und unerledigten.

Kanban Board

Was ist SCRUM? Die kompakte Erklärung.

Scrum hilft Projektorganisationen bei Entwicklungsprojekten. Die Projektziele können dabei sein:

  • physische Produkte
  • Dienstleistungen,
  • eine neue Organisationsform,
  • ein neuer Prozess,
  • eine Marketing-Aktion

SCRUM macht im Vergleich mit Kanban mehr Sinn, wenn etwas Neuartiges durch ein Team entwickelt wird.


Wichtige Scrum-Prinzipien:

  • kleine, selbstorganisierende Teams
  • Aufteilung des Projektergebnisses in Inkremente
  • Aufteilung der Projektlaufzeit in kurze Iterationen (meist 1 bis 4 Wochen)
  • Visualisierung der Aufgabenerledigung in einer Iteration
  • Lernen und Anpassen von Projektziel und Arbeitsweise zwischen den Iterationen – durch Zusammenarbeit mit den „Projekt-Stakeholdern“
agiles entscheiden

Soweit Scrum … und Kanban?

Das Hauptziel von Kanban ist, unproduktives Multitasking – den häufigen Wechsel zwischen verschiedenen Aufgaben – zu reduzieren. Es gibt den treffenden Kanban-Slogan: „Stop starting – start finishing!“ – „Hör auf, Dinge anzufangen – Fang an, Dinge fertig zu stellen!„. Das gilt sowohl für Aufgaben im Projekt als auch für das Projektporfolio.

Die Kanban-Methode besteht aus 3 vergleichsweise einfachen Regeln:

  1. Visualisiere den Workflow, den Arbeitsfluss.
  2. Fang eine neue Aufgabe nicht an, bevor eine andere erledigt ist. Begrenze die Anzahl an Aufgaben in Bearbeitung!
  3. Messe die durchschnittliche Zeit zwischen Beginn und Fertigstellung einer Aufgabe. Finde Wege, diese Zeit zu verringern und möglichst konstant zu machen.

Was ist denn besser: Scrum oder Kanban?

Scrum ist das komplexere agile Vorgehensmodell. Scrum beinhaltet zum Beispiel eigene Werkzeuge für

  • das Anforderungsmanagement (User Stories, Product Backlog),
  • die Aufwandschätzung (Planning Poker) oder
  • den Umgang mit Behinderungen der Projektarbeit (Impediment Backlog).

Scrum definiert Rollen und Aufgaben (Product Owner, Scrum Master, Team Member) – und setzt Prioritäten (zügig und regelmäßig Produktinkremente ausliefern).

Grundsätzlich können Sie alle diese Werkzeuge, Rollen und Vorgaben auch im Projektmanagement mit Kanban nutzen.

Es gibt nur ein einziges Scrum-„Artefakt“, welches mit Kanban fundamental nicht kompatibel ist: und das sind Sprints.

Innovieren mit ASIT-Methode

Time boxing mit Sprints

Das Prinzip der Sprints bedeutet, dass die Projektarbeit in Takten, Zeitabschnitten konstanter Länge, erledigt wird. Taktgebundenes Arbeiten kann große Vorteile haben. Der wichtigste davon ist nachhaltige Produktivität. In jedem Sprint arbeitet das agile Team ein relativ konstantes Arbeitsvolumen ab. Es kennt die Länge der Takte – und es kennt das Volumen der anstehenden Arbeit. Es hat in vorherigen Sprints erfahren, dass es die Arbeit in dem Takt schafft, und zwar ohne sich dabei zu erschöpfen – also nachhaltig. Und es ist durch die Perspektive, in wenigen Wochen den Projektkunden die (Zwischen-) Ergebnisse des Sprints zu demonstrieren, hochmotiviert

Mit Kanban-Projektsteuerung erreichen Projektteams ebenfalls nachhaltige Produktivität. Allerdings nicht durch taktgebundenes Arbeiten, sondern durch das Vermeiden des größten Produktivitätskillers in modernen Organisationen und Projekten: die Verzettelung. Es werden zu viele Aufgaben begonnen, die Arbeit an jeder vielfach unterbrochen – und zu wenig, zu spät wird fertiggestellt.

Scrum Board

Unternehmen, die die Durchlaufzeiten in ihrer Fertigung dank Kanban drastisch verkürzt haben, sind sich nicht bewusst, dass sie nach demselben Prinzip auch die Durchlaufzeit  von Projektaufgaben verkürzen können. Und nicht nur die Durchlaufzeit von Projektaufgaben, sondern auch die von ganzen Projekten. Den Bestand an begonnen Aufgaben und Projekten zu deckeln, ist mindestens ebenso produktiv, wie den Bestand an Teilen in der Fertigung zu begrenzen.

Wenn Sie möchten, schauen Sie sich doch die beiden Taskboards auf dieser Seite mal etwas genauer an. Sie sehen, dass auf dem Kanban-Board in der WiP- (=Work-in-Progress) Spalte im Titel eine Zahl in einer Klammer steht. Diese Zahl ist die Obergrenze für die Anzahl offener Aufgaben. Also von Aufgaben, die begonnen aber noch nicht abgeschlossen sind. Eine neue Aufgabe darf erst angefangen werden, wenn eine angefangene fertig ist und nach rechts gezogen wird.

Flow versus Taktung für nachhaltige Produktivität

Kanban ist ein sogenanntes Flow-System: Ziel ist ein gleichmäßige Fluss der Flow-Items (Autos, Chips-Tüten, Aufgaben, Projekte) bei möglichst kurzer Durchlaufzeit.

Im Prinzip (und auch in der Praxis) kann ein Projektteam das Projekt mit Kanban steuern und – auf einmal oder sukzessive – alle Scrum-Praktiken, -Rollen und -Artefakte daran heften. Ausser Sprints! Wenn das Team sein Projekt letztendlich von Flow (Kanban) auf Taktung (Scrum) umstellt, ist es methodisch bei 100%-Scrum angekommen.

Dies ist die andere Art von hybridem Projektmanagement. Die meisten Menschen verstehen darunter Mischformen von agilem und planungsorientiertem Projektmanagement. Mindestens so wichtig ist zu verstehen, dass auch Hybride zwischen Scrum und Kanban (und traditionellem PM) sehr gut funktionieren können.