Vor ein paar Wochen lernten und spielten wir ein Teambuildung-Spiel für (agile) Teams auf der Agile Games Night des agiLE Meetup Leipzig. Hier ein kleiner “Spielbericht” für Euch.

Einfach Losspielen

Das Spiel ist ziemlich simpel und mit wenigen Materialien umsetzbar. Die Story besagt, dass die Teilnehmer mit einem Flugzeug in der Wüste abgestürzt sind und nur das Team selbst überlebt hat. Es gibt keine Informationen dazu, wo in der Wüste sie sich befinden. Sie haben lediglich eine Liste von 11 Gegenständen, die sich aus dem Flugzeugwrack bergen konnten. Was tut das Team nun? Und wie wichtig sind die 11 Gegenstände für das Team (als sortierte Liste, also ein Backlog)?

Als Material bekommen die Teilnehmer Papier, Stifte, Klebezettel, einen Tisch und ein Flipchart zu ihrer Verfügung. Auf dem Meetup bestand unser Team aus 8 Personen und einem Moderator. In Summe hat das Spiel nur etwa 30 Minuten gedauert.

Innerhalb dieser Zeit muss das Team die Gegenstände der Wichtigkeit nach sortieren. Dabei wird schnell klar, dass das Team zunächst von selbst darauf kommen sollte, sich ein Ziel zu setzen, auf das es hinarbeitet. Zum Beispiel: Wollen wir am Flugzeug auf Rettung warten und solange wie möglich überleben? Oder wollen wir möglichst rasch losgehen und damit versuchen, uns selbst retten?

Danach lohnt eine kurze Auswertung: Wie lief es? Was ist dem Team aufgefallen? Was haben die Teilnehmer gelernt?

Versuchskaninchen

Vor kurzem habe ich das Spiel noch einmal mit einem meiner Teams ausprobieren können. Das Team besteht schon seit einer Weile, die Mitglieder kennen sich gut und haben schon einige Sprints an einer Herausforderung gemeinsam gearbeitet.

Im Spiel zeigten sich aktive und passive Mitglieder und Muster der Aufgabenverteilung wie sie auch im Alltag des Teams auftreten. Der Product Owner des Teams etwa übernahm sehr schnell mit Stift und Zetteln die Rolle des Koordinators und baute das “Backlog” auf. Er stellte vor allem Fragen an das Team und sortierte aus den Antworten die Liste der Gegenstände um.

Im Alltag läuft das im Team sehr ähnlich ab: die Koordination übernimmt zumeist der Product Owner und das Team folgt. Dies zeigt sehr deutlich, dass das Team noch nicht erfahren genug ist, sich aktiv selbst zu organisieren und dass die aktive Unterstützung seitens eines Scrum Masters fehlt. Das Spiel hat dem Team also eher geholfen, seine eigene Rollenverteilung wahrzunehmen und erfüllte weniger den Zweck des Teambuildings.

Ziele und Gelerntes

Das Spiel vermittelt eine Situation, die mit einem Product Backlog Refinement vergleichbar ist. Das Team lernt, wie es gemeinsam priorisiert – etwa mit diesen Aspekten:

• User Stories sollten sehr klar und verständlich formuliert sein.
• Eine Definition of Ready bietet einige Vorteile.
• Techniken wie Planning Poker und Magic Estimation können hilfreiche Werkzeuge sein.

Zudem lernen die Teilnehmer auch, wie sich jeder einzelne in dieser Situation verhält:

• Wer war besonders aktiv oder passiv?
• Welche Rollen wurden übernommen oder fehlten?
• Welche Techniken oder Anregungen haben zu einer Einigung geführt?

Ein weiterer vermittelter Lerninhalt ist zudem die Wichtigkeit, eine klare Vision und ein Ziel zu haben, bevor man startet.

Das Spiel kann in unterschiedlichen Zusammenhängen eingesetzt werden. Für frisch gegründete und bestehende Teams oder Teams mit passiven zurückgezogenen Mitgliedern, empfiehlt sich das Spiel zur Reflektion von Aufgabenteilung und Arbeitsweise. In neu zusammengestellten Teams ist das Spiel außerdem dazu geeignet, den Prozess des Zusammenwachsens zu begleiten. Und letztlich macht das Spielen auch einfach Spaß.