Blog

Agile Games - wie Spiele die Agilität fördern

07. Dez 2022

In einem Kontext, der normalerweise gar nichts mit Spielen zu tun hat, werden auf einmal spielerische Elemente eingebaut und der natürliche Spieltrieb des Menschen genutzt. Was das bringen soll?

Lesezeit: 10min

Titelbild

In einem Kontext, der normalerweise gar nichts mit Spielen zu tun hat, werden auf einmal spielerische Elemente eingebaut und der natürliche Spieltrieb des Menschen genutzt. Nicht ohne Grund beschäftigt sich unsere Projekt-Managerin Anne viel mit dem Thema agile Games, besucht regelmäßig Events und trägt Spielideen ins Unternehmen. Auch unser agile Coach Timo nutzt LEGO in unserer agilen Basiswissenschulung, um Interessierten die agile Produktentwicklung näherzubringen. Was das bringen soll?

Chancen

  • Nachhaltiger Lerneffekt und Verstärkung des Teamgefühls 

  • Hohe Motivation durch gemeinsamen Spaß und hohe Emotionalität

  • Veränderter Blickwinkel/Perspektivwechsel

  • Förderung von Kreativität und Problemlösefähigkeit

  • Gelerntes kann in konkrete Maßnahmen umgesetzt werden

Du möchtest das ausprobieren?
Schnapp dir dein Team und teste doch mal eins der Spiele!

Agilität für Einsteiger

Epic Bedtime Story
LEGO-City
Product Owner Challenge
Epic Bedtime Story

Hierbei wird eurem Team die agile Produktentwicklung anhand der Erstellung eines Kinderbuchs näher gebracht. Ihr sollt verstehen, wieso es so wichtig ist, als interdisziplinäres Team nicht verteilt, sondern gemeinsam an einem Ort zu arbeiten.
Schlüpft in die Rolle von Writer, Illustrator und Editor und erfüllt die Anforderungen des Creators!

Learnings:

  • Teams wollen und müssen miteinander kommunizieren, auch wenn sie sich durch zum Beispiel Homeoffice nicht immer alle am selben Ort befinden.
  • Kommunikationsprobleme können sich auf Qualität und Leistung des Produkts auswirken.
  • Nicht zu wissen, was am anderen Ende vor sich geht, verunsichert einige Teammitglieder. Teams performen besser, wenn alle einen Überblick über den Produktfortschritt haben.

Und so funktioniert's

Wer?
2-6 Teams

Wie lange?
40 Minuten

Was brauchen wir?
- Papier (20-50 Blätter, je nach Teamanzahl)
- Marker oder Buntstifte (10 Stifte pro 5 Personen)

Wie?
Als erstes werden die Rollen verteilt. Es gibt einen Creator, der “Schöpfer” der Geschichte.
Er ist kein Teil der Teams, aber steht allen Teams zur Verfügung.
Der Creator wünscht sich eine Geschichte, die Kindern vorgelesen werden kann bzw. die sie selbst lesen können, wenn sie alt genug dafür sind.
Seine Regeln:

  • Es gibt nur eine Hauptfigur.
  • Auf jeder Seite müssen Bilder und Text sein.
  • Es dürfen maximal x Seiten erstellt werden.

In jedem Team gibt es:

  • Writer (Autoren) - Die Writer entscheiden, was in der Geschichte passieren wird und schreiben das Drehbuch.
  • Illustrator - Sie zeichnen die Bilder und müssen mit den Entscheidungen der Writer und Redakteure übereinstimmen.
  • Editor (Redakteure)  - Die Editoren entscheiden über das allgemeine Aussehen des Buches, die Gestaltung der Seiten, Grammatik und Kontinuität.

*

Die Teams müssen soweit auseinander sitzen, wie möglich.
Und los geht’s!

1. Planning (10min)
Die Teams teilen sich die Arbeit auf und verteilen die Rollen (Writer, Illustrator und Editor) untereinander. Sie überlegen sich, wie sie die Erstellung des Kinderbuchs organisieren wollen.

2. Sprint 1 (10min)
Im nächsten Schritt erstellen die Teams einen groben Entwurf.

