This post was originally published on this site

Ist Kanban eine Softwareentwicklungs-Methode, ein Prozess, ein Framework oder eher eine Projektmanagement-Methode? Ist Kanban eine Alternative zu Scrum? Wie kann ich das einordnen?

Diese und andere Fragen beschäftigen mich seit längerem, dieser Artikel soll helfen, einige der Fragen zu beantworten.

Kanban ist ursprünglich eine Technik aus dem Toyota-Produktionssystem und dient der Selbststeuerung der Material- und Produktflüsse nach dem Hol-Prinzip. David Anderson griff diese Idee für die IT Branche auf und entwickelte sie weiter. 2007 veröffentlichte er sein Konzept auf mehreren Konferenzen, er gilt somit als Begründer von Kanban (für „Wissensarbeiter“).

  • Kanban ist eine evolutionäre Changemanagement Methode, welche mit kleinen Schritten zur Verbesserung eines bestehenden Prozesses führt. Diese vielen kleinen Verbesserungsschritte werden „Kaizen“ genannt, ein Begriff aus dem Japanischen. Man spricht auch vom kontinuierlichem Verbesserungsprozess resp. Continuos Improvement.
  • Kanban ist ein Pull-System (Hol-Prinzip): Das bedeutet, dass neue Aufgaben nicht in das System gedrückt werden (push), sondern, dass neue Aufgaben hineingezogen werden, sobald das System die Kapazität dafür hat.
  • Kanban beschränkt die Anzahl der parallelen Arbeiten, d.h. der Work in Progress (WIP) wird begrenzt. Man spricht auch von WIP-Limits.
  • Kanban selbst ist keine agile Methode, Kanban kann uns aber helfen eine agile Methode einzuführen.
  • Man könnte Kanban als Meta-Methode ansehen, welche mit anderen Vorgehensmodellen z.B. Wasserfall, Scrum, RUP (Rational Unified Process) kombiniert werden kann. Es ist also möglich, mit dem gerade existierenden Prozess zu starten und Kanban einzuführen!

Was ist Kanban nicht?

Kanban ist keine Softwareentwicklungs-Methode, kein Framework und es ist kein Prozess.

Ziele von Kanban

Mit Kanban soll eine nachhaltige Arbeitsgeschwindigkeit bei hoher Qualität erreicht werden. Optimierung der Durchlaufzeit anstatt der Optimierung der Auslastung. Verbesserung des bestehendes Prozesses in vielen inkrementellen Schritten. Mit Kanban sollen Aufgaben vor allem abgeschlossen und nicht nur angefangen werden. Alle Aufgaben der Wertschöpfungskette sollen visualisiert werden, hierdurch wird der bestehende Arbeitsprozess für das Team transparent gemacht. Engpässe und Probleme sollen aufgedeckt und gelöst werden, Durchlaufzeiten sollen vorhersagbar werden.

Die vier Grundprinzipien von Kanban

  1. Starte dort, wo Du gerade bist.
  2. Komme mit den anderen überein, dass inkrementelle, evolutionäre Veränderungen angestrebt werden.
  3. Respektiere den bestehenden Prozess, Verantwortlichkeiten und Titel.
  4. Fördere Leadership auf allen Ebenen.

Das vierte Grundprinzip ist erst später hinzugekommen. Leadership gibt es auf allen Ebenen. Mit Leadership ist hier nicht Führung gemeint, sondern vielmehr Leadership im Sinne von John P. Kotter:

Manager sind eher Verwalter, Leader dagegen Visionäre. Management steht eher für das perfekte Organisieren der Abläufe, planen und kontrollieren. Leadership bedeutet dagegen, die Geführten mit Visionen zu inspirieren und zu motivieren. Leadership schafft Kreativität, Innovation, Sinnerfüllung und Wandel.

Kurz gesagt: Ein Leader kann jeder sein! Es wäre doch toll, wenn von den Mitarbeitern, welche die Arbeit direkt ausführen, auch die Verbesserungsvorschläge kommen würden.

Kanban Praktiken

David Anderson beschreibt in seinem Buch „Kanban – Evolutionäres Change Management für IT-Organisationen“ die wichtigsten Kanban Praktiken:

  1. Visualisiere den Fluss der Arbeit (Workflow).
  2. Begrenze die Menge der begonnenen Arbeit (Work in Progress).
  3. Führe Messungen zum Fluss durch und kontrolliere ihn.
  4. Mach die Regeln für den Prozess explizit.
  5. Implementiere Feedback-Zyklen
  6. Verwende Modelle, um Chancen für Verbesserungen zu erkennen.

Der fünfte Punkt „Implementiere Feeback-Zyklen“ ist 2012 in Mayrhofen bei einer Konferenz hinzugekommen: Vortrag von David Anderson „How Deep is your Kanban“. Die PDF-Datei des Vortrags ist hier zu finden.

Zusammenfassung

Ich hoffe, ich konnte im ersten Teil meiner Artikelreihe grob erklären, was Kanban für Wissensarbeiter darstellt – was es ist, und was nicht. Ein Kanban Board alleine macht noch kein Kanban aus, dazu gehört mehr (z.B. WIP-Limits, Serviceklassen, Metriken, Exit-Kriterien).

In den nächsten Artikeln zu Kanban möchte ich über folgende Inhalte schreiben:

  • Organisation und Aufbau des Kanban Boards
  • Soll ich ein physikalisches Kanban Board verwenden oder lieber Software Kanban Board? Was ist, wenn die Teams örtlich verteilt sind? Welche Tools gibt es?
  • Wie starten wir mit Kanban?
  • Welche Service Klassen gibt es?
  • Begrenzung der angefangenen Arbeit mit WIP-Limits
  • Personal Kanban
  • Communitiy und Konferenzen rund um Kanban
  • Metriken wie z.B. WIP-Tracking mit dem Cumulative Flow Diagram, Durchlaufzeit, Termintreue, Durchsatz, Fehlerrate