Spielerisch gemeinsames Verständnis erlangen

Gerade läuft in Rückersbach wieder die Play 4 Agile Konferenz. Leider schaffe ich es dieses Jahr nicht, dort zu sein, aber ich habe mich heute daran erinnert, was ich 2019 bei meinem letzten Besuch alles mitnehmen konnte. Von einer Methode würde ich euch gerne in diesem Artikel berichten.

 

Damals hatte ich das Spiel Team Work mit dabei und bot eine Open Space Session dazu an.

 

Ziel war herauszufinden, wie man das Spiel mit Teams einsetzen kann, um sie in ihrer Entwicklung weiter voranzubringen. Wie immer bei einem Open Space stieg dann kurz vor der Session die Spannung. Es ist der letzte Slot der Veranstaltung, haben die Leute noch genug Energie? Kommt überhaupt jemand? Zu meiner großen Freude wurden alle Fragen mit „Ja“ beantwortet (Secret Learning: Bei Open Spaces mutig sein, das klappt schon!!).

 

Die Regeln

Zuerst habe ich den Teilnehmern das Spiel vorgestellt. Jede Karte enthält 6 nummerierte Begriffe. Das Tolle an den Karten ist, dass sie auf Deutsch, Englisch, Französisch und Italienisch beschriftet sind. Eine Person, die nicht erklärt und im Team der „Ratenden“ ist, nennt einfach eine Zahl zwischen 1 und 6. Zwei Leute sind für eine Runde das Erklär-Team, ziehen eine Karte und müssen in einem Satz den Begriff mit der genannten Nummer erklären. Dabei darf der Begriff, um den es geht, natürlich nicht selbst verwendet werden. Und damit es nicht ganz so einfach ist, darf jeder immer nur ein Wort sagen während  sein Teammitglied den Satz dann weiter ausformulieren muss.

 

Das Gesellschaftsspiel vergibt Punkte für Erfolg und Misserfolg. Wir haben uns allerdings dagegen entschieden, das Zählen von Punkten in den Mittelpunkt zu rücken. Sobald der Begriff erraten ist, wechselt eine der erklärenden Personen ins andere Team und umgekehrt. Danach geht es von vorne los.

 

Let’s Hack it!

 

Nach ein paar Runden waren die Spielprinzipien klar, und wir haben überlegt, wie wir das Spiel auf unseren Alltag übertragen können. Ausgestattet mit Karteikarten und Stiften haben wir, jeder für sich, ein kurzes Brainstorming gemacht. Es wurden Begriffe notiert, die mit unserer Arbeit als Agilisten zu tun haben.

Für die nächsten Spielrunden waren dies unsere neuen Begriffe. Wir haben wieder eine Weile gespielt, um herauszufinden, wie dies das Spiel verändert.

Der Spaß ist geblieben (ein Glück 😉 ), und wir haben einiges darüber gelernt, dass nicht jeder gleich tickt. Die letzten Minuten der Session haben wir dann genutzt, um unsere Erfahrungen zusammenzutragen und abzuleiten, in welchen Situationen diese Übung eingesetzt werden könnte.

 

Was haben wir gelernt?

 

  • Sowohl das Original als auch die angepasste Variante des Spiels können, je nach Kontext, mit Teams eingesetzt werden.
  • Lasst es passieren, man kann den Satz nicht planen.

     

  • Reagiert auf die Veränderung, die euer Mitspieler in den Satz einbringt.

     

  • Vorgefertigte Karten sind nicht nötig, erstellt sie gemeinsam mit eurem Team.

  • Unterstützt eure Mitspieler, wenn sie feststecken – unterbrecht kurz, macht ein „Daily“ und findet gemeinsam heraus, welches Wort er oder sie gerade braucht.

     

  • Sackgassen sind Anknüpfungspunkte für spätere Diskussionen im Team.

     

  • Nur das gesamte Team sollte Punkte erzielen können (wenn man unbedingt Punkte zählen will). 


Wo kann die Methode eingesetzt werden?

  • In der Opening- oder Closing-Phase einer Retrospektive.

     

  • Als Energizer in Workshops (dann evtl. doch mit vorher geschriebenen Karten, es soll ja schnell gehen).

     

  • Bei kontextspezifischem Brainstorming.

     

  • Beim Klären von Problemen, Missverständnissen bzw. Unklarheiten.

    Ich bin mir sicher, es gibt noch mehr Dinge, die wir in Zukunft durch diese Methode und über ihre Einsatzmöglichkeiten lernen werden. Für eine 45-Minuten-Session bin ich aber mit dem ersten Ergebnis sehr zufrieden und freue mich darauf, die Methode bald in einem Team auszuprobieren. Solltet ihr jetzt angefixt sein und die Methode einsetzen, lasst mich gerne wissen, wie es gelaufen ist und was es mit euch und euren Teams gemacht hat. 

     

     

    Play on!
    Euer Jan

