“Frohes neues Jahr!”, sagte ich zu Rolf als wir anstießen. Es war zwar der 10. August. Für uns war es aber das erste Mal, dass wir uns in 2023 sahen.

Überhaupt war dieses Jahr vieles anders. Erstmals nahm ich nicht am agiLE Barcamp teil. Warum? Weil es in der Woche stattfand. Und ich habe derzeit einen anderen Arbeits-Fokus. Da, wo ich derzeit tätig bin, fordert man zwar, agil zu sein – aber von den andern. Es ist mehr die Stakeholder-Seite. Wie die Ergebnisse entstehen ist egal. Stakeholder werden selten gefragt und Feedback verhallt wirkungslos. So werden die Projektleiter zwar als POs bezeichnet, sie sind es jedoch noch nicht einmal im SAFe-Verständnis des Wortes.

Und für alle, die meinen, das langsame Vorgehen in der öffentlichen Verwaltung würden die Menschen dort gut heißen: nein, sie sind nur zu höflich und zurückgenommen, um ihre Unzufriedenheit auszudrücken. Tatsächlich herrscht eine Mischung aus Unverständnis, Unwillen und Unfähigkeit, die dazu führt, dass irgendwann irgendetwas passiert, wenn der Zeitpunkt günstig ist und die Umstände es zulassen.

Warum der RANT? Das war alles mal anders. Zu Beginn der atomaren Zeiten konnten brilliante Menschen wirkmächtige Dinge tun. Damals passte es in die Zeit.

Es herrschte Handlungsdruck. Auf US-amerikanischer Seite hat man die Arbeiten theoretischer Physiker wahrgenommen, die in den 1920er und 1930er aus Deutschland heraus veröffentlicht haben. Damals glaubte die US-Regierung oder zumindest einzelne Teile, Deutschland könne eine Atombombe bauen, die in der Lage wäre, “ganz London” auszulöschen. So zumindest behauptete es einer von ihnen in den späten 1930er Jahren. “Die Briten” wurden darüber informiert und bemühten sich 1945 in Farm Hall herauszufinden, ob es wirklich so hätte kommen können.

Doch bis 1946 diese, eher rückwärtsgewandte Frage beantwortet werden konnte, stand die Hypothese “Nazi-Deutschland kann eine Atombombe bauen.”

Und so fanden sich die Urväter (und Mütter!) der IT-Industrie, in der wir heute arbeiten, mit 150.000 anderen direkt oder mittelbar Beteiligten in Los Alamos wieder, um etwas in die Tat umzusetzen, das Alan Turing eine “Kettenreaktion von Pulversäcken” nannte, um nicht gegen die strenge Geheimhaltung des Manhattan-Projekts zu verstoßen. Quelle: Turings Kathedrale. In diesem Buch findet der geneigte Leser auch die Geschichte, wie die Montecarlo-Simulation entstand. Die später in White Sands gezündete Atom-Bombe war die erste ihrer Art. Es gab noch nichts, was derart tiefgehend untersucht war, dass man sie hätte “berechnen” können. Design und vor allem Dimensionierung mussten geschätzt werden. Kommt Dir bekannt vor?

Es ging also im Kern darum, wie mehrere Faktoren, die sich innerhalb eines Wertebereichs mit einer gewissen Wahrscheinlichkeit verteilen, miteinander in Wirkung geraten und welche Ergebnisse das erzielen wird. Einer der Grundgedanken soll dabei von den Roulette-Tischen aus Montecarlo (sic!) stammen: “es sei gegeben rot, schwarz und Zero …” Die zu erwartenden Ergebnisse werden nicht anders sein als rot, schwarz und ‘0’. Nur welche Zahl als nächste fallen wird, das vermag niemand zu sagen. Wenn jetzt aber oft genug gespielt werden würde, dann müsste doch ein Muster erkenntbar werden – so die Überlegung. Und in der Tat, das Muster zeigt: der Veranstalter des Spiels gewinnt auf lange Sicht immer.

Was hat das mit mir zu tun?

Einige Dekaden, Wettermodelle und Großrechnergenerationen später kam dann jemandem der Einfall, das MCMC-Verfahren anstatt mit Wetter- oder Versicherungsdaten mit Parametern zu verwenden, die für ein Organisationssystem wichtig sind, das Software erzeugt. Der Grundgedanke war zu seinen Ursprüngen zurückgekehrt. Wie ist es möglich, mit exakten und immer gleichen Verfahrensschritten (aka Algorithmen) Ergebnisse vorherzubestimmen, die in ihrem Auftreten zwar einerseits ungewiss sind, sich aber innerhalb eines bestimmbaren Möglichkeitsbereichs verteilen? Oder anders ausgedrückt: wie gehen wir mit Unschärfe um? Was tun wir, wenn die Katze lebendig ist und was wenn sie tot ist und wie häufig kommt das vor?

Den Algorithmus bildete dann jemand in Excel ab.

