Kanban ist ein System zur Visualisierung und zum Change Management. Es macht einen bestehenden Workflow sichtbar und verändert ihn dadurch, in der Regel zum Besseren. Kanban heißt auf Japanisch (Signal)karte. Toyota hat das System in den 80er Jahren eingeführt, ursprünglich kommt es aus der Fertigung. In der IT nutzen Teams Kanban, um bei der Softwareentwicklung den Überblick zu behalten. Vor allem, um weniger Arbeiten parallel laufen zu lassen und Probleme früher zu erkennen.
Kanban ist nicht Scrum
Kanban ist nicht dafür gedacht, Scrum zu ersetzen. Es ist eine Ergänzung zu Scrum und bringt vor allem Visualisierung in ein Projekt.
- Entwickler und Projektleiter haben denselben Überblick über die laufenden Projekte.
- Das Team arbeitet effizienter, weil weniger Aufgaben gleichzeitig laufen.
- Die Qualität steigt, weil nichts mehr ungetestet nach draußen geht.
Vorteile von Kanban
Kanban hat folgende Vorteile:
- Ein Board zeigt alle anstehenden Aufgaben.
- Der Projektleiter gibt vor, was als Nächstes drankommt (Next).
- Der Entwickler zieht das Ticket, an dem er arbeitet, in die Spalte Process. Alle sehen, wer gerade woran arbeitet.
- Bei Kanban läuft nichts ungetestet ins Board.
Das Team sieht auf dem Board:
- was steht an
- wie viel steht an
- was ist zu tun
- was ist erledigt
- wo muss das Team aufholen
- was sind die wirklich wichtigen Issues
Mit diesem Überblick steuerst du als Projektmanager gezielter, welche Issues zuerst drankommen. Dafür gibt es bei Kanban die Fastlane, eine eigene Zeile für dringende Issues, die vor allen anderen Aufgaben liegen. Der Entwickler sieht ohne Nachfrage, was zu tun ist.
In Redmine sieht das so aus. Jede Spalte zeigt die Anzahl der Tickets, jede Karte Priorität, Fälligkeitsdatum, Fortschritt und Zielversion:
Scrum vs. Kanban
Die größten Unterschiede zwischen Scrum und Kanban sind:
Scrum
Bei Scrum arbeitet in der Regel ein Team an einem einzigen großen Projekt.
Kanban
Bei Kanban organisierst du viele Projekte gleichzeitig. Oft arbeiten mehrere Teams daran und wechseln zwischen den Projekten.
Dabei helfen die Swimlanes, also die waagrechten Zeilen des Boards. Sie unterstützen bei der Priorisierung, zum Beispiel als Fastlane für alles, was wichtiger ist als die übrigen Issues. Farblich unterschiedliche Issue-Zettel machen die Priorisierung zusätzlich sichtbar.
3 wichtige Regeln für das Kanban Board
- Reihenfolge beachten
- Quotas definieren
- Tests sicherstellen
- Die Reihenfolge ist die wichtigste Regel. Beispiel: Der Entwickler zieht sich kein neues Ticket, solange ein älteres Issue von ihm noch in der Spalte Deploy liegt und nicht den Status Done hat.
- Damit die Reihenfolge funktioniert, braucht ihr Quotas, also eine Obergrenze pro Spalte. Beispiel: In einer Spalte dürfen höchstens x Tickets liegen. In Redmine setzt Du das als WIP-Limit pro Spalte um. Sammeln sich dort mehr Tickets an, klärt gemeinsam, woran das liegt.
- Tests: Im Idealfall läuft kein Issue über das Board, das nicht vorher ein weiteres Team-Mitglied getestet hat.
Kanban selbst ist einfach. Du brauchst ein leeres Board und etwas Disziplin. Damit siehst du schnell, wo es hakt, und kannst rechtzeitig eingreifen.
Auf unserer Themenseite gibt es weitere Informationen zur Agilen Produktentwicklung. Wie sich ein Kanban Board mit Swimlanes und Quotas direkt in Redmine abbilden lässt, zeigt das Kanban Board des Reporting Plugins.