20.10.2020
Lesezeit: ca. 8 Minuten

Warum mich das Ball Point Game noch nie im Stich gelassen hat

Gerade jetzt in Zeiten von Corona über das Ball Point Game zu schreiben erscheint wahrscheinlich nicht so sinnvoll. Ich tue es trotzdem… wenn du wissen willst warum, dann musst du wohl den Artikel bis zum Ende lesen (oder einfach runter scrollen) ;)

Die meisten, die schon einmal eine Schulung oder einen Workshop zum Thema Agilität besucht haben, kennen das Ball Point Game. Es ist eine Gruppenübung, die den TeilnehmerInnen die Grundlagen des agilen Arbeitens spielerisch vermitteln soll. Der Fokus liegt dabei auf den Konzepten des iterativen Arbeitens, der kontinuierlichen Verbesserung und der Selbstorganisation. Durch ihren lockeren Charakter rund um das Spielen mit Bällen ist die Übung auch ein toller Einstieg für Schulungen, um die Teamdynamik der TeilnehmerInnen zu stärken.

Im Laufe der letzten Jahre habe ich das Ball Point Game grob geschätzt ca. 30 Mal gespielt oder moderiert. Eines kann ich daher ganz klar sagen: Das Ball Point Game hat mich nie im Stich gelassen!

Egal wie die Gruppen zusammengewürfelt waren, egal welche Regelvariante genau angewandt wurde und egal ob man als Moderator Tricks verwendet - am Ende gab es immer genügend Dinge, die man diskutieren und aus denen man lernen konnte. Wichtig ist natürlich als Moderator sehr genau zu beobachten, um diese dann in der Nachbesprechung auch entsprechend nutzen zu können. Die typischen aber auch ein paar spezielle solcher Erfahrungen möchte ich hier teilen.

Regeln und Ablauf

Aber zuerst einmal eine kurze Zusammenfassung des Ablaufs. (Wenn du das Spiel schon gut kennst kannst du den Part gerne überspringen)

Wie schon erwähnt, gibt es ein paar Varianten das Spiel zu spielen, das Grundprinzip ist aber bei allen gleich.

Gemeinsam als Team gilt es einen Prozess zu erfinden, um eine möglichst hohe Anzahl an Punkten zu erzielen.

Dabei gelten folgende Regeln:

  • Einen Punkt erhält man, wenn ein Ball von jedem/r Teilnehmer/in berührt wurde.
  • Ein Ball darf nicht von 2 Personen gleichzeitig berührt werden, er muss bei der Übergabe also sogenannte Air Time haben.
  • Man darf den Ball nicht an seinen direkten Schulternachbarn weitergeben.
  • Wenn ein Ball den Boden berührt ist er für diese Runde aus dem Spiel, kann aber in der nächsten Runde wieder verwendet werden.

Die Übung verläuft in drei Phasen die vier bis fünf mal wiederholt werden: 1. Prozess erarbeiten / verbessern (initial meistens 2 Minuten, dann 1 Minute) 2. Durchführung (meistens 2 Minuten) 3. Reflektieren, was gut war und was noch verbessert werden kann (1 Minute)

Während dem Spiel sollte sich der Moderator zurückhalten und lediglich die Phasen ankündigen, auf die Einhaltung der Zeiten achten und die Ergebnisse dokumentieren.

Nachdem vier bis fünf Runden gespielt wurden stellt der Moderator abschließende Fragen um eine Diskussion anzuregen und verknüpft das Erlebte mit der Theorie rund um Agilität.

SPOILER ALERT!!

Achtung: Wenn du das Spiel noch nicht gespielt hast solltest du nicht weiterlesen! Einerseits weil ich einige typische Verläufe beschreibe und Tipps dazu gebe, andererseits weil du viele der Verläufe wahrscheinlich nur nachvollziehen kannst wenn du das Spiel schon gespielt hast.

Ein paar typische Verläufe und wie man sie nutzen kann:

Überoptimierung des ersten Prozesses

Ein sehr typischer Verlauf ist, dass die TeilnehmerInnen schnell einen einigermaßen guten Prozess finden und diesen über die ersten zwei bis drei Runden auch gut verbessern, dann aber stagnieren. Zum Beispiel bilden sie 2 Reihen und werfen die Bälle in einem Zick-Zack Muster. In dem Fall entsteht selten ein kontinuierlicher Flow, weil die Bälle wieder an den Start gebracht werden müssen. Spätestens vor der vierten Runde würde ich hier dazu anregen, den Prozess grundlegend zu überdenken. Oft hilft der Hinweis, dass ‚richtig gute Teams die doppelte Punktezahl erreicht haben weil sie einen ganz anderen Prozess hatten‘. In der Nachbesprechung würde ich auf jeden Fall auf die ausufernde Optimierung eingehen und den Realitätsbezug zu Systemen herstellen in denen krampfhaft an einem Prozess festgehalten wird ohne diesen grundlegend zu hinterfragen.

