Klaus: Du verwendest Modelle, um unterschiedliche Zukunftsszenarien zu simulieren. Wie bist du darauf gekommen und wann setzt man Modelle und Simulationen am besten ein?

Troy: Ich habe eine elektrotechnische Ausbildung und bin damit vertraut, elektronische Schaltkreise zu simulieren. Das hat sich auch für die IT sehr passend angefühlt. Simulationen – und Monte-Carlo-Simulationen im Speziellen – werden eingesetzt, wenn es zeitlich unpraktisch oder zu komplex ist, eine mathematische Funktion zu formulieren, um ein Problem zu lösen. Simulationen schätzen das Ergebnis schnell und sie erlauben Experimente auf Basis des Modells, um zu messen, welche Maßnahmen die größte Auswirkung haben. Üblicherweise kommt die Monte-Carlo-Simulation zum Zug, wenn es in zusammenhängenden Prozessen viele Inputs gibt, die sich gegenseitig beeinflussen. Nehmen wir das Beispiel der Wettervorhersage, die du ja auch erwähnt hast: Ein kleiner Anstieg der Meerestemperatur verursacht Temperaturunterschiede, die in einem Gebiet die Regenwahrscheinlichkeit verändern. Diese Inputs verstärken sich gegenseitig und manche haben sogar Rückwirkungen auf frühere Inputs. Es ist ein komplexes System. Wir würden von der Wettervorhersage wegen dieser Zusammenhänge nie Perfektion erwarten, aber aus irgendeinem Grund erwarten wir von IT-Projekten absolute Vorhersagbarkeit, obwohl sie eine ähnlich kaskadierende Komplexität aufweisen.

Klaus: Warum ist es denn nicht einfach mit Schätzungen getan?

Troy: Ich habe sehr früh festgestellt, dass jeder Forecast und auch jede Schätzung verzerrt sind, wenn die Auswirkungen von Ereignissen wie Defektraten, zusätzlichen Anforderungen oder Unsicherheiten im Aufwand nicht simuliert werden. Traditionelle Schätzungen gehen von einem Zusammenhang zwischen Aufwand und Zeit aus, aber in komplexen Systemen kann die Arbeit auch einmal stillstehen oder aus unzähligen Gründen blockiert sein. Der Aufwand für eine Arbeit hängt dann überhaupt nicht mit den verstrichenen Kalenderwochen zusammen. Es ist also eine unpassende Relation, so als wenn ich sagen würde: Die Verspätung eines Flugzeugs wegen eines technischen Defekts hängt damit zusammen, dass ich drinsitze. Wir gehen aber immer davon aus, dass die tatsächliche Arbeitszeit einen Großteil der Lieferzeit ausmacht. Das stimmt für die meisten Softwareunternehmen und Softwareentwicklungsprozesse einfach nicht, wenn man zusätzlich zur reinen Entwicklungszeit auch noch die Zeiten für Test, Release und die Wartezeiten im Backlog mit einbezieht. Und diese Zeiten sollte man einkalkulieren, denn aus Sicht des Kunden ist die Arbeit nicht abgeschlossen, wenn die Entwicklung fertig ist, sondern wenn er sie fehlerfrei verwenden kann.

Klaus: Modelle und Simulationen – das klingt für viele im ersten Moment sehr kompliziert. Lohnt sich diese Vorgehensweise aus deiner Sicht überhaupt bzw. in welchen Zusammenhängen lohnt sie sich?

Troy: Meistens lohnt sie sich. Man muss ja etwas unternehmen, um die Ergebnisse zu erreichen. Wenn die Zahl der Mitarbeiter fixiert ist und der aktuelle Prozess kein bisschen verändert werden darf, zahlt es sich vielleicht nicht aus. Wie auch immer, selbst einfache Modelle können dabei helfen, die Auswirkungen und den Nutzen von Prozessveränderungen in Dollar oder Euros zu beziffern. Mir war es wichtig, Fragen zu beantworten und zu verstehen, welche Auswirkungen es haben würde, wenn zum Beispiel die Defektraten halbiert werden. Welche Fähigkeiten der Mitarbeiter bringen in welchen Situationen den größten Nutzen? Sind Defekte oder fehlende Testumgebungen das größere Problem? Einfache Modelle helfen, diese Fragen zu beantworten, und das geht über die traditionelle Schätzung hinaus. Die Antworten mit Geldeinheiten versehen zu können, hilft bei der Argumentation, warum eine Investition in die Veränderung wert ist, getätigt zu werden. Es hilft, gut informierte und abgewogene Entscheidungen zu treffen.

Klaus: Wie können solche Modelle aussehen?

Troy: Manchmal zeigt schon ein einfaches Spreadsheet die Auswirkung und den Nutzen eines Prozesses vorher und nachher. Ich habe früh herausgefunden, dass ich für die Antwort auf meine Fragen detailliertere Analysen anstellen musste. In meinem Fall wollte ich jeden Schritt jeder Arbeitseinheit modellieren, die den Prozess eines bestimmten Teams durchlief. Also habe ich eine einfache XML-Sprache entwickelt (SimML), mit der sich die Arbeit und der Prozess in Textform beschreiben lassen. Das sind üblicherweise 25 bis 50 Zeilen und es ist ein Mix aus Arbeit, historischen Daten und Definitionen des Teamprozesses. Wenn ich zum Beispiel eine Frage zu den Kosten von Defekten habe, spezifiziert das Modell die aktuelle Defektrate. Dann mache ich einen Forecast für das Lieferdatum und die Kosten, halbiere die Defektrate und sehe mir an, welcher Unterschied sich bei Datum und Kosten ergibt. Der Inhalt des Modells und seine Komplexität ergeben sich aus der Fragestellung. Ich kann gar nicht genug betonen, wie wichtig es ist, sich die Frage zu überlegen, bevor man ein Modell entwirft. Erst, wenn man die Fragen kennt, sollte man sich das einfachste Modell bauen, um die Frage beantworten zu können.

Troy Magennis arbeitet seit 1994 in der Softwareentwicklung. Er hat von der Qualitätssicherung bis zur Position des Vice President multinationaler Unternehmen sämtliche Funktionen innegehabt und hat sich vor einigen Jahren mit „Focused Objective“ selbstständig gemacht. Er konzentriert sich jetzt auf das, was ihn am meisten interessiert: Forecasting und die dazugehörigen Simulationen – vor allem Monte-Carlo-Simulationen. In diesem Bereich berät er Unternehmen wie Walmart, Microsoft, Skype oder Siemens.

Troy und ich werden diesen Winter zwei “Improving Kanban – Metrics Special” Trainings gemeinsam halten. Die Trainings sind als KMP II der Lean Kanban University zertifiziert. Meldet euch gleich an, die Plätze sind limitiert! Wien, 4.-5. Dezember und Düsseldorf, 6.-7. Dezember 2017.

Dieses Interview ist ein Auszug aus dem Buch Kanban in der Praxis, erschienen im November 2016 im Hanser Verlag.