3. Retro (5min)
Teaminterne Retrospektive
(Besprechung des abgeschlossenen Sprints, Diskussion sowohl über Probleme oder Hindernisse, welche entstanden sind, als auch darüber, was gut lief und beibehalten werden sollte. Hierbei geht es nicht um fachliche Aspekte, sondern die menschliche Zusammenarbeit im Team selbst, was das Teamwork und die Produktivität steigern soll.)

4. Sprint 2 (10min)
Im zweiten Sprint wird die endgültige Fassung des Kinderbuchs erstellt.

5. Demo und Rückblick/Retro 2
Die Teams stellen ihr fertiges Produkt dem Creator vor. Er bewertet, ob die Teams die Anforderungen erfüllt haben und ob ihm das Ergebnis gefällt.

Anschließend können alle Teams über Schwierigkeiten/Erfolge während der Sprints diskutieren.

Warm-up-Games

Lucky Lachs

Lucky Lachs könnt ihr schnell und einfach als kleine Aktivierungsübung einsetzen. Das Spiel ist schnell erklärt und fast genauso schnell gespielt.

Und so funktionierts:

Wer?
3-6 Personen

Wie lange?
10 Minuten

Was brauchen wir?
- das Spiel "Lucky Lachs"

Wie?
Stellt euch im Kreis auf. Jeder Spieler erhält ein Kartenset einer Farbe.
Es gibt vier Aktionen:

  • High Five
  • Checker-Faust
  • Tausch Rausch (die Plätze tauschen)
  • Lucky Lachs (sich gegenseitig auf den Unterarm klatschen)

Mischt die Karten nochmal durch und haltet sie verdeckt in der Hand. Alle Spieler decken gleichzeitig die oberste Aktionskarte ihres Stapels auf und müssen so schnell wie möglich einen Mitspieler finden, der die gleiche Aktionskarte oben auf seinem Stapel hat, um mit diesem gemeinsam die abgebildete Aktion auszuführen. Kann die Aktion nicht ausgeführt werden, wird die Karte wieder unter den Stapel geschoben. Danach geht es mit der nächsten Karte im Stapel weiter und die „gespielte“ Karte wird einfach auf den Boden geworfen. Ziel ist es, seinen Stapel so schnell wie möglich los zu werden.

Danish Clapping Game

Dieses Bewegungsspiel kann gut als Energizer eingesetzt werden. Ihr könnt den Kreislauf in Schwung bringen, euch vom vorherigen Termin ablenken und eine offene Haltung einnehmen, die zum Beispiel für kreative Aufgaben nützlich ist.

Und so funktioniert's:

Wer?
eine gerade Anzahl an Personen, egal wie viele

Wie lange?
5 Minuten

Was brauchen wir?
- nichts

Wie?
Die Mitspieler finden sich zu zweit zusammen und stellen sich gegenüber. Zuerst klatscht ihr mit beiden Händen auf eure Oberschenkel und streckt anschließend die Arme gerade nach oben. Dann klopft wieder auf die Oberschenkel und bewegt beide Arme nach links. Klopft wieder auf die Oberschenkel und streckt die Arme nach rechts. Klopft noch einmal auf die Oberschenkel und gebt euch ein doppeltes High-Five.

Nun kennt ihr alle Bewegungen des Spiels und schon kann es losgehen.

Klopft alle gleichzeitig auf eure Oberschenke. Als nächstes entscheidet jeder selbst, ob er seine Hände nach oben, rechts oder links bewegt. Haben du und dein Gegenüber dieselbe Bewegung gewählt, gebt euch ein doppeltes High-Five, ansonsten klopft wieder auf die Oberschenkel. Nun wählt eure nächste Bewegung und versucht immer schneller zu werden. Nach 5 Minuten ist das Spiel vorbei.

Sonstige

User Story Tabu

