Es gibt bereits viele Spiele zur Verdeutlichung von agiler Vorgehensweise, zum Vermitteln der Grundelemente bspw. von Scrum und zur Visualisierung von Beziehungen in der Team-Arbeit.

Jan Fischbach hat bspw. Ubongo zum Ubongo Flow Game so abgewandelt, dass damit sowohl die Wirkweise von Wasserfall, Kanban als auch Scrum verdeutlicht werden können.

Warum habe ich dann ein neues Spiel entwickelt?

Ich habe in meiner bisherigen Arbeit erfahren, wie wichtig flexible, aber auch präzise Anforderungen sind – und wie selten man diese in der Praxis antrifft.
Außerdem müssen Requirements, User Stories oder andere Beschreibungen des Entwicklungsziels genug Raum lassen, um exzellente Lösungen zu entwickeln.
Wenn die Anforderung so viel vorschreibt, dass damit eine bestimmte Lösung bereits vorgegeben wird, dann würgt das die Kreativität der Entwicklergruppe ab und degradiert bspw. die Software-Entwickler zu Code-Sklaven. Damit ist keinem gedient.

Das dahinterliegende psychologische Phänomen heißt “Narrow Framing”. Es ist erschreckend weit im privaten Alltag und in der Geschäftswelt verbreitet. Für den Erfolg eines Produkts ist “Narrow Framing” nahezu tödlich.

Ich habe intensiv gesucht, ich konnte allerdings kein Spiel finden, was den Zusammenhang zwischen einer guten Aufgabenstellung und der Magie einer echten Team-Lösung wirklichkeitsnah und in kurzer Zeit erfahrbar macht. Darum habe ich dieses Spiel entwickelt.

Was soll dieses Spiel zeigen?

Mit dem Spiel Everyday agile soll das wichtige Zusammenspiel von PO, seinen Anforderungen und der Arbeit der Entwicklungsgruppe verdeutlicht werden. Mit diesem Spiel wird Team-Building im Zeitraffer erlebbar.

Was sind die Einsatzmöglichkeiten?

Durch Everyday agile werden die Prinzipien hinter Scrum erlebbar. Im geschäftlichen Alltag gibt es viele Widrigkeiten, die aber in aller Regel nichts mit dem Kern des Vorgehens zu tun haben. Sie führen üblicherweise dazu, dass Ergebnisse erst nach Wochen oder Monaten sichtbar und nur für einen Teil der Beteiligten persönlich erfahrbar werden. Bis zu diesem Zeitpunkt sind bereits 10.000e €/$/£/¥ … direkter oder indirekter Kosten aufgelaufen. Diese Hürde ist definitiv zu hoch, um einen schnellen Eindruck zugewinnen. Mit diesem Spiel werden die essentiellen Grundlagen innerhalb von etwa 60min erfahrbar.

Wofür eignet sich das Spiel also?

• Vorführung der Wirkung von Scrum innerhalb einer Vortragsveranstaltung oder Messe-Situation
• Als beliebig skalierbarer Workshop-Teil in Trainings. Es können auch mehrere Sprints durchgeführt werden.
• Team-Building in der “Forming” und “Norming”-Phase
• Als Proof-of-Concept für eine geplante Team-Umstrukturierung oder Neu-Zusammensetzung (s. vorheriger Punkt)
• “Assesment-Center” im Einstellungsprozess interner oder externer Entwickler
• Design-Format zur Lösungsfindung (Austausch der Alltags-Szenarien durch “reale” User Stories)
• PO-Training durch Ausarbeitung eigener Szenarien (“Aufgaben”)
• Auflockerung von Backlog-Refinements durch Validierung der Stories im Wege dieses Spiels
• Einfach Spaß haben

Wie geht es denn nun?

In der Urform wird das Scrum-Team (Entwickler und PO) durch unbekannte Personen mit unbekannten Fähigkeiten und unbekanntem Erfahrungs-Hintergrund besetzt. Nur der Spielleiter (“Moderator”, “Scrum Master”) kennt zu Beginn die Regeln und Szenarien.

Das Spiel und sein Ziel werden vorgestellt.