Und die späteren Erfinder der Simulations-Simulation “Montecarlo Madness” (Paula und Marc) lernten, dass diese Form der Entwicklungsbegleitung einerseits erstaunlich präzise Vorhersagen ermöglicht und andererseits ein mächtiges Werkzeug ist, um mit Stakeholdern die möglichen Folgen ihrer Anforderungen zu besprechen:

“Kanste machen. Wird dann halt s…päter.”

Montecarlo “Burnup”-Chart

Von hier bis zur Entwicklung des Spiels war es dann nur noch ein kleiner Schritt. Alex Drestl erzählte mir die Geschichte so:

Auf dem agiLE-Barcamp #7 entstand der Gedanke, aus der Montecarlo-Simulation ein Spiel zu machen. Die späteren Entwickler (Paula, Alex, Marc) boten daher zunächst eine Session an, um Inspirationen zu sammeln und Resonanz zu erfahren. Bestärkt von diesen ersten 45 Minuten bastelten sie noch vor Ort einen wirklich schnellen Prototypen und boten am Folgetag eine Session an, in der das Spiel zum allerersten Mal erlebt werden konnte. “Über den Sommer” entstand dann das Spielmaterial, das wir in den zwei Gruppen an diesem Abend erlebt haben.

Wie geht’s?

Auf einem Tisch werden (laminierte) Karten ausgelegt. Sie bilden eine Art Board auf dem für die vorgegebenen 5 Iterationen die jeweiligen Zustände abgebildet werden. Zu Beginn zieht [jemand] aus der Gruppe fünf Ereigniskarten, die zunächst verdeckt bleiben. Die Aufgabenstellung wird verlesen. Die “Entwickler” lernen die Aufgabe kennen: es gibt ein Baisprodukt und eine Erweiterung für die der fiktive Kunde bereit ist, eine festgelegte Summe Geld (Roulette-Chips) zu zahlen. Die Mitarbeitenden werden durch Würfel repräsentiert. Jeder Würfel kostet 5(000) Geldeinheiten. Das Team kann sich entscheiden, ob es weitere Entwickler (Würfel) “kauft” oder welche abgibt, um damit “Kosten” zu sparen. Der Liefertermin (Iteration 5) verändert sich dadurch nicht.

Die Nachricht ist deutlich: wer früher fertig ist, verdient mehr.

Wer zu spät abliefert, zahlt sowohl die Kosten für das Team als auch eine Vertragsstrafe von 30(000) Geldeinheiten. Das Team verliert damit wesentliche Anteile am Gewinn oder geht sogar bankrott.

Die Würfel folgen einer Ungleichverteilung wie sie in nahezu jedem Team zu finden ist. Zwei Seiten tragen eine “1”, zwei eine “2”, eine “3” und ein “X” (0). Am Ende jedes Durchgangs wird gewürfelt und die Augenzahl addiert. Diese Zahl reduziert die kumulierten Wertpunkte der BLI (Backlog-Items) entsprechend. [Jemand] protokolliert die verbleibende Zahl der BLI-Punkte und so entsteht ein Burndown-Chart … oder eher eine Werte-Matrix.

So weit, so bekannt und wenig spannend. Im Verlauf einer Iteration kann das Team Entscheidungen treffen, die auf das Entwicklungssystem Einfluss nehmen. Mehr Würfel? Weniger? oder keine Veränderung? Diese Entscheidung greift zurück auf historische Daten, die in der begleitenden Excel-Liste abgebildet werden und eine Voraussage darüber treffen, in welcher Iteration der vollständige Umfang des Backlogs geliefert werden wird. Je weiter das Team fortschreitet, desto präziser wird die Vorhersage.

Das Team trifft also erst seine Entscheidung und dann auf die Realität: die nächste Ereigniskarte wird umgedreht.

• Firmenfeier: der Fokus sinkt
• Eine zusätzliche Dokumentation wird erforderlich: BLI+2
• Entwickler wird krank: ein Würfel weniger (bei vollen Kosten!)
• …

Die Spielmacher hatten einige dieser “Realworld-Events” vorbereitet und jeder lachte ein “kenn ich!”, wenn wieder eine neue Karte aufgedeckt wurde.

Jede Iteration war timeboxed auf 5 Minuten. Die Gruppe, in der ich spielte, fand im Raum des Gastgebers EWERK IT eine Sanduhr, die tatsächlich innerhalb dieser 5 Minuten ablief.

Was geht ab?

Es spielten zwei Gruppen in zwei Zeitfenstern und damit mindestens 2 Durchläufe. Die andere Gruppe soll sogar 3 geschafft haben.

Ziemlich schnell zeigte sich, dass das “Chinesen-Prinzip” geradewegs in den Bankrott führt. Beide Male bei denen sich die Gruppe für ein frühes “Upscaling” der Mannschaft entschied, war zum Ende des Geldes noch Arbeit übrig – erstaunlich. Die eine Gruppe kam nur deshalb knapp “zu 0” raus, weil per Ereigniskarte der Abgabetermin hinausgezögert wurde. Große Teile der Mannschaft mussten entlassen werden und zum Schluss half dann noch das Würfelglück. Auch so etwas kommt “in der Praxis” vor.