Ziel des Spiels ist es, den Teilnehmern des Workshops zu vermitteln wie gute User Stories geschrieben werden können. Dabei dürfen bestimmte Wörter aber nicht verwendet werden. Den Teilnehmer sollen die Perspektive wechseln, damit sie erkennen, dass Stories wie "Als Server möchte ich ..." nicht zielführend sind. Vielmehr sollen die Teilnehmer lernen, was es bringt, sich Gedanken dazu zu machen, wer bei einer User Story von einer Funktionalität profitiert und warum. Die User Stories werden am Beispiel von Anforderungen für ein erweitertes Schiffe versenken geschrieben. 

Info: Eine User Story, oder Anwendergeschichte, ist eine Anforderung des Kunden an das Produkt, also ein Item aus dem Product Backlog, dass noch bearbeitet werden muss. Die User Stories sind bewusst kurz und knapp gehalten und werden meist in Umgangssprache formuliert. Im Gegensatz zu klassischen Requirements erläutern User Stories auch den Grund, warum etwas getan werden muss. Der Grund oder der Anlass ist für das Team wichtig, um eine passende Lösung zu entwickeln.

Und so funktionierts:

Wer?
4-16 Personen

Wie lange?
60-90 Minuten

Was brauchen wir?
- die Anforderungen, ausgedruckt
- Flipchart

Wie?
Vorbereitung
Die verbotenen Wörter auf ein Flipchart schreiben:

ABC
NutzerUserBenutzer
besserschnellerAnwender
KundeServeransehen
arbeitenFirmaAuftraggeber
ProgrammSystemProduct Owner
Spieleherstellerleicht

Teilt euch in Gruppen von maximal 4 Personen auf. Jeder Gruppe wird ein Teil der Anforderungen zugewiesen (am besten gleich viele).

Runde 1: User Stories schreiben
Klärt miteinander, dass eine gute User Story beschreibt, wer etwas haben möchte, was er/sie haben möchte und warum er es/sie haben möchte.
Dabei bietet das Template "Als <Rolle> möchte ich <Funktionalität> damit ich <Nutzen> habe" meist eine gute Grundlage.
Nun kann sich jeder die verbotenen Wörter anschauen.

Anschließend werden die User Stories geschrieben, was manchmal 2-3 Iterationen in Anspruch nimmt, bis die User Stories die Anforderungen erfüllen und alle verbotenen Wörter eliminiert sind.

Runde 2: Akzeptanzkriterien erklären.
Info: Ein Akzeptanzkriterium ist eine niedergeschriebene fachliche Anforderung, welche ein Produkt zum Zeitpunkt der Abnahme erfüllen muss.

Jede Gruppe wählt sich nun 2 User Stories aus Runde 1 aus und schreibt hierzu die Akzeptanzkriterien auf (hier dürfen die Teilnehmer auch gerne zusätzlich kreativ sein).

Runde 3: Epics identifizieren.
Die Teilnehmer sollen nun die geschriebenen Stories nach Stories und Epics bewerten.

Info: Epics sind größere Aufgabeneinheiten, die in mehrere kleinere Aufgaben (namens Storys) unterteilt werden können.

Mob is You

Mit Mob is You kann sich euer Team ans Mob-Programming herantasten und ist auch für Nicht-Programmierer geeignet. Die Session kann auch remote stattfinden, wenn ihr ein Video-Konferenztool nutzt, bei dem die Teilnehmer die Kontrolle über Maus und Tastatur bekommen können.

Info:

Beim Mob-Programming geht es um einen Entwicklungsprozess, bei dem das gesamte Team gleichzeitig arbeitet. Am selben Ort und am selben Computer. Im Gegensatz zum Pair-Programming sitzen hier nicht nur zwei Personen, sondern fünf oder mehr Teilnehmer an einem Projekt. Dazu kommt die unterschiedliche Rollenverteilung:

  • Es gibt einen einzigen Driver: Die einzige Person mit einer Tastatur und Maus in der Hand ist auch die Person, die den Code ändern darf.

  • Jeder andere übernimmt die Rolle des Navigators. Während der Driver mit physischen Aufgaben beschäftigt ist, hat der Navigator die Zeit, die er braucht, um zu denken, zu rezensieren, zu diskutieren und zu beschreiben.

Die Rollen werden nach einer bestimmten Zeit getauscht getauscht. Zum Mob gehören tatsächlich alle Mitglieder des jeweiligen agilen Projektteams – Product Owner, Scrum Master, Entwickler, Designer. Alle nehmen an den Sessions teil, auch wenn sie selbst keine Programmierkenntnisse besitzen.

