Kanban
Eine flussbasierte Methode, die Arbeit auf einem Board sichtbar macht, begrenzt, wie viel gleichzeitig in Arbeit ist, und neue Arbeit nur bei freier Kapazität zieht, ganz ohne feste Iterationen.
Kanban hat zwei Kernideen: die Arbeit sichtbar machen und die laufende Arbeit begrenzen. Man stellt jedes Element auf ein Board mit Spalten für jede Phase (zu tun, in Arbeit, Review, fertig) und deckelt, wie viele Elemente gleichzeitig in jeder aktiven Spalte liegen dürfen. Ist eine Spalte voll, beginnt niemand neue Arbeit, bis etwas herauswandert. Dieser Deckel ist der ganze Punkt: Er zwingt das Team, Dinge fertigzustellen, bevor es mehr anfängt.
Der Kontrast zu Scrum ist der Takt. Scrum bündelt Arbeit in feste Sprints und plant an jeder Grenze neu. Kanban hat keine Sprints. Arbeit wird kontinuierlich gezogen, sobald Kapazität frei wird, und Prioritäten lassen sich jederzeit ändern, ohne das Ende eines Sprints abzuwarten. Es gibt keine Commitment-Zeremonie, kein Sprint Review, keine künstliche Zwei-Wochen-Box.
Wählt Kanban, wenn Arbeit unvorhersehbar und unterbrechungsgetrieben eintrifft (Support, Operations, Plattform-Teams) oder wenn ein Team reif genug ist, dass das Sprint-Gerüst zu reinem Overhead geworden ist. Wählt Scrum, wenn ein Team den Rhythmus und das erzwungene Review braucht, um Lieferdisziplin aufzubauen, oder wenn Stakeholder einen vorhersehbaren Demo-Takt zum Planen brauchen.
Die ehrliche Version: Bei den WIP-Limits liegt der Wert, und genau dieser Teil wird von Teams gerne stillschweigend ignoriert. Ein Kanban-Board ohne WIP-Limit ist nur eine To-do-Liste mit zusätzlichen Spalten. Wenn das Team fünf Dinge anfängt und keines fertigstellt, ist das Limit die Lösung, nicht ein größeres Board.