Learning by doing: Als Trainer vermittelt Matthias Wolf-Dietrich seinen Teams die Prinzipien von agilem Projektmanagement, indem er mit ihnen agiles Arbeiten simuliert. Ein ideales Einsteigerspiel ist das Ball-Point-Game, das nach dem Ansatz "Inspect and Adapt" funktioniert. Die Spieler erleben unterschiedliche agile Elemente und Meetings wie Sprints sowie Retrospektiven und sammeln Erfahrungen in einem selbstorganisierten Team.
Als Mitglied erhalten Sie die wichtigsten Thesen des Beitrags zusammengefasst im Management Summary!
Learning by doing: Als Trainer vermittelt Matthias Wolf-Dietrich seinen Teams die Prinzipien von agilem Projektmanagement, indem er mit ihnen agiles Arbeiten simuliert. Ein ideales Einsteigerspiel ist das Ball-Point-Game, das nach dem Ansatz "Inspect and Adapt" funktioniert. Die Spieler erleben unterschiedliche agile Elemente und Meetings wie Sprints sowie Retrospektiven und sammeln Erfahrungen in einem selbstorganisierten Team.
Als Mitglied erhalten Sie die wichtigsten Thesen des Beitrags zusammengefasst im Management Summary!
Man kann Scrum-Trainings besuchen, man kann viel und lange ĂŒber AgilitĂ€t reden und diskutieren â oder man probiert es einfach mal selbst aus. Denn nur so wird man begreifen, was die Erfolgsfaktoren sind und wie diese zusammenspielen. "Be-greifen" ist ein gutes Stichwort: Der Vorteil einer Simulation ist das BerĂŒhren, das Erfahren und das Selbsttun. Lernen braucht ein positives emotionales Umfeld, erst so wird nachhaltiges Lernen möglich. Als Trainer und Berater baue ich daher gerne praktische Ăbungen in meine Trainings ein. Eine davon, das Ball-Point-Game, ist eine einfache Simulation. Ein Spiel, das in kurzer Zeit die wichtigsten Erkenntnisse des agilen Arbeitens nĂ€herbringt.
Beim Ball-Point-Game soll das Team eine "menschliche Ballmaschine" bauen. In mehreren Zyklen wird simuliert, wie ein agiler Prozess aussieht und â noch wichtiger â wie sich die Zusammenarbeit in einem echten Team anfĂŒhlt. Die Teilnehmer erleben unterschiedliche agile Elemente sowie Meetings und können Erfahrungen in einem selbstorganisierten Team sammeln.
Ein Team besteht sinnvollerweise aus mindestens vier Personen, es können aber auch mehr sein â mit bis zu 200 haben wir es schon ausprobiert. Die ideale TeamgröĂe liegt erfahrungsgemÀà bei sieben Personen. NatĂŒrlich können auch mehrere Teams parallel spielen, das motiviert viele Teilnehmer noch mehr, weil die Teams vermeintlich in Konkurrenz zueinanderstehen. FĂŒr das Ball-Point-Game sollte man ca. 30 bis maximal 60 Minuten einplanen. Es eignet sich vor allem fĂŒr Teams, die noch wenig oder gar keine eigene Erfahrung mit agilen Methoden haben.
Bild 1: Das Ball-Point-Game im vollen Gang
Neben Flipchart und -Markern (idealerweise eine Farbe pro Team plus einen schwarzen Stift) und einer Stoppuhr (Handy reicht auch) brauchen Sie natĂŒrlich BĂ€lle â einer pro Teilnehmer ist das Minimum, mehr sind wĂŒnschenswert, damit immer ausreichend BĂ€lle zur VerfĂŒgung stehen und der Spielfluss nicht ins Stocken gerĂ€t.
Auf einem Flipchart vermerkt der Moderator in jeder Iteration die SchĂ€tzungen der Teams und ihre Ergebnisse, also die Anzahl der durchgeschleusten BĂ€lle. Das kann entweder in Form einer Tabelle (Bild 1) passieren oder in einer Grafik (Bild 2), welche die Teilnehmer selbst ausfĂŒllen. Die Tabelle besteht aus drei Spalten: "Iteration", "SchĂ€tzung" und "Ergebnis". In jeder Zelle können dann die SchĂ€tzungen und Ergebnisse pro Team, eventuell in unterschiedlichen Farben, eingetragen werden (siehe Bild 2).
Bild 2: Tabelle zum Eintragen der Ergebnisse
Wenn Sie die Darstellung in einer Grafik wĂ€hlen, zeichnen Sie auf der horizontalen Achse die Iterationen auf und auf der vertikalen eine Skala fĂŒr die erreichten Punkte, hier von 0 bis 100. SpĂ€ter können die Teams ihre (optionalen) SchĂ€tzungen mit einem "O" bei der richtigen Iteration eintragen. Die Ergebnisse werden mit einem "X" an der betreffenden Stelle notiert (siehe Bild 3).
Bild 3: Grafik zum Eintragen der Ergebnisse
Durch die unterschiedlichen Farben lassen sich die Eintragungen der Teams gut unterscheiden. Sollte die vertikale Skala nicht ausreichen, da ein Team ĂŒber 100 Punkte sammelt, kann man sie im Verlauf der Simulation auch erweitern. Dass es die Skala gesprengt hat, kann das Team zusĂ€tzlich motivieren.
Olivia Danilsen
20.11.2018
Matthias Wolf-Dietrich
20.11.2018
Hier âwie gewĂŒnscht â meineâŠ
27.02.2020
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âŠâ