Neues aus dem magischen Labyrinth

9 neue Erkenntnisse für agile Teams mit Magic Maze

Dieser Artikel ist Ursprünglich im Januar 2020 erschienen.

Magic Maze für agile Teams -Was bisher geschah…

In meinem letzten Artikel zu Magic Maze hatte ich die uns bis dato 9 bekannten Erkenntnisse zusammengefasst und mit euch geteilt. Seitdem ist natürlich nicht Schluss gewesen. Ich selbst hatte bei Kunden mehrfach die Gelegenheit Magic Maze einzusetzen und zusammen mit meinem

Kollegen Veit sowie Stefan Zumbrägel beim Global Scrum Gathering in Wien eine Open Space Session zu Magic Maze zu hosten.
Mein Highlight bezüglich Magic Maze dieses Jahr war allerdings ein Certified Scrum Master Training mit Björn Jensen . Ich war als Co- Trainer mit dabei und konnte mit den Teilnehmern recht früh am ersten Tag eine Runde Magic Maze

Neun neue Erkenntnisse für agile Teams mit Magic Maze spielen, um sie für agiles Arbeiten zu sensibilisieren. Das hat nicht nur sehr viel Spaß gemacht, sondern auch noch richtig gut funktioniert. An dieser Stelle nochmal „Danke an Björn“ für diese tolle Gelegenheit und das Vertrauen!

Aber warum erzähle ich euch das alles? Es gab natürlich neue Erkenntnisse, insgesamt 9 neue Erkenntnisse für agile Teams mit Magic Maze. Und genau das treibt mich an, Magic Maze weiter mit Teams und in Trainings einzusetzen. Ich werde die bisher bekannten Erkenntnisse nicht nochmal hier zusammenfassen, dafür bitte den oben verlinkten Artikel lesen.

Feedback aus der Community

Kurz nach dem letzten Beitrag kam schon der erste Kommentar von Abigail Leijten , in dem sie zwei Erkenntnisse geteilt hat.

„Mut: es gehört Mut dazu, am Anfang dich als erste am Tisch zu setzen, wo du gar nicht genau weißt, was passieren wird.“
Das kann ich bestätigen, ich habe mehrfach größere Gruppen gehabt, bei denen wir auch die Rolle des Beobachters hatten und sich der Tisch somit erst zögerlich gefüllt hat. Das kann man in Retrospektiven auch oft beobachten. Man bittet das Team Beobachtungen zu teilen und es dauert eine Weile, bis sich der Erste traut oder freiwillig spricht. Sowohl im Spiel, als auch in der Retro, passiert aber nichts Schlimmes, wenn man die Initiative ergreift. Schönes Thema über das man im Debrief sprechen kann.

„Als Teil des „Agiles Mindset“ ist auch ein Satz „Jeder hat seine eigene Geschwindigkeit“. Wir hatten den Fall, wo manche Leute 3 Runden gebraucht haben, bevor sie den Teleporter komplett verstanden haben. Auch das war für die Gruppe ein schönes Learning.“ Das ist eine weitere tolle Erkenntnis, wie ich finde. Mir fällt das auch oft auf. Ich interpretiere da auch rein, dass man Leute nicht mit Informationen überladen und erwarten kann, dass es alle sofort verstanden haben. Man kann das Spiel noch so oft und ausführlich erklären – erst wenn es los geht, merkt man, ob es wirklich verstanden wurde.

Vielen Dank Abigail, dass du diese tollen Impuls mit uns geteilt hast!

Was wir neues gelernt haben

