Steinzeit Team Spiel

Eine Projekt Simulation, welches auf spielerische Art und Weise zeigt, was für Arbeitsweisen dabei helfen, bessere Produkte herzustellen. Basierend auf einer Ideen von X. Detant

Spiel zur Simulation AARGH! TECT

Spiel Cover AARGH! TECT

Inhalt des Spiels

  • Eine Karte mit der Erklärung der Bewegungen für die Farben und Befehle für Bewegungen in Steinzeitsprache
  • Holzblöcke zur Errichtung der Bauten
  • Karten mit Bauten (an der rechten unteren Ecke der Karten befinden sich die “Werte Punkte” für ein vollständig erbautes Gebäude)
  • Zwei Keulen (ich nenne sie liebevoll die “Feedbackkeulen”)
Spielinhalt

Um die Simulation mit zwei Teams gleichzeitig durch zu führen, wird nur ein Spiel benötigt.

Vorbereitungen vor Spielbeginn

  • Zeichne ein Diagramm (x Achse für Runde – Runde 1, Runde 2, Runde 3, y Achse – Werte Punkte). Das Spiel hat insgesamt 3 Runden. 
  • Stelle sicher, dass auf jedem Tisch post its und Stifte sind.
  • Erkläre und zeige alle Bewegungen zu den Farben und nenne ein Paar Beispiele zu den Bewegungen.
  • Für die Simulation gibt es zwei Grundregeln, auf deren Einhaltung Du während des gesamten Spieles achten musst:
    • Das Entwickler / Erbauer Team darf niemals das zu bauende Gebäude auf der Karte sehen, außer sie sagen, dass sie fertig sind und ein Review ansteht.
    • Während den 7 Minuten in denen das Spiel läuft, darf niemand eine andere Sprache sprechen, als die Steinzeitsprache.

Runde 1

Set Up

Zwischen den Gebäudebauern und dem Manager muss eine “Mauer” so stehen, dass der Manager nicht sehen kann, was gebaut wird. Ich nehme dazu den Karton des Spiels und weise die Leute darauf hin, dass sie hinter der Box bauen sollen.

  • Eine Person spielt den Manager
  • Mindestens eine Person ist der Gebäudebauer (bei genug Personen kann man das Spiel auch damit beginnen, dass jeweils einer zuständig ist für einen oder zwei Holzsteine)
  • Eine Person spielt den Kunden

Bevor die erste Runde beginnt:

Der Kunde zieht eine Karte aus dem Kartenstapel. Nun hat er 5 Minuten Zeit auf einem Stück papier zu beschreiben, was er für ein Gebäude erbaut haben möchte. Am besten ist es, wenn der Tisch des Kunden weit weg ist vom Tisch der Gebäudebauer. Das gibt ein echtes Gefühl der Distanz, welches wir auch oft in echten Softwareprojekten erleben.

Spiel (7 Minuten)

Ab jetzt darf niemand mehr eine andere Sprache als die Steinzeitsprache sprechen. Der Manager erklärt 7 Minuten lang, was für ein Gebäude der Kunde haben möchte und darf dabei nur die Anforderung auf dem Zettel lesen. Falls es Fragen geben sollte, darf der Manager zum Kunden gehen und (in normaler Sprache) seine Fragen stellen und auch Antworten bekommen. Stelle dabei sicher, dass die Gebäudebauer nichts mit hören können, um das Ergebnis nicht zu verfälschen. Sind die Entwickler der Meinung, dass das Gebäude fertig ist, kann ein Review statt finden. Wurde das Gebäude korrekt erbaut (kommt praktisch nie vor in der ersten Runde), darf der Kunde eine weitere Karte ziehen und seine Anforderung beschreiben.

Markiere die Werte Punkte für jedes Team auf dem Diagramm

Mache eine Retro mit allen Spielern (3 Minuten)

  • Frage nach den Problemen
  • Erfrage mögliche Verbesserungen

Für gewöhnlich ist das erste Problem, dass der Manager gar nicht sehen konnte, was erbaut wird. Das zweite, dass er nicht wirklich verstanden hat, was der Kunde wollte.

