Ich liebe Simulationen und kleine Spiele, um komplexe Zusammenhänge greifbar zu machen. Dinge, die man theoretisch erklären kann, werden durch eine gute Simulation oft innerhalb weniger Minuten intuitiv verständlich.
Das folgende Spiel nutze ich regelmäßig in Trainings und auf Konferenzen. Es macht einen zentralen Unterschied in der agilen Produktentwicklung sichtbar: Teams bewegen sich ständig zwischen zwei sehr unterschiedlichen Arbeitsmodi – Explore und Exploit.
Im Explore-Modus gibt es viele Unklarheiten. Das Team versucht zu verstehen, wie ein Problem eigentlich funktioniert. Hypothesen werden aufgestellt, Experimente durchgeführt und aus den Ergebnissen werden neue Erkenntnisse gewonnen.
Im Exploit-Modus ist das Ziel ein anderes: Hier geht es darum, möglichst effizient zu liefern. Erkenntnisse aus der Explore-Phase werden genutzt, um schnell und zuverlässig Wert zu erzeugen.
Beide Modi sind wichtig. Erfolgreiche Teams beherrschen beide – und wechseln bewusst zwischen ihnen. Problematisch wird es, wenn innerhalb eines Teams unterschiedliche Vorstellungen darüber existieren, in welchem Modus gerade gearbeitet wird. Dann entstehen schnell Konflikte: Die einen wollen experimentieren, während die anderen möglichst effizient liefern wollen.
Genau diese Dynamik macht das folgende Spiel sichtbar.
Das Explore-vs-Exploit-Game
Teilnehmer
Das Spiel funktioniert gut mit 1 bis 8 Spielern pro Team. Bei größeren Gruppen bietet es sich an, mehrere Teams parallel spielen zu lassen. Gerade bei mehreren Teams entstehen interessante Dynamiken, weil die Teams anfangen, sich gegenseitig zu beobachten und ihre aktuelle Vorgehensweise hinterfragen, wenn sie im Rückstand sind.
Jedes Team benötigt zusätzlich eine Person in der Rolle des Regelwächters. Diese Person kennt die geheimen Regeln des Spiels und führt nach jedem Zug bestimmte Aktionen aus.
Teilnehmer können auch als Beobachter teilnehmen.
Die Rolle des Regelwächters kann entweder vom Spielleiter übernommen werden oder von Teilnehmern. Wenn Teilnehmer diese Rolle übernehmen, sollten sie die geheimen Regeln ausgedruckt erhalten.
Benötigte Materialien
- Spielkegel in verschiedenen Farben (mindestens sechs Farben)
- Vier farbige Felder, die jeweils einer der Kegelfarben entsprechen
- Ein Bereich für „Value Delivered“
- Ein Beutel oder ähnliches, um Kegel blind zu ziehen
Vorbereitung
Die vier farbigen Felder werden im Quadrat ausgelegt.
Daneben wird ein Bereich „Value Delivered“ markiert.
Auf jedes der vier Felder wird anschließend
ein Kegel gestellt. Wichtig:
Die Farbe des Kegels darf nicht der Farbe des Feldes entsprechen.
Ziel des Spiels
Das Ziel für die Spieler ist einfach: Möglichst viel Wert liefern.
Konkret bedeutet das: möglichst viele Kegel in den Bereich „Value Delivered“ zu verschieben. Kegel, die einmal dort liegen, sind in Sicherheit und werden von den Regeln nicht mehr beeinflusst.
Spielablauf
Der Regelwächter erklärt zunächst die grundlegenden Spielregeln.
Das Spiel läuft in Runden ab.
- Zu Beginn jeder Runde entscheidet das Team gemeinsam, welche Kegel „delivered“ werden. Dabei gilt, dass immer mindestens ein Kegel auf einem der farbigen Felder verbleiben muss.
- Dann entscheidet das Team, welcher Kegel auf ein anderes farbiges Feld verschoben wird.
- Pro Runde muss genau ein Kegel bewegt werden – nicht mehr und nicht weniger.
- Nachdem der Kegel verschoben wurde, führt der Regelwächter seine Aktionen aus.
- Danach startet direkt die nächste Runde mit dem „Delivery“.
Strategie-Hinweis für die Spieler
Der Regelwächter folgt strikten Regeln, um Kegel hinzuzufügen oder zu entfernen. Je besser das Team diese Regeln versteht, desto besser kann es den Value Delivered maximieren.
Die geheimen Regeln des Spiels
Die folgenden Regeln kennt nur der Regelwächter. Nach jedem Zug werden sie angewendet – so lange, bis keine Regel mehr greift. Erst danach sind wieder die Spieler am Zug. Die Regelwächter ziehen dabei neue Kegel immer blind, so dass die Farbe der Kegel zufällig ist.
Hinzufügen-Regeln
1. Wiederholte Bewegung
Wenn ein Kegel zweimal hintereinander bewegt wurde, wird auf dem Feld, auf dem der Kegel jetzt steht, ein neuer Kegel hinzugefügt.
2. Leeres Spielfeld
Wenn auf keinem der farbigen Felder mehr ein Kegel steht, wird auf jedes Feld ein neuer Kegel gelegt.
3. Gleichfarbige Kegel
Wenn ein Kegel auf ein Feld verschoben wird, auf dem bereits ein oder mehrere Kegel mit derselben Farbe stehen, werden zusätzliche Kegel erzeugt. Die Anzahl entspricht der Anzahl der Kegel dieser Farbe auf dem Feld. Diese Regel gilt sowohl wenn Spieler einen Kegel verschieben als auch wenn durch eine andere Regel neue Kegel hinzugefügt werden
Beispiel: Wenn ein gelber Kegel auf ein Feld verschoben wird, auf dem bereits ein gelber Kegel steht, dann werden zwei neue Kegel hinzugefügt. Ist einer der neuen Kegel auch gelb, so werden nochmals drei neue Kegel hinzugefügt. Hierbei ist zu beachten, dass wenn dadurch mehr als 8 Kegel auf dem Feld stehen, die entsprechende Entfernen-Regel zur Anwendung kommt.
Entfernen-Regeln
1. Kegel auf gleichfarbigem Feld
Wenn ein Kegel auf einem Feld landet, das dieselbe Farbe wie der Kegel hat, wird dieser Kegel entfernt. Diese Regel gilt ebenfalls sowohl für Spielerzüge als auch für automatisch erzeugte Kegel.
2. Dreimal bewegt
Wenn ein Kegel dreimal unmittelbar hintereinander bewegt wurde , wird dieser Kegel entfernt. Wird dazwischen ein anderer Kegel bewegt, beginnt die Zählung von vorne.
3. Überfülltes Feld
Wenn auf einem Feld mehr als acht Kegel liegen, werden alle Kegel auf diesem Feld entfernt.
Spielende
Das Spiel kann beispielsweise 20 Minuten gespielt werden.
Erfahrene Spielleiter beobachten oft einfach die Dynamik im Raum und beenden das Spiel, sobald genügend interessante Situationen entstanden sind, um darüber zu reflektieren.
Typische Beobachtungen aus dem Spiel
Nachdem das Spiel einige Zeit läuft, lassen sich fast immer bestimmte Muster beobachten. Genau diese Beobachtungen bilden später die Grundlage für das Debriefing.
In der Planung feststecken
Eine Situation, die ich regelmäßig sehe, sind zeitraubende Diskussionen ohne eine wirkliche Entsscheidungsgrundlage.
Einige Teams beginnen damit, lange über mögliche Strategien zu diskutieren. Sie versuchen zunächst, das System theoretisch zu verstehen und diskutieren darüber, wie die Regeln vielleicht sein könnten.
Das Problem dabei: Zu diesem Zeitpunkt verfügen sie praktisch über keine Informationen.
In einem Training diskutierte ein Team fast zehn Minuten lang mögliche Strategien, ohne einen einzigen Zug auszuführen. Erst als jemand zum Nachbartisch schaute und bemerkte, dass das andere Team bereits eine ganze Reihe von Kegeln geliefert hatte, änderte sich die Stimmung im Raum schlagartig.
Der Lerneffekt ist meist schnell sichtbar: Während das eine Team noch über mögliche Strategien diskutierte, hatte das andere Team bereits Erfahrungen gesammelt.
Übertragung auf den Entwicklungsalltag
Genau dieses Muster sieht man auch in vielen Softwareprojekten. Teams versuchen durch lange Diskussionen mehr Klarheit zu schaffen – obwohl ihnen eigentlich noch die notwendigen Informationen fehlen.
In komplexen Situationen entsteht Wissen jedoch selten durch Diskussionen, sondern durch Experimente und Feedback. Statt lange über die „richtige“ Lösung zu spekulieren, ist es oft sinnvoller, schnell etwas auszuprobieren und daraus zu lernen.
Im Explore-Modus feststecken
Ein anderes Muster zeigt sich bei Teams, die sehr stark auf Exploration setzen. Sie führen viele Experimente durch und versuchen möglichst viele Regeln zu verstehen. Dabei entstehen immer neue Hypothesen, die getestet werden sollen.
Das kann sehr spannend sein – führt aber manchmal dazu, dass das eigentliche Ziel aus dem Blick gerät. Das Ziel des Spiels ist schließlich nicht, das System vollständig zu verstehen, sondern Wert zu liefern.
Übertragung auf den Entwicklungsalltag
Auch in der Produktentwicklung kann Exploration zum Selbstzweck werden. Teams analysieren, experimentieren und optimieren – ohne jemals in eine Phase zu kommen, in der sie ihre Erkenntnisse konsequent nutzen. Es wird nach noch besseren technischen Lösungen gesucht oder nochmal eine andere Variante der Bedienung probiert, obwohl das bisher erreichte eigentlich schon „good enough“ ist.
Exploration ist wichtig, um Unsicherheit zu reduzieren. Aber irgendwann kommt der Punkt, an dem es sinnvoll ist, vorhandenes Wissen systematisch zu nutzen und Wert zu liefern.
Im Exploit-Modus feststecken
Das Gegenteil passiert bei anderen Teams. Sie entdecken relativ früh eine funktionierende Strategie und konzentrieren sich anschließend ausschließlich darauf, möglichst effizient zu liefern.
Das funktioniert zunächst gut – verhindert aber oft weitere Erkenntnisse. Vielleicht existiert eine deutlich bessere Strategie, die nie entdeckt wird, weil das Team aufgehört hat zu experimentieren.
Übertragung auf den Entwicklungsalltag
Auch Entwicklungsteams geraten leicht in diesen Zustand. Sobald ein Vorgehen funktioniert, wird es zur Routine. Prozesse, Architekturentscheidungen oder Arbeitsweisen werden kaum noch hinterfragt.
Das Problem: Die Rahmenbedingungen verändern sich ständig. Technologien entwickeln sich weiter, Nutzerbedürfnisse ändern sich und neue Möglichkeiten entstehen. Teams, die ausschließlich im Exploit-Modus arbeiten, laufen Gefahr, dass Rahmenbedingungen sich schleichend verändern und so das Team die Notwendigkeit für eine Anpassung erst viel zu spät erkennt.
Im Spiel bleiben die Regeln konstant. In der Realität ist das selten der Fall. Deshalb ist es wichtig, auch in stabil wirkenden Situationen immer wieder bewusst Raum für Exploration zu schaffen.
„Gibt es vielleicht noch einen besseren Weg?“
Eine besonders spannende Situation beobachte ich regelmäßig bei Teams, die bereits effizient liefern. Das Team arbeitet im Exploit-Modus und produziert zuverlässig „Value Delivered“. Dann stellt plötzlich jemand eine Frage:
„Könnte es vielleicht noch einen besseren Weg geben?“
Interessanterweise kommt diese Frage häufig von einer Person, die gerade nicht direkt im Delivery-Flow eingebunden ist. Diese Person hatte Zeit, das System zu beobachten und über Alternativen nachzudenken.
Übertragung auf den Entwicklungsalltag
In vielen Teams ist genau das die Rolle eines Scrum Masters oder Agile Coaches . Während ein Teil des Teams stark auf Delivery fokussiert ist, können andere Personen bewusst einen Schritt zurücktreten und das Gesamtsystem betrachten.
Diese Perspektive ist wichtig, um immer wieder neue Möglichkeiten zu entdecken und nicht dauerhaft in bestehenden Mustern zu verharren.
Hypothesen und Experimente
Nur wenige Teams arbeiten wirklich strukturiert mit Experimenten.
Der ideale Ablauf wäre eigentlich:
- Eine Hypothese formulieren
- Ein Experiment definieren
- Das Experiment durchführen
- Ergebnisse auswerten
- Daraus neue Hypothesen und Experimente ableiten
In der Praxis passiert vieles eher intuitiv. Experimente werden durchgeführt, ohne dass klar ist, was genau getestet werden soll.
Nach einigen Runden taucht dann häufig die Frage auf:
„Was ist eigentlich passiert, als wir das vorhin schon einmal ausprobiert haben?“
Übertragung auf den Entwicklungsalltag
Genau hier liegt eine große Chance für viele Teams. Strukturierte Experimente können helfen, schneller zu lernen und bessere Entscheidungen zu treffen. Schon einfache Dinge wie das explizite Formulieren einer Hypothese oder das kurze Dokumentieren von Ergebnissen können den Lernprozess erheblich verbessern.
Teamdynamik
Das Spiel macht auch unterschiedliche Teamdynamiken sehr gut sichtbar.
Manche Teams werden stark von einzelnen Personen dominiert. Andere diskutieren so lange, dass kaum noch Zeit zum Spielen bleibt. Manchmal gehen gute Ideen unter, weil die Gruppe sie nicht aufnimmt. Andere Teams nutzen bewusst die unterschiedlichen Perspektiven der Mitglieder, bündeln ihre Stärken und profitieren von der Vielfalt.
Übertragung auf den Entwicklungsalltag
Im Teamalltag passiert das genauso. Einzelne dominieren Diskussionen, andere trauen sich nicht, Vorschläge einzubringen. Teams, die aktiv ihre Diversität nutzen, treffen bessere Entscheidungen und finden kreative Lösungen. Awareness für Teamdynamik ist also entscheidend.
Standards vs. Kreativität
Eine weitere interessante Beobachtung zeigt sich beim Wechsel der Modi. Im Exploit-Modus helfen klare Standards und bewährte Patterns. Sie ermöglichen effizientes Arbeiten, schnelle Lieferung und Stabilität.
Im Explore-Modus sind Standards dagegen oft hinderlich. Hier braucht es Kreativität, Innovationskraft und den Mut, neue Wege auszuprobieren. Regeln, die im Exploit-Modus Sicherheit geben, können Exploration ausbremsen.
Übertragung auf den Entwicklungsalltag
Für Entwickler bedeutet das: Standardlösungen und etablierte Patterns liefern Effizienz, aber Innovationsprojekte brauchen Freiraum und kreative Ansätze. Teams müssen bewusst unterscheiden, wann Standardisierung hilft und wann sie hemmt.
Kollaboration
Auch die Bedeutung von Zusammenarbeit verändert sich zwischen den beiden Modi.
- In der Explore-Phase profitiert das Team von gemeinsamer Diskussion, dem Austausch verschiedener Perspektiven und aktiver Kollaboration.
- Im Exploit-Modus hingegen bringt zusätzliche Kollaboration oft keinen Mehrwert. Wenn ein Prozess einmal etabliert ist, kann ein Einzelner die Umsetzung genauso effizient erledigen.
Übertrag in den Entwickleralltag:
Das erklärt, warum Pair- und Mob-Programming in manchen Situationen dem Team einen echten Boost geben können – und warum sich dieselbe Praxis in anderen Momenten eher wie Zeitverschwendung anfühlt. Die bewusste Unterscheidung zwischen Explore- und Exploit-Modus kann hier mehr Klarheit schaffen. Noch entscheidender ist jedoch, dass Teams die Fähigkeit entwickeln, enge Kollaboration gezielt einzusetzen : Im Explore-Modus ermöglicht sie eine effiziente Kommunikation, nutzt die Meinungsvielfalt und Diversität der Teammitglieder optimal und verwandelt potenzielle Reibungen in kreative Energie statt in Konflikte.
Fazit für den Entwickleralltag
Am Ende des Spiels reflektiert man gemeinsam, welche Erkenntnisse sich ableiten lassen:
- Explore und Exploit sind zwei sehr unterschiedliche Arbeitsmodi, die auch unterschiedliche Rahmenbedingungen brauchen.
- Gute Teams wechseln bewusst zwischen diesen Modi. Der Wechsel sollte explizit sein.
- Allen Beteiligten muss klar sein, in welchem Modus gerade gearbeitet wird. Andernfalls entstehen Konflikte im Team und mit Stakeholdern.
- Explore nutzen wir, um mit Komplexität umzugehen. Nicht alles im Projekt ist komplex – deshalb gibt es verschiedene Phasen, in denen der passende Modus angewendet werden muss.
- Exploitation sorgt für effiziente Wertschöpfung. Ohne Explore würden Teams kaum neue, bessere Wege finden.
Der Schlüssel liegt im bewussten Wechsel der Modi. Frühes Tun und Experimentieren erzeugt Wissen, das effizient genutzt werden kann. Awareness für Teamdynamik, Standards, Kreativität und Kollaboration macht den Unterschied zwischen einem funktionierenden Team und einem wirklich erfolgreichen Team aus.
Explore hilft uns, mit Komplexität
umzugehen.
Exploit hilft uns, Wert effizient zu liefern.
Gute Produktentwicklung braucht beides – und die Fähigkeit, bewusst zwischen diesen beiden Welten zu wechseln.