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.
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:
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.
Dann kann man vergleichen, wie gut die Schätzung war.
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.
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."
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.
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.
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:
- Die Teilnehmer bilden ein einziges Team.
- Jeder Teilnehmer muss jeden Ball mindestens einmal berührt haben. Die Berührung symbolisiert die Mitarbeit in einem Projekt oder im Betrieb.
- Bei der Übergabe von einem Teilnehmer zu einem anderen muss der Ball kurz in der Luft sein ("Airtime").
- 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 |
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.
Ausgezeichnete Wiki
AntwortenLöschen