Projektmanagement & ITIL

Kanban

Overview

Kanban stammt aus der Produktionssteuerung bei Toyota und wurde ab etwa 2004 für Wissensarbeit adaptiert. Kanban steuert Arbeit nach dem Pull-Prinzip: Neue Aufgaben werden erst begonnen, wenn Kapazität frei ist. Das Board mit Spalten für die Arbeitsschritte macht Engpässe und liegen gebliebene Aufgaben sichtbar.

In IT-Teams passt Kanban gut für Support, Betrieb und Infrastrukturprojekte, weil Arbeit dort laufend und ohne feste Iterationen eintrifft. Viele Teams kombinieren Kanban mit ITIL-Practices, etwa ein Board für Changes oder für Verbesserungsmaßnahmen.

Abgrenzung: Scrum arbeitet in festen Sprints mit definierten Rollen. Kanban schreibt keine Rollen und Iterationen vor und lässt sich in bestehende Abläufe einführen. Ein Board allein ist noch kein Kanban, entscheidend sind WIP-Limits und das aktive Steuern des Flusses.

How it works

Der Kanban Guide (Version Mai 2025) beschreibt drei Praktiken:

  1. Workflow definieren und visualisieren: Start- und Endpunkt, Arbeitsschritte als Spalten, Regeln für den Übergang.
  2. Aufgaben aktiv steuern: Work in Progress (WIP) begrenzen, alternde Aufgaben im Blick behalten, Blockaden lösen.
  3. Den Workflow verbessern, basierend auf dem, was die Daten zeigen.

Vier Flow-Kennzahlen sind verpflichtend: WIP (begonnene, nicht fertige Aufgaben), Throughput (fertige Aufgaben pro Zeiteinheit), Work Item Age (Alter offener Aufgaben) und Cycle Time (Dauer von Start bis Ende).

Werkzeuge sind z. B. Microsoft Planner, Azure Boards, Jira oder Trello. Azure Boards unterstützt WIP-Limits, geteilte Spalten und ein Cumulative Flow Diagram.

Benefits

  • Engpässe werden sichtbar, weil sich Karten vor einer überlasteten Spalte stauen.
  • Weniger Multitasking durch WIP-Limits, dadurch werden Aufgaben schneller fertig.
  • Prognosen auf Datenbasis: Aus Cycle Time und Throughput lässt sich ableiten, wann Arbeit voraussichtlich erledigt ist.
  • Niedrige Einstiegshürde, da Kanban auf dem bestehenden Ablauf aufsetzt und ihn schrittweise verändert.

Practical example

Das vierköpfige Infrastrukturteam eines Handelsunternehmens jongliert Projekte, Störungen und Anfragen gleichzeitig. Es führt ein Board in Azure Boards mit den Spalten Eingang, Analyse, Umsetzung, Test und Erledigt ein und begrenzt die Umsetzung auf vier parallele Aufgaben. Nach zwei Monaten zeigt die Auswertung, dass Aufgaben im Test am längsten warten. Das Team plant feste Testslots ein, die Cycle Time sinkt deutlich.

Things to keep in mind

  • Setze WIP-Limits von Anfang an, auch wenn sie anfangs unbequem sind, ohne Limits ist das Board nur eine Aufgabenliste.
  • Formuliere explizite Regeln für jede Spalte, z. B. wann eine Aufgabe als getestet gilt.
  • Schau regelmäßig auf alte Karten (Work Item Age), denn sie zeigen Blockaden früher als jede Statusrunde.
  • Trenne ungeplante Arbeit (Störungen) farblich oder in einer eigenen Bahn, damit sie sichtbar bleibt.

Conclusion

Kanban ist für IT-Betriebsteams oft die passendere agile Methode als Scrum, weil Arbeit dort laufend eintrifft. Der Nutzen entsteht durch WIP-Limits und Flow-Kennzahlen, nicht durch das Board allein.

Further reading

Related articles