Erhöhung der Last

Wenn ein Prozess gut funktioniert, wird als Maßnahme oft die Last erhöht. Bspw. werden mehr Bälle ins System gebracht oder die Wurf-Taktung wird erhöht. Die Folge ist sehr oft, dass mehr Fehler passieren und Bälle runterfallen. In diesem Fall ist es sehr hilfreich die heruntergefallenen Bälle als Bugs zu werten und zusätzlich zum Ergebnis zu notieren. In der Nachbesprechung kann man darauf eingehen, dass die Erhöhung der Last selten zu einer signifikanten Steigerung des Outputs führt, aber fast immer zu mehr Fehlern.

Radikale Änderung des Prozesses

Oft ändern Teams ihren Prozess grundlegend wenn sie keine wirksamen Optimierungen mehr finden. Der Effekt ist meistens, dass die Punkte Anzahl zuerst sinkt, weil der neue Prozess nicht gleich funktioniert, dann aber stark ansteigt. Das am öftesten gesehene Beispiel ist der Wechsel von den zwei Reihen auf einen Kreis bzw. der Wechsel von einem Kreis auf einen Doppelkreis. Auf dieses Phänomen sollte man in der Nachbesprechung umbedingt eingehen. Es zeigt sehr schön, dass Maßnahmen nicht immer gleich den gewünschten Effekt bringen und man sich erst einspielen muss. Gerade wenn man die Übung mit Führungskräften macht sollte man hier klar machen, dass eine Veränderung Zeit braucht um sich einzuspielen und man nicht gleich wieder zurückrudern darf.

Dominante TeilnehmerInnen

Das Ball Point Game setzt darauf, dass die TeilnehmerInnen gemeinsam eine Lösung finden und dabei auf Augenhöhe zusammenarbeiten. Falls ein/e Teilnehmer/in zu dominant agiert und versucht den Prozess vorzugeben stellt sich immer die Frage, ob man als Moderator eingreifen sollte oder nicht. Ich greife grundsätzlich erst ab der dritten Runde ins Geschehen ein, weil auch aus einem ‚negativen‘ Verlauf immer gute Erkenntnisse abgeleitet werden können. So ist es oft passiert, dass zurückhaltende Teilnehmer sehr gute Ideen vorbringen und erstmal ignoriert werden. Später stellen sich die Vorschläge dann als nützlich heraus. In der Diskussion sollte man auf solche Beobachtungen hinweisen wenn sie nicht von TeilnehmerInnen kommen und unterstreichen, dass Diversität und eine respektvolle, offene Zusammenarbeit kreative Lösungen fördert und daher auch immer die besseren Ergebnisse liefern wird.

Dominante TeilnehmerInnen II

Besonders spannend kann es werden, wenn die TeilnehmerInnen in einem direkten hierarchisch Verhältnis zueinander stehen. Dann ist Fingerspitzengefühl bei der Moderation gefordert. In einer derartigen Situation (in der dies auch für den Moderator galt) hatten wir das Glück, in mehreren Gruppen zu spielen. Wir konnten am Ende die Ergebnisse vergleichen… ratet mal, welche Gruppe die wenigsten Punkte hatte? :D In jedem Fall bietet sich in der Nachbesprechung an die Frage zu stellen, ob mehr Punkte erzielt worden wären, wenn ein einzelner den Prozess vorgegeben hätte und auch hier wieder auf Entscheidungen im Arbeitsalltag über zu leiten. (Diese Frage stelle ich aber auch wenn kein/e dominante/r Teilnehmer/in anwesend war…)

TeilnehmerInnen, die das Spiel schon gespielt haben

Oft kommt es auch vor, dass TeilnehmerInnen die Übung schon einmal gemacht haben und quasi die guten Lösungen und Erfahrungen spoilern. Ich weise grundsätzlich vor dem Spiel darauf hin, dass solche TeilnehmerInnen sich die ersten paar Runden bitte nicht einbringen sollen. Ein sehr lustiges Phänomen, dass ich in dem Zusammenhang schon mehrfach erlebt habe ist, dass wenn die erfahrenen Teilnehmer dann die vermeintlich besseren Lösungen vorbringen, diese aus diversen Gründen gar nicht funktionieren. Zum Beispiel gibt es die berüchtigte Variante bei der alle ihre Hände direkt übereinander halten und Bälle von oben eingeworfen werden. Diese kann extrem effizient sein, funktioniert aber nur bei kleinen Gruppen, weil man sich sonst schnell im Weg steht. Ich freu mich extrem wenn das passiert, weil man dann perfekt darauf eingehen kann, dass eben nicht jeder Prozess für jedes Team funktioniert und das jedes Team seinen eigenen Weg erarbeiten sollte.

Probleme mit der Raumsituation

