Den Release-Zyklus verkürzen

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:

• Zeit, die mit der Anzahl Features (oder Bugfixes, Tickets, sonstige Wünsche) wächst. Dazu gehören die eigentliche Softwareentwicklung, Tests eines einzelnen Features u.ä. Das sind die variablen Kosten für das Release
• Zeit, die wir für jedes Release aufwenden müssen, egal, wie groß es ist. Dazu gehören etwa Regressionstests, formelle Abnahme, Deployment usw. Das sind die Fixkosten für das Release.

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.

Das Investitionsrelease

Im Beispiel wollen wir von 4-wöchigen Releases (zu je 100 Personentagen) auf 2-wöchige Releases kommen, bei derzeitigen Fixkosten von 20 Personentagen (PT) pro Release, also einem Overhead von 20%.

Wenn wir einfach nur doppelt so oft ausliefern, verdoppelt sich leider auch der Overhead. Das lässt sich wahrscheinlich eher schlecht verkaufen innerhalb Ihrer Organisation. Statt dessen stellen wir uns die Aufgabe, die Fixkosten von 20 PT auf 10 PT zu halbieren, womit wir wieder bei akzeptablen 20% Overhead wären.

Das ist nicht zum Nulltarif zu haben – irgendwoher müssen wir die Kapazität für die nötigen Veränderungen im Lieferprozess nehmen.

Als Lösung haben wir das Investitionsrelease entwickelt. Das Investitionsrelease ist ein Deal, den Sie den anderen Beteiligten anbieten: “OK, wir schalten ab sofort um auf den neuen Rhythmus. Seid Ihr im Gegenzug bereit, für einige Zeit weniger Features (Tickets, usw.) zu akzeptieren?” Ein Teil der Entwicklungs-Kapazität wird also umgewidmet, von der Produktion von Features zur Verringerung der Fixkosten.

In unserem Beispiel können wir die 50 PT aufteilen:

20 PT für Features und Bugfixes aus dem Produktivbetrieb. The show must go on. Es ist übrigens ratsam, die Kapazität für die Behebung von Bugs aus dem Produktivbetrieb nicht zu verringern. Im alten vier-Wochen-Zyklus konnten wir in zwei Wochen 40 PT für Features und Bugfixes verbrauchen, jetzt sind es nur noch 20 PT. Die Produktion von neuen Features wird also um mehr als 50% zurückgehen müssen.

10 PT für Verringerung des Release-Overheads. Diese Kapazität sollte möglichst früh im Releasezyklus eingesetzt werden, um zum Ende hin möglichst schon von Verbesserungen zu profitieren.

20 PT für Fixkosten (alt). Wir setzen hier den Aufwand bewusst vorsichtig an – falls wir in diesem Release noch keine wirksame Verbesserung erreichen können, bleibt es bei 20 PT. In der Praxis gibt es aber sehr oft Maßnahmen, die für wenig Aufwand schnell die Fixkosten des Releases verringern können.

Wenn Sie großes Glück haben, reicht ein Investitionsrelease aus, um die Fixkosten zu halbieren. Wenn nicht, dann hängen Sie ein oder mehrere weitere Investitionsreleases dran. Je nach politischer Großwetterlage können Sie die frei werdende Kapazität zur weiteren Verringerung der Fixkosten investieren, oder langsam die Rate an neuen Features wieder hochfahren. Hier ist eine Reihe von drei Investitionsreleases, die jeweils 10 PT für die Verringerung des Release-Overheads einsetzen:

In diesem Beispiel wird die Produktion von neuen Features wieder hochgefahren, soweit es die festen Anteile für Bugfixes und Investition erlauben. Es ist sinnvoll, den jeweiligen Zeitaufwand zu erfassen (Features, Bugfixes, Investition, Release-Overhead), um weitere Investitionen rechtfertigen zu können.

Sinnvolle Investitionen finden

Bleibt noch zu klären, welche Investitionen wir zur Verringerung des Release-Overheads machen können. Dazu muss man manchmal die Perspektive der Software-Entwickler etwas zurechtrücken: Sie sind nicht nur für die Produktion von Features oder das Beheben von Bugs verantwortlich, sondern sollten ihre Fähigkeiten auch zur Unterstützung des gesamten Lieferprozesses einsetzen.

Alles, was irgendwo Zeitverluste verringern kann, ist ein Kandidat für eine Investition:

• Bereitstellung von Testumgebungen
• Definition und Laden von Beispieldaten
• automatisierte Regressionstests
• automatisierte Tests für die Integration mit Drittsystemen
• bessere Unterstützung für manuelle Tests

Im letzten Punkt kann man z.B. Bestellungen mit bestimmten Rabatten für die Tester mit einem Klick verfügbar machen. Allzu oft ist es ja so, dass ein Tester sich durch etliche Schritte klicken muss, bevor er das eigentlich zu testende Feature erreicht. Für solche Zeitverluste sind Entwickler manchmal etwas betriebsblind; es ist also sehr hilfreich, wenn Entwickler und Tester in demselben Team sind.

Die Investitionen kann man einfach priorisieren, indem man erfasst:

• Wie lange dauert es jetzt (PT pro Release)?
• Welche Zeitersparnis können wir in diesem Release-Zyklus erreichen?
• Wieviel Entwicklungsaufwand kostet das?

Dann wählt man die Investitionen, die mit möglichst geringem Entwicklungsaufwand möglichst viel Zeitersparnis erreichen.

Zusammenfassung

Die Vorteile des Investitionsreleases sind:

• Es wird sofort auf den kurzen Release-Zyklus umgestellt.
• Es wird weiter produziert, wenn auch mit verringerter Rate an Features.
• Die Kapazität für Bugfixes bleibt erhalten.
• Es sind keine grundlegenden Änderungen am Entwicklungsprozess nötig.
• Die Verbesserungen können in kleinen Schritten und am Bedarf ausgerichtet gemacht werden.

Es hindert Sie natürlich niemand daran, die Investitionsreleases noch etwas fortzusetzen, bis der Overhead unter die ursprünglich akzeptierten 20% gefallen ist. Damit hätten Sie dann einen mehrfachen Nutzen: nicht nur größere Agilität, bessere Qualität und verringerte Verzögerungskosten durch schnellere Zyklen, sondern auch höhere nominelle Produktivität durch verringerte Fixkosten für Releases.

Und wir begrüßen es natürlich ganz besonders, wenn Sie auch nach einigen Investitionsreleases einen Teil Ihrer Kapazität weiterhin in die kontinuierliche Verbesserung Ihres Software-Lieferprozesses investieren.