Direkt zum Hauptbereich

Spielerisch lernen, was "agil" bedeutet: Das Ball Point Game

Seit einigen Jahren verwenden wir für unsere Organisationsentwicklungsprojekte agile Methoden. Ganz am Anfang eines Projekts möchten wir als externe Berater den Projektteilnehmern im Kundenunternehmen den Grundsatz "rasche Feedback-Zyklen statt eines perfekten Projektplans" nahe bringen. Die besten Erfahrungen haben wir dabei mit einem Spiel gemacht,  das die Besonderheiten dieses neuartigen Vorgehens schlagend demonstriert.

Früher habe ich in meinen Startworkshops von Projekten immer sehr gut ausgearbeitete PowerPoint-Vorträge gehalten. Darin habe ich dann lang und breit die Vorteile von agilen Vorgehensweisen anhand mehr oder weniger schlagender Rechenbeispiele vorgetragen. Das dauerte relativ lang und das Ergebnis war mäßig. Die Teilnehmer konnten meine Argumente glauben oder auch nicht. Also verstärkte ich meinen Überzeugungsdruck Richtung Zuhörer. Die Folien wurden mehr und sie wurden reichhaltiger. Das Ergebnis wurde nicht besser.

Bis ich dann durch einen Kollegen in unserem CST-Team (an seinen Namen kann ich mich nicht erinnern, wir sind einfach zu viele) auf das Ball Point Game /1/ aufmerksam gemacht wurde. Man kann dieses Spiel verwenden, um die Methode der Retrospektive, aber auch die der Sprints im allgemeinen schnell klar zu machen.

Die Spielregeln


Für das Spiel wird ein Korb mit 24 Tischtennisbällen neben einen der Teilnehmer gestellt. Das Ziel besteht darin, so viele Bälle wie möglich in einer Minute durch die Reihe der Teilnehmer laufen zu lassen und am Schluss in einen Korb abzulegen.

Die Regeln sind sehr einfach:
  1. Die Teilnehmer bilden ein einziges Team.
  2. Jeder Teilnehmer muss jeden Ball mindestens einmal berührt haben. Die Berührung symbolisiert die Mitarbeit in einem Projekt oder im Betrieb.
  3. Bei der Übergabe von einem Teilnehmer zu einem anderen muss der Ball kurz in der Luft sein ("Airtime").
  4. Bälle, die runterfallen, gelten als Fehler.


Die Festlegung, dass der Ball sich zwischen zwei Teilnehmern kurz in der Luft befinden muss, verhindert zu einfache Lösungen (zum Beispiel: alle Bälle kommen in eine flache Schale und alle Teilnehmer berühren sie mit der Hand).

Einer der Teilnehmer wird zum "Controller" ernannt. Er muss die Zahl der im Korb angekommenen Bälle zählen. Dabei kann es sich um einen Mitspieler handeln, oder um jemanden, der von außen zuschaut.

Der Ablauf

Das Spiel wird auf einem Flipchart protokolliert. Pro Durchlauf wird eine Zeile geschrieben (siehe Abbildung). Vor jedem "Sprint" müssen die Teilnehmer schätzen, wie viele Bälle sie wohl durch die Reihen geben werden. Nach jedem Durchlauf wird die Zahl der durchgereichten aufgeschrieben und die Anzahl der Fehler (= runtergefallene Bälle) abgezogen.

Dann kann man vergleichen, wie gut die Schätzung war.


Das Ergebnis eines Ball Point Games in sechs Runden
  
Anschließend erhält das Team drei Minuten Zeit, um den nächsten Sprint vorzubereiten. Es kann Maßnahmen festlegen, um die Effizienz zu steigern. Nach dieser 3-Minuten-Retrospektive erfolgt der nächste Durchlauf à einer Minute usw.

Erfahrungen mit dem Spiel

Das Beispiel zeigt noch eine relativ mäßige Steigerung. Innerhalb von sechs Sprints (also von circa 24 Minuten) hat sich die Anzahl der Bälle von 25 auf 78 gut verdreifacht. Ich habe auch schon Teams erlebt, die sich auf das Sechsfache steigerten.

Die erste Erfahrung ist: keiner kann sich dem Spiel entziehen. Die Teilnehmer oder eine Fraktion davon mag mit kritischen Mienen in den Raum gekommen sein - sowie das Spiel beginnt, erzeugt es eine unwiderstehliche Sogwirkung. Noch nie ist jemand außen vor geblieben. Das funktioniert auch über Hierarchiegrenzen hinweg oder auch über vorher existierende Spannungen zwischen verschiedenen Teilnehmergruppen.

Wir Menschen sind Gruppenwesen. Steck mich in eine Gruppe und gib der Gruppe eine Aufgabe - und ich werde mitmachen.

