Der Haupteinflussfaktor dafür, wie lange eine Anforderung braucht, um die gesamte Produktentwicklung zu durchlaufen, ist die Zahl der anderen Anforderungen, die auch noch in Arbeit sind (WIP = work in progress). Der zweite Einflussfaktor ist die Zeit, die eine Anforderung braucht, um jeden einzelnen Prozessschritt zu durchlaufen.

Wir können also auf zwei Arten reagieren, um agil zu werden:

  1. Wir limitieren die Zahl der Aufgaben, die gleichzeitig in Arbeit sind
  2. Wir entwickeln schneller, erledigen also jede einzelne Aufgabe schneller

Der erste Weg ist der einfachere. Kanban geht deshalb den ersten Weg und limitiert WIP, also die Zahl der Aufgaben in Arbeit.

WIP kann man überall limitieren, in allen Tätigkeiten des Entwicklungs-Workflows. Sollte in einem Schritt (z.B. im Akzeptanztest) ein Flaschenhals entstehen, staut sich die Arbeit davor. Das System wird langsamer und Entwickler werden frei, die den Flaschenhals beheben können, so dass der Fluss wieder hergestellt wird. Danach wird das System wieder schneller.

Ist WIP nicht limitiert, arbeiten die Entwickler ungehindert weiter, so entsteht ein Berg ungetesteter Software, und es wird niemand frei, um den Testern zu helfen, weiterzukommen. Bei limiterter Arbeitsmenge kann dieses Problem nicht auftreten bzw. wird schnell beseitigt.

Mehr Informationen dazu auf den Seiten der Limited WIP Society: http://www.limitedwipsociety.org.