Besonders wenn man die Übung in Meetingräumen abhält, kann es schnell eng werden. In dem Fall weise ich nach der zweiten Runde darauf hin, dass es keine Regel gibt, die besagt dass man den Raum nicht verändern oder sogar verlassen darf. In der Nachbesprechung kann man dann darauf eingehen, dass man seine Umgebung nicht einfach so hinnehmen sollte, sondern auch diese verändern kann.

Falls ihr euch jetzt denkt wie das mit Physical Distancing zusammenpasst, man könnte das Spiel auch virtuell spielen. Aber mehr dazu später ;)

Einbinden von Gegenständen

Oft wird bei der Übung das Einbinden von Gegenständen wie Körben, Tischen oder Sesseln untersagt. Persönlich finde ich es in Ordnung, weil es die Kreativität der Lösungen fördert und ich noch keine Situation erlebt habe, in der Gegenstände einen deutlichen Vorteil gebracht hätten. Im Gegenteil, meistens werden Gegenstände als Quick Fix für ein Problem verwendet und verhindern die grundlegende Lösung des Problems. Des Öfteren habe ich erlebt, dass in der 2 Reihen Prozess Variante ein Korb verwendet wurde um die Bälle am schneller wieder an den Start zu bekommen oder diese zu puffern. Dies erleichtert kurzfristig die Situation, verzögert aber die Lösung der Grundvoraussetzung, nämlich die Erschaffung von kontinuierlichem Flow. In der Nachbesprechung kann man darauf eingehen und eventuell auch eine Parallele zur Einführung von Tools ziehen.

Stille

Wenn alle voll konzentriert bei der Sache sind und die Bälle exakt im Takt übergeben werden, tritt oft eine fast schon hypnotisierende Stille ein. Ja nachdem, was man vermitteln will könnte man diese zerstören und vermeintlich besonders wichtige Bälle von außen ins System bringen. :) Ich habe das ehrlich gesagt noch nie gemacht, aber ich frage in der Nachbesprechung gerne was passiert wäre, wenn ich es gemacht hätte. ;) Die Analogie erklärt sich hier hoffentlich von selbst.

Team Konkurrenz

Wenn man mit mehreren Teams parallel spielt wird man sehr schnell feststellen, dass diese miteinander konkurrieren. In den meisten Fällen haben wir die Teams getrennt, damit sie sich nicht gegenseitig beeinflussen. Man kann den Spieß aber auch umdrehen und den Effekt bewusst nutzen, indem man die einzelnen Runden der Teams am Ende summiert um die Gesamtpunkteanzahl pro Runde zu ermitteln. In der Nachbesprechung kann man dann auf lokale Optimierung in einzelnen Teams und den Wert von Austausch zwischen den Teams eingehen. Gerade in skalierten Agilen Umsetzungen bietet sich dieses Vorgehen an.

Fazit

Ich weiß gar nicht wie oft mein Co-Moderator und ich uns während des Ball Point Games angesehen haben, weil wir beide Angst hatten, dass es mit dieser oder jener sehr speziellen Gruppe nicht funktionieren wird. Aber keine Sorge, es hat immer funktioniert! Man muss nur genau beobachten, was in der Gruppe passiert um einerseits gezielt eingreifen zu können und andererseits genug Impulse für die Nachbesprechung zu generieren. Im Idealfall kennt man die Situation der TeilnehmerInnen so weit um beurteilen zu können, welches Erlebnis ihnen am meisten hilft. Das klingt jetzt irgendwie nach cheaten, aber ihr wisst was ich meine ;)

und wie spielt man das in Zeiten von Corona?

Bleibt trotzdem noch die Frage, warum ich den Artikel gerade jetzt schreibe, wo man coronabedingt keine derartigen Gruppenübungen abhalten kann?

Im Grunde trauere ich dem Ball Point Game ein bisschen nach. Es fehlt mir in Workshops und Schulungen und ich habe noch keine remote alternative gefunden die ich als wirklich gleichwertig empfinde.

Daher habe ich begonnen meine eigene remote Variante der Übung als Browsergame zu implementieren, das Remote Ball Point Game.

Kommt das Remote Ball Point Game an das Orginal heran? Weiß nicht so recht, das müssen wir wohl gemeinsam herausfinden ;)

Auf jeden Fall hab ich bei der Umsetzung unglaublich viel über Agile Methoden und über mich selbst gelernt :D Aber dazu mehr in meinem nächsten Blog Post.

https://remoteballpointgame.openforce.com/

Remote Ball Point Game

Thomas Schmid
Scrum Master & Agile Coach

Nach dem Abschluss seines Wirtschaftsinformatik Studiums hat Thomas als Software Entwickler die agile Arbeitsweise kennen und lieben gelernt. Im Laufe der Zeit konnte er Erfahrung in allen Scrum Rollen und mit den gängigsten agilen Frameworks sammeln und konnte diese in Schulungen und Workshops vermitteln. Aktuell beschäftigt er sich leidenschaftlich mit dem Einsatz agiler Methoden auf Organisationsebene und unterstützt unsere Kunden dabei diese einzuführen und kontinuierlich zu verbessern.

Scroll to top