TalkAbout

Agile Jenga

Von Maik Nogens
5. Februar 2018

Jenga (hier der Link zum Wikipedia-Artikelist ein Geschicklichkeitsspiel aus dem Jahre 1983. Agile Jenga nutzt den Spieleklassiker zur Wissensvermittlung im IT-Kontext. Es übernimmt die Grundidee des Turms ("Produkt") und des Konstruierens ("Entwicklung") in den Kontext der Software-Entwicklung. 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 Blog meine praktischen Erfahrungen mit Agile Jenga in Deutsch, ich habe Agile Jenga nicht erfunden. Ich verweise auf englische Blogposts unten in der Linksammlung.


 

Benötigtes Material

  • Bauklötze in ausreichender Anzahl, minestens 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 bekommt eine der Farben 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. Hier ein paar Beispiele: "Der Turm ..."

  • ... muss 3 Einheiten hoch und 2 Einheiten breit sein.
  • ... besteht auf jeder zweiten Ebenen nur aus zwei Spielsteinen.
  • ... muss wie ein Einhorn aussehen.
  • ... muss eine Kaffeetasse tragen.

Ein farbig nummerierter Turm kann dann so aussehen:

Agile Jenga: Ein Turm aus Bauklötzen mit nachträglich hinzugefügten Nummern in unterschiedlichen Farben.

 

Allgemeine Spielregeln 

  1. Es werden Teams aus minestens 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 für die erste Runde

Diese Spielrunde stellt einen Arbeitsstil dar, der häufig bei Wasserfall-Projekten, 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 auseinander genommen werden?
  • Was machen die Tester, während die Entwickler bauen?

Zweite Spielrunde

Regeln

  • Das Team hat ein paar Minuten Zeit, sich vorzubereiten.
  • Nach 12 verbauten Klötzen werden die bestehenden Fehler in diesem Bauabschnitt aufgezeigt.
  • Ansonsten gelten die Regeln aus der ersten Spielrunde.

Hintergrund für die zweite Runde

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"? Zum Beispiel als Steine-Sortierer, Steine-Zähler oder anderes? 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 für die dritte Runde

Diese Runde arbeitet mit sehr frühem Feedback. Das zeigt auf, wie eine enge Zusammenarbeit den Arbeitsablauf positiv beeinflussr 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.

Beobachtungen auf der Meta-Ebene

Aus dem spielerischen Ansatz mit Agile Jenga lassen sich 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 und Blöcke werden anders benutzt (Nummern sind immer sichtbar). 
  • Einzelne Team-Mitglieder übernehmen feste Tätigkeiten oder Rollen. 
  • Das Team findet 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. Wenn Sie mehr über eine der genannten Abwandlungen erfahren möchten, fragen Sie gern ü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 Feedback ab der 2. Spielrunde früher 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)

Kennen Sie weitere Varianten? Was sind Ihre Lernerfahrungen und Beobachtungen? Schreiben Sie mir via Kommentarfeld. Ich nehme Ihre Erfahrungen gerne auf.


Linksammlung

  1. Gutes Debriefing auf blog.khangnguyen.me

  2. Gutes Debriefing auf anagilemind.net 

  3. Artikel auf nandalankalapalli.wordpress.com

  4. Artikel auf tastycupcakes.org

  5. Kapitel im Buch Growing Agile

Neuen Kommentar schreiben

Public Comment form

  • Zulässige HTML-Tags: <a> <em> <strong> <cite> <blockquote> <code> <ul> <ol> <li> <dl> <dt> <dd><p><h1><h2><h3>

Plain text

  • Keine HTML-Tags erlaubt.
  • Internet- und E-Mail-Adressen werden automatisch umgewandelt.
  • HTML - Zeilenumbrüche und Absätze werden automatisch erzeugt.

ME Landing Page Question

Erhalten Sie regelmäßig Praxis-Tipps per E-Mail

Praxis-Tipps per E-Mail erhalten