Ein weiteres Problem ist, dass rechts, links, hinten und vorne aus der Sicht des Managers andere Richtungen sind als aus der Sicht der Entwickler und es so zu Verständnis Problemen kann. In diesem Fall kann das Team (in seiner internen Retro), ob sie die Richtugnen mit Zettel markieren wollen. Als Facilitator kann man darauf hinweisen. Ich finde es spannender es nicht zu tun 😉

Nach dieser Retro können folgende Verbesserungen vom Facilitator gemacht werden:

  • Entferne die Box, damit der Manager sehen kann, was das Team baut.
  • Entferne den Manager (oder gib ihm eine andere Rolle), So dass nun der Kunde direkt erklärt, was er auf der Karte sieht (Anmerkung: Es gibt Teams, die ihren Manager behalten wollen. Wenn das Team eine andere Lösung ansrebt, ist das vollkommen ok und sollte vom Facilitator zugelassen werden. Meist kommen die Teams auf, für sie sehr gut funktionierende, Lösungen.

Retro innerhalb des jeweiligen Teams (2 Minuten)

Die Teams haben nun Zeit ihre eigenen Verbesserungen zu besprechen und umzusetzen.

Runde 2

Set Up

  • Keine Box mehr zwischen Gebäudeerklärer und Team
  • Kunde erklärt statt Manager, was er haben möchte (Falls das nach Retro in Runde 1 das so umsetzen wollte. Ansonsten so verfahren, wie das Team entschieden hat.)

Spiel (7 Minuten)

Erklärer zieht eine Karte vom Stapel. In den nächsten 7 Minuten ist nur noch Steinzeitsprache erlaubt. Beendet das Team ein Gebäude, so gibt es ein Review durch den Erklärer. Ist das Gebäude korrekt, kann eine weitere Karte gezogen werden. Wenn nicht muss das Team weiter bauen. Das Team sollte natürlich die Endlösung auf der Karte nicht gesehen haben.

Trage die Wert Punke im Diagramm ein

Mache eine Retro mit allen Spielern (3 Minuten)

  • Frage nach den Problemen
  • Frage nach möglichen Verbesserungen

Für gewöhnlich ist das Hauptproblem nach Runde 2, dass es keine Möglichkeit des Feedbacks gibt.

Nach dieser Retro können folgende Verbesserungen vom Facilitator gemacht werden:

Führe die Feedbackkeule ein. Dei erklärende Person kann den Entwickler Feedback geben. Ein Schlag auf den Kopf bedeutet “ok””, zwei oder mehr “nicht ok”. Der Erklärer kann sich auch selbst auf den Kopf schlagen, falls er selbst einen Fehler einräumen will.

Retro innerhalb des jeweiligen Teams (2 Minuten)

Die Teams haben nun Zeit ihre eigenen Verbesserungen zu besprechen und umzusetzen.

Runde 3

Spiel (7 Minuten)

Läuft ab wie in Runde 2 nur mit zusätzlicher Verwendung der Feedbackkeule

Trage die Wert Punke im Diagramm ein

Letzte Retro mit allen Teilnehmern zusammen (Je nach dem wie viel Zeit noch übrig ist oder man aufwenden möchte)

  • Was haben wir während des Spiels gelernt?
  • Welche Verbesserungen haben das Ergebnis positiv beeinflusst? Warum?
  • Welche Faktoren führten dazu, dass ein Team bessere Ergebnisse erzielt hat als das andere? (Nur bei marginalen Unterschieden zwischen den Ergebnissen und in einem nicht diskrimierenden Ton!)

Einige Beispiel Learning Objectives

Einige Ideen zur Veränderung des Spiel Setup, um weitere Learning Objectives zu generieren (Großen Dank hier an die Teilnehmer der Session bei der play4agile 2018)

  • Eine Runde mit einem “Remote Gebäudebauer”, der nicht immer gleich alles sieht oder mit bekommt
  • Ein Gebäudebauer, dessen Augen verbunden sind und Deliverer, die ihm die Bauteile in die Hand geben
  • Runde 2 mit Schreiben des Konzept, aber mit mehr Transparenz für den Manager (Teamarbeit zwischen Kunde und Manager)

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.