Und so funktionierts:

Wer?
Dein ganzes Team

Wie lange?
45 Minuten

Was brauchen wir?
- Game: “Baba is you”
- Rollenbeschreibungen von Willem Larsen
- großer Bildschirm
- Tastatur
- Rechner, auf dem das oben genannte Spiel läuft
- Timer

Wie?
Teil 1: Basic Mobbing
Nachdem ihr Setting und Ziele des Spiels geklärt habt, könnt ihr entscheiden, wer mit welcher Rolle starten möchte. Setzt den Timer auf 3 Minuten, startet das Spiel und lasst den Mob rotieren.

LEGO

Zwischendurch ist Zeit für ein paar situationsabhängige Fragen:

  • Warum hat der Driver nicht auf den Navigator gehört? 

  • Ist es okay für euch, dass der Navigator die Ideen aus dem Mob komplett ignoriert?

  • Warum hat einer aus dem Mob entschieden, was als nächstes gemacht wird und nicht der Navigator? 

  • Was wäre, wenn es keinen Navigator gebe und der Mob bestimmt, was der Driver tut? 

  • Was könntet ihr tun, damit Navigator/Driver/Mob besser ihre Rolle ausüben können?


Teil 2: Die Rollenkarten
Teilt die Rollenbeschreibungen von Driver, Navigator und Mob von Willem Larsen aus. Nun geht es darum, wie oft man in seiner Rolle genau das getan hat, was laut Rollenbeschreibung auf dem Zettel steht. Das Ankreuzen der eigenen Taten gibt noch einmal einen tieferen Einblick in die Rolle des Drivers, Navigators und Mobs.

Teil 3: Das Debrief
Besprecht die Session nochmal. Was habt ihr mitgenommen? Was habt ihr gelernt?
Folgende Fragen könnten beispielsweise gestellt werden:

  • Wärt ihr in diesem Spiel auch so weit gekommen, wenn ihr alleine gespielt hättet? 

  • War die Session für jemanden langweilig? 

  • Hat sich jemand verloren gefühlt oder ist nicht mitgekommen? Warum bist du nicht komplett ausgestiegen?

  • War es schlimm, wenn jemand einen Fehler gemacht hat? Wie habt ihr euch darüber geäußert?

  • Wie empfandet ihr den Wechsel zwischen Driver, Navigator und Mob? Hatte es positive Auswirkungen auf das Spiel?  

  • Würdet ihr Mob Programming nun auch im daily Business ausprobieren?

Du hast eines der Spiele ausprobiert oder kennst noch weitere agile Games?
Teile uns gerne deine Erfahrungen mit!

LEGO-City

Ein Kunde kommt zu euch und möchte "eine Lego-Stadt". Er weiß nicht genau wie diese aussehen soll, aber er hat auf jeden Fall einige Anforderungen im Kopf. Ihr durchlauft vier Iterationen: Vom Sprint Planning über die Durchführung bis zum Review und der Retrospektive.

Learnings:

  • Die Bedeutung von Agilität und Scrum.
  • Wie man flexibel auf veränderte Produktanforderungen reagieren kann.

Und so funktioniert's

Wer?
Euer ganzes Team

Wie lange?
30 Minuten

Was brauchen wir?
- LEGO Creative Boxen
- Whiteboard
- Post-Its
- Marker
- einen Kunden mit Anforderungen an die LEGO-City
- einen Product Owner

LEGO

Wie?
1. Anforderungen des Kunden (5 Minuten)
Der Kunde schildert seinen Wunsch, wie das Produkt aussehen soll. So soll die LEGO-Stadt zum Beispiel 

  • eine Straße
  • einen Zebrastreifen
  • Bäume
  • einen Kindergarten
  • einen Elefanten
  • eine Brücke enthalten.

Beachtet dabei, dass nicht nur der Spaß für die Kinder des Kunden garantiert, sondern auch die Verkehrserziehung vermittelt werden soll.

