Agile Jenga

Jenga ist ein Geschicklichkeitsspiel aus dem Jahre 1983. Mehr Informationen gibt es im Wiki Artikel Jenga. Agile Jenga nutzt den Spieleklassiker “Jenga!” zur Wissensvermittlung im IT Kontext.

Es übernimmt die Grundidee des Turms (“Produkt”) und des Konstruierens (“Entwicklung”) in den Kontext der Softwareentwicklung.

Durch die haptische Erfahrung und den spielerischen Ansatz bleibt das Gelernte besser haften.

Agile Jenga kann in verschiedenen Varianten gespielt werden. Dieser Artikel stellt eine Variante für “Tester” und “Entwickler” dar.

Disclaimer

Ich beschreibe in diesem Artikel meine praktischen Erfahrungen mit Agile Jenga in Deutsch. Ich habe Agile Jenga nicht erfunden.
Auf weitere englische Blogposts verweise ich unten in der Linksammlung.

Benötigtes Material

• Bauklötze in ausreichender Anzahl, min. 36 Stück
• Optional: Würfel in passenden Farben
• Zettel und Stifte

Vorbereitung

• 36 Bauklötze werden in drei 12er Blöcke aufgeteilt.
• Jeder Block erhält eine Farbe (Rot, Grün oder Blau) zugewiesen.
• Jeder Bauklotz eines Blocks wird mit einer Zahl (1-12) in der Blockfarbe beschrieben.

• Die Bauklötze werden farblich nummeriert.
• Jeder Bauklotz erhält nur eine farbige Zahl.
• Die Zahl wird willkürlich auf eine der sechs Seiten geschrieben.
• Für jede Spielrunde werden Fehlerlisten vorbereitet.
• Jede Fehlerliste enthält vier Zahlen (1-12) pro Farbe.
  (Vier rote, vier grüne, vier blaue)
• Fehlerlisten können ausgedacht oder ausgewürfelt werden.
• Anforderungen ausdenken und auf einen Zettel schreiben. Beispiele: “Der Turm …”
  • … muss 3 Einheiten hoch und 2 Einheiten breit sein.
  • … besteht alle 2 Ebenen nur aus 2 Spielsteinen.
  • … muss wie ein Einhorn aussehen.
  • … eine Kaffeetasse tragen.

Ein farbig nummerierter Turm kann dann so aussehen:

Generelle Spielregeln

1. Es werden Teams (min. 2 Personen) gebildet.
2. Jedes Team erhält einen Satz Bauklötze (… nicht staunen!).
3. Das Team erhält die Anforderungen.
4. Das Team entscheidet, wer “Tester” und wer “Entwickler” ist. Optional: Kann pro Spielrunde rotiert werden.
5. Die Fehlerliste wird nur den Testern bekannt gegeben.
6. Die Bauphase ist zeitlimitiert.
7. Der Turm wird spätestens am Ende der Bauphase anhand der Anforderungen abgenommen.

Erste Spielrunde

Regeln:

• Das Team baut den Turm und muss alle Bausteine nutzen.
• Am Ende der Bauphase wird die Fehlerliste bekannt gegeben.
• Das Team muss die fehlerhaften Bausteine entfernen und zur Seite legen.
• Dann müssen fehlerhafte Bausteine wiederverwendet werden.
• Der Turm muss weiterhin alle Anforderungen erfüllen.

Hintergrund

Diese Spielrunde stellt einen Arbeitsstil dar, der häufig beim Wasserfall, V-Modell oder anderen sequentiellen, separierten Arbeitsmodellen vorherrscht.

Die Tester sind oft erst am Ende der Arbeitskette eingebunden und können das Feedback über Auffälligkeiten erst spät weitergeben.

Mögliche Beobachtungen

Kann das Team die fehlerhaften Bauklötze im fertigen Turm überhaupt sehen und entfernen? Müssen ggf. einige Ebenen oder sogar der komplette Turm auseinandergenommen werden? Was machen die Tester, während die Entwickler bauen?

 

Zweite Spielrunde

Regeln:

• Das Team hat ein paar Minuten Zeit, sich vorzubereiten.
• Alle 12 Bauklötze werden die bestehenden Fehler in diesen 12 Bauklötzen aufgezeigt.
• Ansonsten gelten die Regeln aus der ersten Spielrunde.

