Wenn eine Spalte am Kanban-Board ihr WIP-Limit überschreitet, sollte man keine weitere Arbeit in der betreffenden Phase annehmen und erstmal das Vorhandene abarbeiten. Wie gesagt, das wird unbequem, wenn z.B. ein Entwickler zeitweise “unbeschäftigt” bleibt.
Wenn WIP-Limits öfter überschritten werden, ist das ein starker Hinweis zur Verbesserung des Prozesses. So gab es in einem Team z.B. ein Trello-Board mit den Spalten Ready for Development, Development, Code Review, Testing, Staging, Ready for Production, Done. Die Spalte “Staging” war für User stories (auch Bug Fixes usw.), die “fertig entwickelt” sind und in der Staging-Umgebung bereit stehen. Die User Stories auf dem Staging-Server wurden dann vom Auftraggeber durchgespielt und in die Spalte “Ready for Production” verschoben. Es gab immer mal wieder Situationen, in denen sich mehr als ein Dutzend Karten in der Spalte Staging angesammelt hatten.
Leider wurden die “fertig entwickelten” User stories vom Auftraggeber nur unregelmäßig durchgesehen, trotz guter Vorsätze hatte man nur alle 2 bis 4 Wochen die Zeit dafür. Oder anders ausgedrückt: das Entwicklungsteam hat die Karten ganz gut im “Flow” abgearbeitet, aber der Auftraggeber arbeitete im Batch-Modus: alle 2-4 Wochen wird der Stapel aufgelaufener Features, Bug-Fixes usw. abgearbeitet. Dass damit das Feedback verzögert wird, mit entsprechenden Qualitätseinbußen und Risiken für fortgesetzte Missverständnisse, liegt auf der Hand.
Eine naheliegende Verbesserung war, einen wöchentlichen Termin festzulegen, auf dem alle “fertigen” Karten der letzten Woche demonstriert und besprochen werden. Das Kanban-Board machte die Problematik zwar gut sichtbar, nur leider war vom Auftraggeber nicht mehr als “Dann versuchen wir mal, uns das öfter anzusehen” zu bekommen. (Ein weiteres Symptom einer überlasteten Organisation: Wir können beim besten Willen keinen wöchentlichen Termin für eine Stunde anbieten).
Die kontinuierliche Verbesserung des Software-Lieferprozesses ist übrigens Punkt 15 in unserem Flow Check.
Matthias Berth