2. Sprint Planning (4 Minuten)
Der Product Owner erhält alle Anforderungen des Kunden, welche euer Team einschätzen soll - und zwar nicht nach Zeit und Aufwand, sondern nach Komplexität. Nun teilt euch in die Gruppen “Spaß”, “Landschaft” und Infrastruktur” auf und überlegt euch, welche Anforderungen ihr in der ersten Iteration (begrenzt auf 4 Minuten) umsetzen wollt und könnt.

2. Sprint 1 (4 Minuten)
Versucht nun, die Anforderungen, die ihr für diesen Sprint ausgewählt habt, so gut es geht umzusetzen.

3. Review mit dem Kunden (4 Minuten)
In diesem Termin präsentiert ihr dem Kunden das Ergebnis eures Sprints. Ist die Straße vielleicht zu hügelig oder der Kindergarten nicht groß genug? Die Verbesserungswünsche nehmt ihr mit in die nächste Iteration und schaut, ob ihr eine weitere Anforderung erfüllen könnt.

4. Sprint 2 (4 Minuten)
Neben den bisherigen Anforderungen, möchte der Kunde spontan eine weitere Anforderung hinzunehmen, auf die ihr flexibel reagieren könnt. In diesem Sprint stellt ihr eure LEGO-City auch schon fertig. Ob euch der Kunde euer Ergebnis abnehmen wird?

5. Retrospektive (4 Minuten)
Was hat gut geklappt? Was hat nicht so gut geklappt? Und was würdet ihr euch für das nächste Mal vornehmen?

LEGO-City
Product Owner Challenge

Dieses Spiel kann euch beim Übergang vom klassischen Wasserfallmodell hin zur agilen Denkweise unterstützen - mit LEGO!

Learnings:

  • Product Owner müssen die Ziele, Anforderungen und Produktivisionen klar an die Entwickler kommunizieren.
  •  POs sollten den Entwicklern die Selbstorganisation ermöglichen, zu detaillierte Anweisungen behindern die Kreativität und führen schnell zum Mikromanagement.
  •  Die Zusammenarbeit an einem Ort führt zu schnelleren Ergebnissen und besserer Qualität; 

Und so funktioniert's

Wer?
Product Owner und Entwickler

Wie lange?
30 Minuten

Was brauchen wir?
- zwei Räume (oder ein großer Raum)
- LEGO 3in1 Creator Set

Wie?
1. Vorbereitung:
Der Product Owner und die Entwickler befinden sich in unterschiedlichen Räumen/weit genug voneinander entfernt. Die Entwickler verfügen über einen Lego-Bausatz. Nur der PO hat Einsicht auf die Produktbeschreibung und darf sie so oft er möchte anschauen. Allerdings darf er sie den Entwicklern nicht zeigen. 

2. Der Product Owner versucht nun die Produktvision so klar wie möglich zu vermitteln und weist sie so präzise wie möglich an. Die Entwickler versuchen das Produkt nach dieser Anleitung zu bauen. Die Zeit wird auf 30 Minuten begrenzt.

Product Owner Challenge

Debriefing

PO:

  • Wie einfach/schwer war die Aufgabe für dich?
  • Hat dich die Aufgabe gestresst? - Warum?
  • Wie war die Kommunikation mit den Entwicklern?
  • Wie oft hast du dir die Anweisungen nochmal angeschaut?
  • Wie viele Abweichungen bestehen zwischen dem Endprodukt (Modell) und der Produktvision (Bauanleitung)?

Entwickler:

  • Wie einfach/schwer war die Aufgabe für dich?
  • Was hat Ihre Aufgabe leicht/schwer gemacht?
  • Wie war die Kommunikation mit dem PO?
  • Wie könnte der PO ihre Anweisungen verbessern?
  • Hast du deine Aufgaben/Ziele zu jeder Zeit verstanden?

0Noch keine Kommentare

Ihr Kommentar
Antwort auf:  Direkt auf das Thema antworten
empiriecom
Cookie Hinweis

empiriecom GmbH & Co. KG und Partner brauchen für einzelne Datennutzungen deine Einwilligung, um dir unter anderem Informationen zu deinen Interessen anzuzeigen.