Ihre Ideen erfolgreich ins Unternehmen einbringen mit Fearless Journey

(c) Paul WeberVeränderung ist immer eine Herausforderung. Jeder von uns kennt warscheinlich den Moment, wenn eine gute Idee offensichtlich die passende Lösung für eine Situation ist. „Wir müssten jetzt einfach nur X machen, dann würde Y für uns gar kein Problem mehr darstellen.“

Doch dieses Wissen anderen Menschen zu vermitteln, ist nicht immer leicht. Was für einen selbst so logisch und beinahe selbstverständlich richtig erscheint, ist oft für andere  überhaupt nicht nachvollziehbar. Es gibt andere Sichtweisen, andere Meinungen, andere Ideen. „Das kann so bei uns nicht funktionieren“ oder „es wäre besser, nochmals weitere Optionen zu untersuchen, bevor wir…“ haben Sie vielleicht auch schon einmal gehört?

Doch wie schaffen Sie es, Ihre Idee zum Wohl Ihrer Abteilung und Ihres Unternehmens einzuführen? Wäre es nicht schön, wir könnten die Herausforderung der Veränderung leichter angehen?

Fearless Journey - Jetzt auf DeutschGute Neuigkeiten: Es geht leichter.

Die kostenfreie Simulation „FearlessJourney“, welche nun schon seit 2011 weltweit im Einsatz ist, gibt es nun auch auf Deutsch. Als Training für einen selbst oder (noch viel besser) in der Gruppe entwickeln Sie damit einen Satz von Strategien, wie Sie Ihre Idee am Besten einführen können.

Die im Spiel enthaltenen praxiserprobten 48 Strategien basieren auf dem in der agilen Welt bekannten Buch „Fearless Change“, welches ich – nicht erst nachdem ich Linda Rising persönlich kennenlernen durfte – als Ergänzung zu dem Spiel auch Ihnen gerne empfehle.

Wenn Sie auch Ihre Ideen auf fruchtbaren Boden aussähen wollen, können Sie FearlessJourney (in Deutsch und weiteren Sprachen) jetzt hier herunterladen.

Kommunikationsbrücken

Alexander Groß hat in seinem heutigen Vortrag auf der .NET Usergroup Rhein-Neckar Behaviour Driven Design (BDD) vorgestellt. Dieser als „Test Driven Development done right“ propagierte Ansatz beschäftigt sich mit Anforderungsspezifikationen, die eine Maschine automatisiert validieren kann.

BDD funktioniert, indem menschenleserlich formulierte Anforderungen so niedergeschrieben werden, dass diese von einem so genannten Testrunner ausgeführt werden können. So ergibt sich eine Kommunikationsbrücke zwischen Fachanwender und Entwickler. Man spricht eine gemeinsame Sprache.

Hierzu definiert man bestimmte Phrasen, welche dann nach und nach eine Domänensprache bilden, die zum Testen genutzt werden kann.

Der besondere Charm liegt darin, dass so auch technisch versierten Fachanwendern die Möglichkeit gegeben wird, Spezifikationen zu erstellen, die von Entwicklern ausgeführt werden können. Dabei können je nach Ausprägung des BDD Frameworks auch schon Sprachelemente verwendet werden, die noch kein Entwickler programmiert hat – „Spezifikation zuerst“ sozusagen.

Damit ist an einer definierten Stelle das Verhalten des Systems aus der Businesssicht beschrieben – was für eine tolle Dokumentation für neue Entwickler und die Einarbeitung bei Wartungsfällen. Außerdem hängen dann die Testfälle direkt mit den Anforderungen zusammen.

Darüber hinaus lassen sich diese Spezifikationen jede Nacht automatisch ausführen, wenn man einen Buildserver betreibt. So ist also sichergestellt, dass ungewollte Veränderungen am System früh auffallen. So früh, das Entwickler noch den Kontext ihrer Veränderungen kennen und diese korrigieren können oder mit dem Analysten über das neue gewünschte Verhalten sprechen können.

Wenn Sie also Fachanwender und Entwickler enger miteinander kommunizieren lassen möchten, kann diese Kommunikationsbrücke eine gute Idee für Sie sein.