Nachdem wir uns bereits ausgiebig mit Spielen zu Scrum und Kanban ausgetauscht haben, geht es im dritten, und vorerst letzten Teil zu agilen Spielen um Spiele, die allgemein die agile Arbeits- und Denkweise vermitteln.
Links
- Ball Point Game: https://borisgloger.com/wp-content/uploads/2016/08/Ball_Point_Game.pdf
- Traditional vs. Agile Way of Managing Work: http://tastycupcakes.org/2016/05/5668/
- User Story Tabu: https://github.com/djungowski/user-story-taboo
- Agile Mindset Exercise: http://tastycupcakes.org/2016/06/the-agile-mindset-workshop/
- Product Owner Challenge: http://product-owner-challenge-game.weebly.com/the-game.html
- Story Mapping Game: http://www.barryovereem.com/the-user-story-mapping-game/
Links (Ressourcen)
- Tasty Cupcakes: http://tastycupcakes.org/
- Gamestorming (Dave Gray, Sunni Brown, James Macanufo): https://www.amazon.de/Gamestorming-Praxisbuch-Querdenker-Moderatoren-Innovatoren/dp/3897213265 (Affiliate Link)
- Training from the Back of the Room (Sharon L. Bowman): https://www.amazon.de/Training-Back-Room-Aside-Learn-ebook/dp/B0062O7L7S (Affiliate Link)
@Sebastian Zum Thema ”Story Mapping Game“:
Ich finde das Spiel grundsätzlich sehr hilfreich, um das Thema Story Mapping greifbar zu machen. Ich habe es schon einige Male verwendet und gute Erfahrungen gemacht:
* Das Verständnis für die Systematik von Story Maps lässt sich damit sehr gut erlebbar machen.
* Es funktioniert sowohl mit wenigen Beteiligten, als auch mit mehreren. Erfahrungsgemäß sollte man allerdings dafür sorgen, dass bei mehreren Beteiligten nicht jeder 20 Post-It’s schreibt, da es sonst sehr redundant, unübersichtlich und lang werden kann.
* Einmal habe ich es in einem halbtägigen Workshop angewendet, was dazu geführt hat, dass wir zu viel Zeit verloren haben. Wenn die Zeit knapp ist, reicht es meiner Erfahrung nach, das Spiel einfach mündlich zu beschreiben. Das Verständnis ist dann sicher nicht ganz so tief, die Methode wird anhand dessen aber trotzdem schnell verstanden. Wichtig ist eben auf die verschiedenen Szenarien (Stunde Zeit um das Haus zu verlassen vs. 5 Minuten etc.) und die damit verbundenen Auswirkungen einzugehen.
Interessant, dass du das Problem der Variabilität bei der Priorisierung ansprichst. Das ist aus meiner Sicht nämlich eins der größten Aha-Effekte, auf die ich immer versuche hinauszukommen. Wenn man in die Story Map nämlich Zielgruppen mit aufnimmt, kann man genau an den Stellen wo Priorisierungsprobleme auftreten, à la „ich hab keine Kinder, deine Kinder interessieren mich nicht“ sehr schön aufgreifen: aha, für wen ist das Produkt denn primär? Sprechen wir mal wieder „alle“ an? Was wäre, wenn wir die Eltern aus der Gleichung erst mal rausstreichen? Dann fällt gleich eine Menge Aufwand weg und wir kommen schneller zum Ziel.
Ich spiele das Spiel meistens mit „mein Weg zur Arbeit“ oder „wie fand der heutige Tag bis jetzt statt“. Ich muss bspw. erst mal mit dem Bus zum Zug, dann mit dem Zug nach Köln, um dann mit dem Fahrrad die letzten Kilometer zu machen. Wenn man „Pendler“ weglässt, fällt gleich sehr viel Aufwand weg und man kann ein fokussierteres Produkt entstehen lassen. In einem späteren Release können dann weitere Zielgruppen mit einbezogen werden.
Auch sehr hilfreich beim Sammeln von Stories sind Fragen wie „was ist denn an Sonntagen?“ oder dergleichen. Damit lassen sich noch mehr Ideen für einen Tag generieren. So erhöht man absichtlich die Variabilität, um in die Breite zu gehen. Durch die schon besprochenen Methoden kann man das dann aber wieder gut eindampfen und priorisieren.
Der Witz ist dann natürlich das Ganze auch wieder auf die Produktebene zu übertragen. Beispiel: „Was wenn wir unser Produkt im mobilen Kontext denken?“.
Das Spiel mit diesen ganzen Ausprägungen wird im Buch „User Story Mapping“ von Jeff Patton sehr gut beschrieben.
Vielen Dank für die mal wieder sehr spannende Folge. Macht weiter so!
Schöne Grüße aus der Eifel
Mark
Bezüglich des Spiels „Traditional vs. Agile Way of Managing“. Es klingt so als wäre es genau das richtige um mein Team aus deren Silos rauszuholen. Eine kleine Sache hinkt jedoch bei dem Spiel. Ich kann mir jetzt schon das Argument der Leute vorstellen das das Spiel nicht auf die richtige Entwicklung Übertragbar ist denn jeder der Entwickler kann in etwa gleich gut schneiden und malen. Somit geht die Einarbeitung des Malers wenn er schneiden soll doch gegen null und die Qualität ist mit der des Schneiders vergleichbar. Im Vergleich dazu sind die Silos z.B. zwischen HW-Entwickler und SW-Entwickler viel höher. Um das Spiel realitätsnäher zu machen habe ich mir folgendes überlegt:
Wenn ein Spieler einem anderen hilft und dabei seine Fachkompetenz verlässt, muss er das mit seiner “ schwachen“ Hand machen, also mit links. Dadurch wird der Maler beim schneiden deutlich mehr BUGs produzieren oder viel langsamer zum Ziel kommen als der Schneider. Der Schneider muss sich auch gut anstrengen beim Malen mit links nicht über die Linien zu malen.
Ich freue mich schon darauf wenn ich das Spiel in meinem Team spielen darf und hoffe dass meine ausgedachte Änderung den Aha-Effekt des Spiels nicht zerstört.
Gruß Sergej
Aus Mittelhessen