Was vorkommt, ist dass Teams nach 3, 4 Runden resignieren. "Jetzt ist keine weitere Steigerung möglich." Dann empfiehlt es sich, dem Team vorzuschlagen, es noch zwei Runden zu versuchen und dabei einen Teilnehmer zum "Scrum-Master" zu ernennen. Der spielt nicht mit, sondern schaut von außen zu und gibt in den Retrospektiven Feedback - sowohl zum Spiel selbst als auch zum Diskussionsstil in den Retrospektiven selbst. Auch das hat nach meiner Erfahrung immer gewirkt.

Es kommt auch vor, dass ein Sprint ein schlechteres Ergebnis liefert als der vorherige. In der Abbildung sieht man das. Zwischen Runde 4 und 5 wurde eine Änderung eingeführt, die sich nicht positiv auswirkte. Aber, bemerkte ein Teilnehmer in der anschließenden Spielauswertung, "ohne die Erfahrung in Sprint 5 hätten wir den Sprung in Sprint 6 nicht machen können."

Auswertung des Spiels

Bei der gemeinsamen Spielbilanz nach Abschluss der letzten Runde lasse ich die Teilnehmer erst einmal berichten, wie zufrieden sie mit dem Ergebnis  sind und ob sie es am Anfang erwartet hätten.

Dann stelle ich noch zwei Fragen.

"Sie haben sechs Runden gespielt. Dabei hatten Sie insgesamt 18 Minuten Zeit für die 'Planung', d.h. um sich Gedanken über Ihre Prozessmethode zu machen.
Wenn ich Ihnen diese 18 Minuten Planungszeit am Anfang des Spiels gegeben hätte und hätte Sie aufgefordert: 'Machen Sie doch bitte einen guten Plan, wie Sie vorgehen wollen!' - meinen Sie, dass Sie dann das gleiche Ergebnis erreicht hätten?"

Die Antwort ist regelmäßig: Nein, das hätten wir nicht erreicht. Nur die praktische Erfahrung, die wir immer wieder gesammelt haben, hat diese Steigerung möglich gemacht. "Probieren geht vor studieren", sagt kürzlich eine Teilnehmerin.

Für die zweite Frage gehe ich auf einen beliebigen Teilnehmer zu (wobei ich mir jemanden aussuche, der psychisch robust wirkt): "Herr (oder Frau) X, ich habe jetzt leider die Pflicht, ein kritisches Wort zu verlieren. Sie waren deutlich der Langsamste im Team. Ich schätze, Sie waren 20% langsamer als der Rest. Ich fürchte, dass ich das bei unserem nächsten Jahreszielgespräch auf  die Tagesordnung setzen muss."

Der angesprochene Teilnehmer reagiert zu Beginn verdutzt. Die meisten merken nach den ersten drei Sätzen, dass es sich um einen Scherz handelt. Einige wenige Ausnahmen habe ich erlebt, in denen der Angesprochene sich zu verteidigen versuchte.

Ich wende mich dann an das Team: "Was ich gesagt habe, stimmt alles nicht. Herr X war nicht langsamer und ich habe niemanden daraufhin beobachtet. Aber stellen Sie sich vor, mein Vorwurf hätte der Wirklichkeit entsprochen. Es gibt ja in der Realität Leute, die langsamer arbeiten als andere. Was hätte das genutzt, auf diesen 'Flaschenhals-Schuldigen' loszugehen und ihm Druck zu machen?"

Auch hier ist die Erkenntnis der Teams immer ähnlich: Wir wären bestenfalls um 20% schneller geworden. Aber wir wollen ja nicht um 20% schneller werden, sondern um mindestens 300%. Also ist die Sündenbockmethode bestenfalls Zeitverschwendung.

Nutzen des Spiels (und eine Frage)

Das Spiel erlaubt es den Teilnehmern des Workshops, in sehr kurzer Zeit eine sehr verdichtete und intensive Erfahrung zu machen. Es geht dabei nicht nur um die Methode selbst, nicht nur um "Sprints und ständige Verbesserung statt perfekter Vorausplanung". Es geht auch um die Erfahrung des Zusammenarbeitens in (weitgehend) hierarchiefreien Teams.

Aber eine Frage bleibt auch, ein Wermutstropfen gewissermaßen. Siehe oben: Steck uns Menschen in eine Gruppe und gib uns eine Aufgabe - und wir werden mitmachen.

Das Ball Point Game hat ja keinen "Sinn". Es erzeugt keinen Wert. Und es begeistert trotzdem. In der Realität funktionieren agile Teams sehr gut. Egal, ob es darum geht, bessere medizinische Diagnoseplattformen zu schaffen oder bessere Überwachungssoftware für E-Mails in Diktaturen.

Anmerkungen