Hintergrund

Diese Runde holt  das Feedback dichter an das Konstruieren, es wird schon nach 12 Bauklötzen gegeben, nicht erst nach 36.

Mit der Erfahrung der ersten Runde und den erlebten Schwierigkeiten beim Fehlerbeheben wird wahrscheinlich eine Teamdiskussion in Gang kommen, um den Arbeitsprozess zu verbessern und “Fehlervermeidungsschritte” einzubauen.

Mögliche Beobachtungen

Wie verläuft die Kommunikation im Team? Gibt es selbst-entstehende Muster? Werden die Bauklötze sortiert oder vorbereitet? Wie? Warum?
Übernimmt jemand eine “Rolle” Z.B. als Steine-Sortierer, Steine-Zähler oder andere ? Wird dieses bewusst kommuniziert oder “einfach gemacht”? 

Dritte Spielrunde

Regeln:

• Das Team hat ein paar Minuten Zeit, sich vorzubereiten.
• Wenn der fehlerhafte Block benutzt wird, kann sofort Bescheid gesagt werden.
• Ansonsten gelten die Regeln aus der ersten Spielrunde.

Hintergrund

Diese Runde bietet das früheste Feedback, es zeigt auf, wie eine dichte Zusammenarbeit den Arbeitsablauf positiv beeinflusst und das Konstruieren effizient gestaltet.

Mögliche Beobachtungen

Es wird eventuell ruhiger im Team, das kann ein Zeichen sein, das jeder das Ziel, den Prozess und seine eigene Rolle im Team kennt.

Diese Konzentrationsphase wird auch “flow” oder “zone” genannt. Wenn ein Team so arbeitet, und nicht gestört wird, erreicht es eine hohe Effizienz und Effektivität.

Meta Beobachtungen

Es lassen sich aus diesem spielerischen Ansatz mit Agile Jenga auch weitere Beobachtungen ableiten, die im Kleinen widerspiegeln, was eine selbstbestimmte und -befähigte Arbeitsweise ermöglicht.

Vergleicht man die Teamentwicklung über die Spielrunden, wird man feststellen, dass ein neu zusammengestelltes Team in einen Rhythmus kommt:

• Selbstorganisation fängt an
  • Blöcke werden vorsortiert
  • Blöcke werden anders benutzt (z.B.: Nummern sind immer sichtbar)
  • …
• Einzelne übernehmen feste Tätigkeiten oder Rollen
• Das Team finder einen passenden Arbeitsprozess
• Es wird weniger Kommunikation oder Dokumentation benötigt, die Teilnehmer sind im wahrsten Sinne des Wortes eingespielt
• …

Spielvarianten

Agile Jenga kann mit vielen Varianten und Zielen eingesetzt werden.

Hier eine kurze, unkommentierte Auflistung (wer mehr Varianten kennt oder mehr über eine erfahren will, fragt über die Kommentarfunktion an):

• Wie verändert sich der Zeitraum zum “Fertigstellen” von Spielrunde zu Spielrunde?
• Tester erhalten unterschiedliche Fehlerlisten und dürfen zu unterschiedlichen Zeiten Feedback geben
  (simuliert Separierung von Teststufen oder Testabteilungen)
• Anforderungen können unscharf sein
  (wird erst bei der Abnahmephase festgestellt; Spielleiter kann ab der 2. Spielrunde früher Feedback geben)
• Das Team wird um andere Rollen erweitert (Analyst, Designer, …)
• Die Zeitbox oder andere Faktoren werden willkürlich verändert
  (was passiert mit dem Team bei Störungen; wie wirkt sich das aus)

Wer weitere Lernerfahrungen und Beobachtungen kennt, schreibt mir bitte via Kommentarfeld. Ich nehme es gern auf.

 

Linksammlung

1. http://blog.khangnguyen.me/2016/02/agile-games-jenga-builders.html (Gutes Debriefing)
2. http://anagilemind.net/2014/10/27/agile-jenga/ (Gutes Debriefing)
3. https://nandalankalapalli.wordpress.com/2011/09/15/game-test-small-test-often/
4. http://tastycupcakes.org/2016/03/agile-jenga-testing-game/
5. https://leanpub.com/AgileTesting/read
   (Wird im Buch erwähnt)