Gestern habe ich die Maxime “Durchlaufzeiten verringern” mit dem Hinweis auf Verzögerungskosten erklärt. Es gibt noch einen weiteren sehr plausiblen Grund, Durchlaufzeiten zu verringern: Kosten, die entstehen während etwas unseren Software-Lieferprozess durchläuft. Damit meine ich nicht die reinen Bearbeitungskosten (z.B. Entwicklerstunden). Im Lean Thinking und allgemein in der Fertigung kennt man das unter der Überschrift “Kosten von Beständen” (Inventory). Lange Durchlaufzeiten sind verbunden mit hohen Beständen (via Little’s Law).
In der Produktion binden Bestände Kapital, weil wir ja das Material und einen Teil der Arbeit schon bezahlt haben, ohne dass wir bisher einen Umsatz dafür erzielt hätten. Bestände haben Schwund (man rechnet als Faustregel mit 10% pro Jahr): Metall rostet, Teile gehen kaputt beim hin- und hertransportieren, manchmal werden Teile obsolet usw. In einem Restaurant sollten viele Zutaten zügig verarbeitet werden (=kurze Durchlaufzeit), weil sie sonst verderben.
Aber gibt es sowas wie Bestände auch im Projektgeschäft bzw. in der Wissensarbeit? Ja, natürlich. Zu Beständen (Inventory) gehört alles, was darauf wartet, bearbeitet zu werden, Tickets, Designs, Projektideen usw. Wenn wir die Arbeit schon angefangen haben, ist es WIP, work in process.
Bleiben wir mal bei der eigentlichen Softwareentwicklung, wo sind da die Entsprechungen zu Schwund, Lagerkosten, Handlingkosten usw.?
Schwund ensteht, weil das Verständnis der Aufgabe mit der Zeit verloren geht. Man kann natürlich gegensteuern, indem man möglichst alles aufschreibt. Trotzdem muss der Entwickler sich wieder einlesen und eindenken, wenn er die Aufgabe später wieder anfasst. Genauso ist es mit dem Verständnis des Codes, das lässt schon innerhalb weniger Tage nach – manchmal bis zu dem Punkt, wo man sich nicht mehr erinnert, dass man diesen Abschnitt mal selbst geschrieben hat.
Lagerkosten gibt es kaum, Tickets in Jira sind fast kostenlos. Während in der Produktion große Lager unterhalten werden und sich die Bestände in der Fabrikhalle stapeln, bleiben sie in der Wissensarbeit leider sehr unauffällig.
Handlingkosten gibt es dagegen schon, z.B. wenn die Tickets priorisiert werden müssen, wenn ein Entwickler die nächste Aufgabe auswählt, oder wenn wieder mal ein Statusbericht fällig ist. All diese Dinge werden leichter, wenn nicht so viele Tickets in Bearbeitung sind.
Obsoleszenz gibt es definitiv, z.B. wenn eine Anforderung nicht mehr gefragt ist. Oder wenn wir angefangene Arbeit abbrechen, weil etwas dringenderes dazwischen kommt. Wenn die abgebrochene Arbeit nie wieder aufgenommen wird, ist der ganze bisherige Aufwand verloren. In der Produktion verkauft man solche Teile dann wenigstens noch als Schrott.
Kapital wird gebunden, sobald wir etwas vorfinanzieren. Wenn man nicht im Voraus bezahlt wird, bindet jedes angefangene Projekt Kapital. Die laufenden Kosten für eine interne IT-Abteilung sind insofern z.T. auch eine Vorfinanzierung für die aktuell laufenden Projekte. Rechenbeispiel: wenn wir durchgängig angefangene Projektarbeit von 10 Personenjahren im Bestand haben (d.h. es gab dazu noch kein nutzbringendes Release), dann bindet das dauerhaft Kapital in Höhe von 10 Jahresgehältern.
Sie sehen, egal ob es um Herstellung von Dingen oder Wissensarbeit geht, die Mechanismen sind ungefähr dieselben. Weil hohe Bestände und lange Durchlaufzeiten Hand in Hand gehen, lohnt es sich, Beides zu verringern.
Matthias Berth