Auf dem Weg zum besseren Software-Lieferprozess ist die Länge des Release-Zyklus ein wesentlicher Indikator. Deswegen lautet auch die erste Frage aus unserem Flow Check, 15 Schritte zum besseren Software-Lieferprozess: “Liefern Sie regelmäßig, mindestens einmal pro Monat, Software?”
Die nächsten Schritte wären dann etwa:
Wenn Sie nicht genau in dieses Raster fallen, weil Sie z.B. alle 10 Tage liefern wollen, ist das auch kein Problem. Wichtig ist uns nur, dass es eine Entwicklung hin zum Ideal der kontinuierlichen Lieferung gibt.
Wie kann man nun den Release-Zyklus verkürzen? Zuerst sollte die Zykluszeit stabil sein, wenn also bei Ihnen aus 4 Wochen noch gelegentlich 5 oder 6 Wochen werden, dann sollten Sie an diesen Verzögerungen arbeiten, bevor Sie z.B. einen zweiwöchigen Release-Zyklus anstreben.
Unser Ansatz zur Verringerung der Zykluszeit baut auf dem Konzept der Fixkosten für ein Release auf. Der Zeitaufwand für einen ganzen Release-Zyklus lässt sich nämlich in zwei Gruppen einteilen:
Mit der Erfahrung aus vergangenen Releases kann man die Fixkosten ganz gut schätzen. Nehmen wir mal an, wir liefern derzeit alle vier Wochen mit einem Gesamtaufwand von 100 Personentagen. Davon entfallen in unserem Beispiel zwanzig Personentage, also 20%, auf die mit dem Release verbundenen Fixkosten.
Wenn uns nun jemand die Pistole auf die Brust setzt und sagen würde: “Ab morgen brauchen wir alle zwei Wochen ein Release”, könnten wir eigentlich antworten: “OK, machen wir, wenn Ihr wollt, aber das kostet etwas…”. Hier ist der einfache Plan: In zwei Wochen haben wir 50 Personentage (PT) zur Verfügung, wovon wir 20 PT für das Release brauchen. Es bleiben dann nur noch 30 PT übrig für neue Features, also liefern wir entsprechend weniger.
Nach vier Wochen haben wir also 40 PT für Fixkosten aufgewendet und 60 PT für produktive Arbeit. Vorher, im Vier-Wochen-Zyklus, waren das 80 PT, wir liefern also ungefähr 25% (60 statt 80 PT) weniger. Das sind also die Konsequenzen, wenn wir ab morgen alle zwei Wochen ausliefern und sonst nichts ändern. (Übrigens: Die 25% Verringerung sind etwas pessimistisch. In der Praxis wird durch verringertes Multitasking, schnelleres Feedback und kleinere Stapel die Qualität und die Produktivität steigen.)
Nochmal andersherum: wenn häufigeres Liefern mehr Overhead verursacht, warum liefern wir dann nicht seltener, alle 12 Wochen beispielsweise? Dann hätten wir 300 Personentage in einem Releasezyklus, davon nur 20 PT Release-Aufwand, also 6,7%, statt 20% Overhead. Ein toller Effizienzgewinn, oder? Es wäre insgesamt leider ein Verlust, denn der längere Releasezyklus verursacht mehr Verzögerungskosten. Schließlich sind die Features bzw. Bugfixes eines ganzen Quartals nicht in Produktion, während alle auf das nächste Release warten müssen.
Der jetzige Releasezyklus ist also ein Kompromiss: Man ist bereit, 20% Overhead zu akzeptieren, wenn es dafür alle 4 Wochen eine Lieferung gibt. Man ist aber nicht bereit, 40% Release-Overhead zu akzeptieren, auch wenn es dafür alle zwei Wochen eine Lieferung gibt. Und 12-Wochen-Releases haben zwar nur einen Overhead von 6,7%, sind aber viel zu lang.
Lean Thinking: Rüstkosten verringern
Ein wesentliches Ziel beim Lean Thinking ist die Verringerung der Stapelgröße (batch size). In unserem Zusammenhang ist ein Release solch ein Stapel: Eine Gruppe von Features, die gemeinsam bearbeitet werden, von der Spezifikation bis zum Test und zur Auslieferung. Große Stapel in der Produktion sind nachteilig, weil sie Lageraufwand verursachen, Qualitätsprobleme verstecken, und weil sie die Reaktion auf geänderte Kundenwünsche verlangsamen. Bei der Softwareentwicklung gibt es entsprechende Nachteile von großen Releases. Das Ideal in der Lean Production ist die Stapelgröße 1, d.h. jedes Teil kann den gesamten Prozess unabhängig von allen anderen durchlaufen.
Im ursprünglichen Verständnis von Lean aus der Industrie entspricht unser Release-Overhead den Rüstkosten, also dem Zeitaufwand für das Umrüsten einer Maschine von Teil A auf Teil B. Das kann etwa das Einspannen eines anderen Bohrers oder der Wechsel von weißer auf rote Farbe in einer Lackieranlage sein.
Hohe Rüstkosten wurden als Argument dafür verwandt, dass man ziemlich große Stückzahlen von demselben Teil (Lose) herstellen muß, bevor man die Maschine auf ein anderes Teil umstellt. Größere Stückzahlen verursachen andererseits aber auch höhere Lagerkosten, so dass man einen Kompromiss finden muss. Für gegebene Rüstkosten und Lagerkosten wurden also “optimale Losgrößen” berechnet, die die Gesamtkosten minimieren, indem sie den Aufwand für eine Umrüstung auf möglichst große Stückzahlen verteilen.
Ein Durchbruch im Lean Thinking bestand nun darin, das Konzept der optimalen Losgröße auf den Kopf zu stellen. Die Rüstkosten wurden nicht mehr als gegeben hingenommen, sondern dramatisch verringert. Zum Beispiel wurden Pressen für Karrosserieteile so verändert, dass statt zwei Stunden für eine Umrüstung nur noch sechzehn Minuten gebraucht werden. Damit konnte man in wesentlich kleineren Losgrößen produzieren, was den ganzen Produktionsprozess schlanker machte.
Unser Ziel sind häufigere, also auch kleinere Releases. Der Weg dorthin ist die aktive Verringerung der Fixkosten für ein Release, so dass wir uns häufigere Releases auch leisten können.
Ein Plan dazu kommt morgen.
Matthias Berth