Verbesserungen als Investition betrachten? Gut und schön, aber wo sollen wir investieren? Wenn man erstmal einen Blick dafür entwickelt hat, sieht man ja überall Verbesserungspotenzial, ob beim Yak Shaving oder bei der Bewältigung von kleinen und großen Katastrophen oder allgemein im Code (z.B. Refactoring)
Wie vermeiden wir, dass bei all dem Verbesserungseifer nicht die eigentliche Aufgabe (z.B. das nächste Release) zu kurz kommt?
Eric Ries (derselbe, der das Konzept “Lean Startup” entwickelt hat) beschreibt einen originellen Ansatz dazu: “5 Whys” und anteilige Investitionen. Wenn ein Problem auftritt, identifiziere zunächst die Ursachen. Das ist das bekannte “5 Whys” – frage immer weiter “Warum?”, bis Du bei einer oder mehreren Grundursachen angekommen bist. Dann verwende einen kleinen Betrag für die (teilweise) Behebung der Ursachen auf jeder Ebene. Das sind die “anteiligen Investitionen”. Der Ansatz ist überblicksweise beschrieben in Eric Ries: The Five Whys for Start-Ups (Harvard Business Review, 2010), ausführlicher und mit Fallbeispiel im Blogeintrag Five Whys von 2008.
In Fortsetzung des Beispiels von gestern (Yak Shaving), können wir uns eines der Probleme vornehmen und fragen:
(Die Zahl 5 in “5 Why” muss man nicht wörtlich nehmen, und es gibt auch oft mehrere Stränge von Ursachen; aber das Prinzip “nicht bei der unmittelbaren Ursache stehenbleiben” gilt.)
Die übliche Ursachenforschung (root cause analysis) würde ungefähr hier enden: Aha, weil die Lasttests weggelasen wurden, haben wir jetzt keine Beispieldaten auf dem Test-Server. Also geben wir eine neue Richtlinie heraus: Nie wieder die Lasttests weglassen! Oder wir starten eine Initiative: Lasttests so schnell machen, dass sie innerhalb von 5 Minuten durchlaufen – dann kommt niemand mehr in die Versuchung, sie wegzulassen. Der geschätzte Zeitaufwand dafür beträgt 2 Wochen. Hier wird’s schwierig: Um eine kleine Unannehmlichkeit in Zukunft zu vermeiden, sollen wir 2 Wochen aufwenden?
Eric Ries behandelt das etwas differenzierter und platziert kleine vorbeugende Investitionen entlang der gesamten Ursachenkette. In unserem Beispiel wäre das etwa so:
Warum ist das anteilige Investieren sinnvoll? Es dient natürlich zum ersten der Vorbeugung auf jeder Ebene. Je höher man in der Ursachenkette kommt, desto größer wird (hoffentlich) die positive Wirkung sein. Wenn wir die Lasttests jetzt etwas schneller machen, kommt uns das auch in anderen Bereichen zugute. Oder wenn wir lernen, die Last des Datenbank-Clusters besser zu diagnostizieren, können wir auch in anderen kritischen Situationen besser reagieren.
Zum zweiten vermeidet es die “große Investition”, die mit einem Schlag alles besser machen soll. Das funktioniert nämlich eher selten, wir haben dafür die Kapazität nicht, und die große Investition wäre manchmal einfach zu teuer.
Zum dritten werden die Aufwendungen dosiert. Ursachen, die häufiger auftreten, bekommen automatisch mehr “Zeitscheiben” unserer Investitionen zugeteilt. Jede Investition in Verbesserung ist ja eine Wette: das was ich heute dafür aufwende, werde ich hoffentlich in der Zukunft mehrfach einsparen. Diese Wetten sind schwer zu machen, denn wer weiß schon, welche unerwarteten(!) Probleme nächste Woche auftreten? Wir begrenzen also den Wetteinsatz: Falls das Problem nie wieder auftritt, haben wir nur eine kleine Zeitscheibe verloren. Außerdem lassen wir die Investitionen gewissermaßen vom System selbst auswählen: häufiger auftretende Ursachen bekommen automatisch mehr Investition. Statt mit der Gießkanne in alles zu investieren, was irgendwie verbesserungswürdig scheint, konzentrieren wir uns auf Dinge, die zumindest schon einmal als Problem aufgetreten sind.
Matthias Berth