Hier –wie gewünscht – meine kurzer Erfahrungen mit über 50 Ball-Point Games.
Vorab: Ich verwende das Ball-Point Game in Schulungen für neue Teams die ich neu aufbaue. Es ist nämlich nebenbei ein sehr guter Team Building-Event. Für gemischte Schulungen, bei denen auch die Gruppen größer als 6 +/- 2 Personen (plus PO / SM) sind, gibt es m.E. geeignetere Übungen (z.B. Human Knot – TastyCupcakes.org).
1. Die Regel Nr. 5 gehört nicht zur Originalversion des Spiels und schränkt m.E. die Freiheiten des Teams und die Lernpotentiale ein. (Und das Spiel soll – wie Scrum – mit möglichst wenig Regeln auskommen; fördert die Selbstorganisation.)
Ich verwende diese Regel nicht und somit kommt es regelmäßig vor, das Teilnehmer den herunter gefallenen Bällen hinterher laufen, was Zeit kostet (Task Switching) und das gesamte Team aus den Tritt bringt (Störung des Flow), bis sie dann merken, welche Verschwendung das ist und die Bälle einfach liegen lassen.
2. Das die Kreativität und die Selbstorganisation steigt, je weniger Regeln vorgegeben sind, zeigte sich mir bei einem Team, dass meine Balltasche verwenden wollte, um gleich alle 10 bereitgestellten Bälle gleichzeitig durch das Team laufen zu lassen. Hier habe ich dann doch eingegriffen und darauf hingewiesen, dass meine Balltasche nicht zum Spielmaterial gehört…
3. Apropos Anzahl der Bälle: Es gibt Anleitungen die behaupten, dass man für das Spiel mind. 100 Bälle benötigt. Da ist falsch! Ich komme locker mit 10 Bällen aus, selbst wenn ich mal zwei Teams parallel spielen lasse. Wenn ein gefühlter Mangel an Bällen entsteht, benötige ich auch keine zusätzliche Regel, um die Qualität zu erhöhen (siehe Varianten im Artikel). Wenn zu viele Bälle herunter fallen und wegrollen dann kommen die Teams selbst darauf, dass mit der Qualität etwas nicht stimmt.
4. Auch wenn in Boris seiner aktuellen Anleitung (Abruf 02/2020) keine Ergebnisgrafik mehr enthalten ist, verwende ich bewusst eine Grafik analog Bild 3 (ein Bild sagt mehr als 1.000 Zahlen…) mit durchaus 150 Bällen an der Y-Achse, um die Teams heraus zu fordern. Und ich versuche immer Zeit für 5 Iterationen zu haben, weil sich das Team nach 3 Runden eingespielt hat und dann ein gewisses Maximum mit seiner Vorgehensweise erreicht hat. Dann provoziere ich die Teams mit meinem hohen Skalenwert an der Y-Achse uns sage ihnen, dass andere Teams durchaus an diesen Wert herangekommen sind. Sie sollen doch noch mal überlegen, ob es nicht noch Verbesserungspotentiale gibt!
Das führ sehr oft dazu, dass die Teams ihr geübtes Vorgeben aufgeben und eine ganz neue, alternative Vorgehensweise ausprobieren (Disruptive Innovation). Und das Ergebnis ist in Bild 3 dargestellt: Die Teams brechen mit der Performance ein, weil sie sich erst einmal neu finden müssen; haben dann mit der neuen Vorgehensweise aber so viel Potential erschlossen, dass sie danach zu Ergebnissen kommen, die sie mit der zuerst verwendeten Vorgehensweise nie erreicht hätten.
Und damit erleben Sie zwei wesentliche Merkmale von Scrum:
1. Inspect & Adapt in kurzen Iterationen
2. Experimente und ggf. Rückschläge sind o.k., zu erwarten und nicht schlimm! Sie eröffnen aber neue Horizonte.
Eine Regel behalte ich aber immer in der Hinterhand, insb. nachdem ich das Ball-Point Game auch schon mehrfach in Schulklassen mit bis zu 34 Schülerinnen & Schülern als Teambildungsübung verwendet habe: „Die Bälle müssen nachvollziehbar durch das Team wandern…“