Überhaupt war dieser Durchgang unglücklich. Vielleicht lag’s am Essen oder an der Uhrzeit. Vielleicht lehnten sich die meisten Mitspieler zurück, weil sie das Spiel ja jetzt kennen …?

Irgendwo zwischen 3. und 4. Iteration muss es passiert sein … die Berechnung der verbleibenden BLI-Punkte und des verfügbaren Budgets wurde gestört und mit großer Sicherheit ein falscher BEtrag eingetragen. Hans versuchte mehrfach darauf hinzuweisen und wurde nicht gehört. Anne fühlte sich auch hier an “die Realität” erinnert. “Die leisen werden nicht gehört – auch wenn sie Recht haben.”

Fun facts

Alex Drestl erzählte mir von den Vorbereitungen und ich verfing bei den ungleichen Würfeln. Er sagte, sie seien so schlecht (unregelmässig) gefertigt, dass mit ihnen keine zufällige Normalverteilung zu erreichen sei. Ich dachte: “super, wie im richtigen Leben”. Und als ich die Würfel sah, musste ich lachen. Manche Seiten waren fast oval, Kanten unterschieden sich um mehrere Millimeter …
Tatsächlich beabsichtigt war von den Erschaffern wahrscheinlich eher:

• 1 = 2/6
• 2 =2/6
• 3 = 1/6
• 0 = 1/6

Jetzt hätte man faul sein können und die Zufallsverteilung Excel überlassen können. Das war Paula wohl zu synthetisch und so setzte sie sich einen Abend lang hin und würfelte nach Alex’ Aussage 300 mal.

Verbesserungen?

Noch während des Spiels schlug Hans vor, man solle einen “Projektleiter” einkaufen. Der sei zwar teurer als ein Entwickler (Würfel) und trage auch nicht zur Reduzierung der Arbeit bei (kein Würfel), er könne aber in die Ereigniskarten sehen und entscheiden, in welcher Reihenfolge die ausgespielt werden.

Im Anschluss an die Spielrunden aggregierten die Teilnehmer ihr Feedback mit der 1-2-4- alle-Methode.

Insgesamt wurde das Spiel gut aufgenommen. Meine Gruppe wünschte sich mehr Bezug zu den Parametern des Algorithmus. Der Punkt erscheint mir besonders wichtig. Obwohl ich insgesamt 12 Ereigniskarten erlebt hatte, kann ich mich tatsächlich nur an die drei Erinnern, die einen direkten Einfluss auf die Parametrisierung hatten (s.o. Firmenfeier etc.).

Die Antwort: 42?

Das Buch, das die Zahl 42 berühmt gemacht hat, präsentiert sie als das Ergebnis auf eine Frage, die über die Zeit vergessen wurde. Es behauptet: die Rechenmaschine Erde sei geschaffen worden, um den Algorithmus zu verarbeiten und hätte dafür so lang gebraucht, dass es niemanden mehr gäbe, der sich noch an die Frage erinnern könne.

In den Umgebungen, in denen ich bisher tätig war, hat die Frage zur Antwort “Montecarlo Madness” bislang niemand gestellt:

“Wie wirkt sich das aus?”

Als ich seinerzeit in der Rolle des Product Owners tätig war, hätte ich dieses Werkzeug gern an der Hand gehabt. Es hätte so einiges vereinfacht und wahrscheinlich Etliches ermöglicht. Doch so kam es anders. Die Teams machten Versprechungen (“Overcommitment”), die sie immer wieder nicht eingelöst haben. Diejenigen, denen Verlässlichkeit wichtig war und die zu ihren Zusagen stehen wollten, brannten aus, verließen die Umgebungen oder beides – in dieser Reihenfolge.

Jetzt muss das nicht mehr so kommen. Mit der Montecarlo-Simulation erhält die jeweilige Organisation ein Werkzeug an die Hand, das in der Lage ist eine Orientierung zu geben, die zwar keine exakte Vorhersage ist, aber auch kein Bullshit.

“Zwischen wahr und falsch liegt Bullshit.
Und Bullshitter verfolgen ihre eigene Agenda.”

Norbert Voßiek, früher mal theoretischer Physiker

Und jetzt kommst Du!

Egal in welcher Rolle Du tätig bist, egal ob Deine Organsation “agil” entwickelt oder es nur so nennt, mit der Montecarlo-Simulation ersetzt Ihr die Glaskugel und markige Ansagen durch ein Werkzeug, das im Kontext Eurer realen Umgebung eine Verlässlichkeit erzeugen kann, wie nichts anderes.

Eine äußerst wirksame Vorstufe zur Einführung der Methode bildet nach meiner Einschätzung das spielerische Kennenlernen über die Simulation der Simulation: Montecarlo Madness.

Viel Spaß und macht was draus!