Ich knüpfe gleich an. Ich würde noch einen Schritt weitergehen und die Erkenntnis ziehen „einfach mal Machen“. Bei der Produktentwicklung wissen wir nicht, ob wir das Richtige bauen, bis wir den Kunden um Feedback bitten. So geht es mir als Facilitator des Spiels auch oft. Ob die Spieler meine Anweisungen verstanden haben, sehe ich erst, wenn sie es spielen. Und bisher hatte es keine Gruppe zu 100% verstanden. Das konnte dann aber schnell angepasst werden im Spiel. Ich weiß nicht, wie viel Zeit es gekostet hätte, um die Missverständnisse beim Erklären auszuschließen bzw. ich glaube es ist nicht möglich. Also Erkenntnis bzw. Parallele zu agilem Arbeiten, einfach mal machen und Feedback einholen!

Es gilt die Prime directive (von Norman L. Kerth). „Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.“ Übersetzt: „Unabhängig davon, was wir entdecken werden, verstehen und glauben wir aufrichtig, dass jeder sein Bestes in der gegebenen Situation mit dem verfügbaren Wissen, den Ressourcen und unseren individuellen Fähigkeiten getan hat.“ Wie sehr diese Haltung hilft, erkennt man bei Magic Maze in den Phasen, in denen gesprochen werden kann. Ist das erste Fingerpointing vorbei, haben die Teams in der Regel verstanden, was ihnen weiterhilft ihr Ziel zu erreichen und was nicht. Fingerpointing hilft nie! So ist es auch in Retrospektiven. Nicht umsonst ist die Prime directive dort so wichtig. Dieser Punkt baut ebenfalls sehr schön auf den Punkten 11 und 12 auf, wie ich finde.

Läuft man bei Magic Maze ein Feld zu weit, kann man diesen Fehler selbst nicht korrigieren. Man braucht Hilfe aus dem Team. Diese Erkentiss hat dazu geführt, dass die Runde gemerkt hat, dass es auch im Alltag OK ist, um Hilfe zu bitten, wenn man sich in eine Sackgasse manövriert hat. Denn man bedenke Punkt 13, es gilt die Prime directive; man hat es ja nicht absichtlich gemacht.

Der letzte Punkt aus meinem vorherigen Artikel bezog sich darauf, dass man durch lange Planung am Anfang nicht besser vorhersagen kann, wie sich das Labyrinth aufbauen wird. Ein Team hat dies noch um die Aussage „eine Schätzung am Anfang wäre sehr sehr ungenau“ ergänzt. Das Team weiß, dass es alle Mittel hat, um die Aufgabe zu lösen, aber es hätte sich nicht gut gefühlt eine feingranulare Schätzung abzugeben. Sicher ein tolles Learning für Personen außerhalb eines Entwicklungsteams. Nehmt den Punkt gerne gezielt mit ins Debrief, wenn ihr im Alltag Probleme mit den Ansprüchen an Schätzungen habt.

In den Phasen auf der Sanduhr wird immer fleißig gesprochen und geplant. Doch dann kommt oft alles anders. Das führte zu der Erkenntnis, dass eine gemeinsame Sprache und gemeinsames Wording nicht selbstverständlich sind. Auch das ist bei Scrum oft zu beobachten. Daher führe ich sehr gerne Grundlagentrainings mit neuen Teams durch, um die verschiedenen Taxonomien ans Licht zu bringen und eine gemeinsame zu verankern.

Der „Tu was Stein“ kann von jedem Spieler genutzt werden, um einem andren Spieler zu signalisieren, dass er etwas tun kann, das dem Team weiterhilft. Im Spiel passiert das sehr natürlich und unverzüglich, sobald eine solche Situation erkannt wird. Die Analogie zu Scrum ist das Impediment. Ein Spieler hält unwissentlich den Betrieb auf. Es ist total OK und auch wichtig, dies sofort anzusprechen. Im Spiel passiert das von alleine. Warum sollte das also im Alltag nicht ebenso selbstverständlich werden?

Ich schließe mit einem für mich schönsten Sätze in einem Debrief, der auch keiner weiteren Erklärung bedarf „Das Spiel hat aus Fremden innerhalb kürzester Zeit ein Team gemacht“

Viel Spaß beim Ausprobieren und Danke fürs Lesen!