Wir fokussieren hier viel auf WIP (work in process), das ist es ja auch, was oft an Kanban-Boards dargestellt wird. WIP ist aber nur eine von insgesamt drei Art von Beständen (inventory):

1. Bestände an Rohmaterial. Das kommt von Zulieferern, bei einer Bäckerei sind es das Mehl im Lager und die Eier im Kühlschrank. In der IT ist es das 300 Seiten starke Word-Dokument mit Spezifikationen (oder Spezifiktionen), oder die noch nicht angefangenen Support-Tickets.
2. Umlaufbestände, auch bekannt als WIP. Das sind in der Bäckerei der Teig, der gerade in der Knetmaschine ist, die Brötchen, die gerade gebacken werden usw. Bei IT-Projekten sind es z.B. die Features oder die User Stories, die wir gerade bearbeiten.
3. Bestände an Fertigerzeugnissen, also Produkte, die wir fertiggestellt aber noch nicht ausgeliefert bzw. verkauft haben. Unser Aufwand wurde zwar schon erbracht, aber es gab bis jetzt dafür noch keinen Kundennutzen. In der Bäckerei sind das die Brote und Brötchen, die im Laden liegen. In der Softwareentwicklung sind es Features oder Applikationen, die fertig entwickelt und getestet wurden, aber noch nicht ausgeliefert sind.

Alle drei Arten von Beständen haben Nachteile (versteckte Folgekosten). Über WIP haben wir schon Einiges gesagt, man kann Kanban-Boards einordnen als ein Mittel, um WIP (Umlaufbestände) zu begrenzen.

Die Bestände an Fertigerzeugnissen werden mit DevOps-Praktiken (Continuous Delivery, Continuous Deployment) angegangen. Wenn man 250 Mal pro Woche ein Deployment macht, hat man nicht mehr allzu viele Features im Bestand, die zwar fertig aber noch nicht ausgeliefert sind.

Es bleibt der erste Punkt – Bestände an Rohmaterial – als allgemein etwas unterbelichtetes Thema. Wenn ein Projektplan auf zwei Jahre angelegt ist, enthält er etliche Annahmen darüber, wie die Welt in zwei Jahren aussehen wird, was unsere Kunden dann als wertvoll betrachten werden usw. Dass diese Wetten auf die Zukunft nicht immer gut gehen, weiß jeder, der schon mal ein Feature oder eine Applikation “verschrottet” hat.

Wie können wir also vermeiden, dass neue Anforderungen in großen Stapeln hereinkommen? Auf Projektebene heißt das: kürzere Projekte machen, das verringert auch die “Bestände an Rohmaterial” (und spart Verzögerungskosten).

Wenn man das immer weiter treibt, kommt man zur Devise: “Produkte statt Projekte” (bzw. “Services statt Projekte”). Statt mehr oder weniger großer einmaliger Projekte gibt es einen kontinuierlichen Fluss von Veränderungen, die nur noch wenig Zeit von der Idee bis zur Umsetzung brauchen. Aus Projektteams, die nach einem Projekt auseinander laufen, werden stabile Produktteams; Projektmanager wandeln sich zu Produktmanagern; einmalige Projekt-Budgets werden zu kontinuierlicher Finanzierung mit laufender Messung des erzielten Nutzens. Damit wären dann die “Bestände an Rohmaterial” ganz gering, weil wir im Prinzip für jede Idee sofort mit der Umsetzung starten können. Sicher, man kann Projekte nicht komplett durch kontinuierlich bewirtschaftete “Produkte” oder Services ersetzen. Aber es lohnt sich darüber nachzudenken, wo und wie man so ein Wandel vollziehen könnte. Wenn Sie mehr wissen wollen: Der Artikel “#noprojects - If You Need to Start a Project, You’ve Already Failed” von Evan Leybourn geht etwas in die Tiefe.

Matthias Berth