/1/ nach http://tastycupcakes.org/2014/05/ball-flow-game/

Kommentare

Kommentar veröffentlichen

Beliebte Posts aus diesem Blog

Outlook-Aufgabenliste: bitte nicht die Aufgaben des ganzen Teams!

Am Tag der Arbeit kommt eine Lösung, nach der ich schon so oft gefragt wurde: Wie schaffe ich es, dass meine Outlook-Aufgabenliste nur meine eigenen Aufgaben anzeigt und nicht auch die E-Mails, die meine Kollegen gekennzeichnet haben oder Aufgaben, die einfach in einem gemeinsamen Postfach stehen?

Kategorien in Outlook - für das Team nutzen

Kennen Sie die Kategorien in Outlook? Nutzen Sie diese? Wenn ja wofür? Wenn ich diese Fragen im Seminar stelle, sehe ich oft hochgezogene Augenbrauen. Kaum jemand weiß, was man eigentlich mit diesen Kategorien machen kann und wofür sie nützlich sind. Dieser Blogartikel stellt sie Ihnen vor.

Das Ubongo Flow Game

Spiele bieten eine gute Gelegenheit, zeitliche Erfahrungen zu verdichten und gemeinsam zu lernen. Karl Scotland und Sallyann Freudenberg haben im Mai 2014 das Lego Flow Game veröffentlicht. Wir haben die Spielidee übernommen, aber das Spielmaterial gewechselt. Statt Legosteinen benutzen wir Material aus Grzegorz Rejchtmans Ubongo-Spiel. Hier präsentieren wir die Anleitung für das Ubongo Flow Game.

Beispiel für eine Partyplanung mit Scrum

Wer sich neu mit Scrum beschäftigt, ist vielleicht überwältigt von den ganzen Fachbegriffen. Dann sieht man vielleicht gar nicht, wie einfach die einzelnen Elemente von Scrum sind. Deshalb hier ein einfaches Beispiel für die Vorbereitung einer Party mit Hilfe von Scrum.

E-Mail-Vorlagen gemeinsam nutzen (Outlook)

Mittlerweile wird praktisch alle Routine-Korrespondenz in Outlook erledigt. Was liegt da näher, als ein gutes Set von Vorlagen zu erstellen und diese gemeinsam in Team zu nutzen? Leider hat Microsoft vor diesen – an sich simplen – Wunsch einige Hürden gebaut.

Tooling #5: Die gute alte Systemtheorie

Gelegentlich fragen mich Menschen nach den wichtigsten Tools und Herangehensweisen für meine Arbeit. Einige davon habe ich hier im Blog bereits vorgestellt (und zwar  hier ). Heute möchte ich über ein weiteres, vielleicht sogar DAS entscheidende Basiswerkzeug sprechen: Die gute alte Systemtheorie.

Protokolle in OneNote - neue Ideen für's neue Jahr

Protokolliert Ihr Team seine Besprechungen in OneNote? Das geht einfach, schnell ist teamfähig und hat eine exzellente Suchfunktion. Die beliebte Fragen "Wann haben wir eigentlich beschlossen, dass..." ist so schnell beantwortet. Darum wird OneNote an dieser Stelle immer beliebter. In meinen Seminaren dazu sind gute Ideen entstanden, die ich hier weitergeben will.

Ich bin ganz oben (mit Kanban und Outlook)

Mit einem Kommentar zu einem lesenswerten Artikel von Thomas Mauch /1/ habe ich es an die Spitze der Trefferliste bei Google geschafft. Suchen Sie mal nach „Kanban Outlook“. Kanban ist eine alte Idee, aber immer noch der Renner unter den Produktivitätswerkzeugen. (There is an English version of this post.)

Scrum und Kennzahlen (KPIs, Metriken)

In regelmäßigen Abständen hören wir die Frage, welche Kennzahlen (neudeutsch KPIs) bei Scrum sinnvoll sind. Zeit für einen längeren Beitrag, auf wichtige Ressourcen zu verweisen. Der Scrum-Guide selbst gibt dazu keine erschöpfende Auskunft. Und das hat seine Gründe.

OneNote Prinzipien: Zugriffsrechte und Speicherorte

OneNote ist praktisch – ohne jeden Zweifel. OneNote ist auch einfach und intuitiv zu bedienen… Ja… so am Anfang. Doch früher oder später kommen Fragen wie: - wer genau hat eigentlich wie Zugriff auf die Daten? Wie ist das mit Synchronisation zwischen Büro-PC und Smartphone oder iPad? Wie funktioniert OneNote auf dem SharePoint? Auf diese Fragen findet sich die Antwort nicht ganz so leicht. Ich versuche hier die nicht ganz so offensichtlichen Zusammenhänge deutlich zu machen und "gern genommene" Fallen zeigen.