Die Entwicklungsgruppe wird mit Freiwilligen besetzt, ein weiterer Freiwilliger übernimmt die PO-Rolle.
Der Spielleiter übernimmt die Rolle eines Schiedsrichters, der aber auch durch die Kenntnis der Szenarien kleinere Hilfestellungen geben darf und sollte, wenn der Kommunikationsfluss ins Stocken gerät. Wie ein Scrum Master hat er die Aufgabe, die Arbeitsfähigkeit des Scrum Teams zu schaffen, zu beschützen und insgesamt aufrecht zu erhalten.

Der PO gewichtet das vorgefundene Backlog nach Geschäftswert. Das Backlog enthält Szenarien als Aufgaben. Alle Angaben, die zur Lösung erforderlich sind, wurden im Vorfeld erarbeitet und werden im Szenario mitgegeben. Sie sind als wahr zu anzunehmen. Darüber hinaus sind eigene Gedanken und zusätzliche Informationen willkommen, solange sie valide (vom PO bestätigt) sind. Gute Lösungen sind mit den gegebenen Angaben möglich. Exzellente Lösung muss das Team zusammen mit dem PO selbst erarbeiten.

Der PO lobt einen Betrag aus seinem Budget aus. Der Betrag ist die Summe des Geldes, das der PO für die Erfüllung der Aufgabe ausgeben möchte. Nimmt er die Story ab, muss er den Betrag an das Team auszahlen. Möchte er die Lösung darüber hinaus verändert haben, muss er für einen der kommenden Sprints einen weiteren Teil seines Budgets für die Lösung dieser bestimmten Refactoring-Aufgabe aufwenden. Refactoring konkurriert im Geschäftswert mit den übrigen Elementen im Backlog.
Nimmt der PO eine Story nicht ab, weil die Lösung seine Anforderungen nicht erfüllt, dann behält er den Betrag ein. Die Story weist weiterhin den höchsten Geschäftswert auf und muss daher im kommenden Sprint (weiter) bearbeitet werden.

Unmittelbar nach der Auslobung des Preises für die Lösung der Aufgabe beginnt die Lösungsentwicklung.

15 Minuten für die Lösungsentwicklung sind wünschenswert, 30 Minuten das Maximum. 20 Minuten sind im ersten Durchgang mit komplett unbekannten Teilnehmern möglich.

Danach folgt Review: Präsentation der Aufgabe und Abnahme durch den PO.

Die Iteration wird abgeschlossen durch eine Retrospektive. Das Minimum sind 5 Minuten. In Trainings und bei abgeschlossenen Teilnehmergruppen sollte sie etwa 10 Minuten umfassen und in jedem Fall vor einer Pause durchgeführt werden. Mehr als 15 Minuten sollte die Retro nicht dauern. Das würde dann als “zu lang” empfunden werden.

Potential zur Skalierung

Je nach Zeitrahmen (“Timebox”) können mehrere Aufgaben (“Stories”) durch das Team bearbeitet werden. Spätestens nach zwei Sprints wird das Team das Bedürfnis verspüren entweder die Sprintlänge anzupassen oder die Anzahl der Aufgaqben zu erhöhen (Beginn der “Performing”-Phase). Aufgrund des bereits stark komprimierten Formats ist eine Verkürzung auf minimal 15 Minuten (1 Aufgabe) oder maximal 30 Minuten (2 Aufgaben) ratsam. Wenn die verfügbare Zeit zu gering wird, werden Team-Building-Prozesse zu stark und dadurch teilweise oder ganz beschnitten.
Leben braucht Raum!

Erfahrungsberichte

Die ersten “Trockenläufe” erfolgten in Gesprächen mit agile Coaches und Scrum Mastern. Das Feedback war ermutigend.

Die Premiere erfolgte dann auf dem freiraum.camp 2016. Der Erfahrungsbericht liegt hier.

Wie komme ich an das Spiel?

Derzeit befindet sich das Spiel am Ende der Entwicklungsphase. Es wird durch Beta-Tests überprüft, weiter ausgearbeitet und verfeinert. Zu diesem Zeitpunkt führe ich es persönlich durch oder stelle es Interessierten zur Verfügung. Bedingung ist, Rückmeldung zu geben und damit den Wert zu bestätigen oder zu verbessern.

Interessiert? Bitte Kontakt aufnehmen.