[SL] Verbesserungen steuern mit "5 Why" und anteiligen Investitionen

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:

  1. Die Testdaten aus dem Produktivbetrieb sind nicht auf dem Test-Server gelandet. Warum? Weil das Export-Skript von den Administratoren abgebrochen wurde.
  2. Warum wurde das Skript abgebrochen? Weil der Datenbank-Cluster überlastet war. Sie haben alle Jobs abgebrochen, die nicht für den laufenden Betrieb essenziell waren.
  3. Warum war der Cluster überlastet? Das passierte kurz nachdem die neueste Version eingespielt war. Eine halbe Stunde nach unseren Eingriffen hat sich die Situation normalisiert. Genaueres wissen wir noch nicht.
  4. Warum haben wir das Performance-Problem nicht erkannt, bevor wir die neue Version eingespielt haben? Wir haben keine Lasttests durchgeführt, sonst hätten wir das Problem wahrscheinlich bemerkt.
  5. Warum gab es keine Lasttests? Weil die Änderung so klein war, haben wir die Lasttests übersprungen, um Zeit zu sparen. Normalerweise dauern die Lasttests nämlich ca. eine Stunde.

(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:

  1. Können wir dafür sorgen, dass Produktivdaten importiert werden, obwohl das Export-Skript abgebrochen wurde? Man könnte z.B. ersatzweise die Produktivdaten vom Vortag verwenden.
  2. Kann man in Zukunft besser diagnostizieren, welche Prozesse den Datenbank-Cluster wirklich belasten? Vielleicht hätte man das Export-Skript ja gar nicht abbrechen müssen, weil es kaum Last erzeugt?
  3. Die Überlastung des Clusters muss gesondert untersucht und nachhaltig vermieden werden.
  4. Können wir irgendwie dafür sorgen, dass Lasttests automatisch durchgeführt werden? Oder können wir vielleicht zuverlässiger vorhersagen, ob eine “kleine Änderung” Auswirkungen auf die Performance haben kann?
  5. Lassen sich die Lasttests mit wenig Entwicklungsaufwand etwas beschleunigen?

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

Alle Emails