Agile Computerspiele

Spiele eignen sich außerordentlich gut um Ideen, Techniken und Praktiken leicht verständlich zu vermitteln. Als ScrumMaster greift man deshalb häufig und gerne auf Rollenspiele, Ballspiele, Kartenspiele, Legospiele, Brettspiele und selbst ausgedachte Spiele zurück, um agiles Gedankengut  zu transportieren. Auf Webseiten wie Tastycupcakes findet man unterschiedliche Variationen dieser Spiele, die zudem nach Themenbereichen unterteilt sind. Was diese Spiele gemeinsam haben ist, dass Software-Entwickler ihre Aufmerksamkeit auf etwas lenken müssen, das nicht ihrem "natürlichen Lebensraum" entspricht und sie oftmals aus ihrer Komfortzone herausreißt. Dagegen ist nichts einzuwenden, ganz im Gegenteil, denn "Lernen" und "Wachstum" passieren immer außerhalb unserer Wohlfühlzonen, was Jan-Hendrik Heuing sehr schön in seinem Blog "Scrum and comfort zones" beschreibt.

Dennoch finde ich, dass man "Komfortzonen" als ScrumMaster unterschiedlich ansprechen kann. Bei Rollenspielen habe ich häufig den Eindruck gewonnen, dass sich Kollegen mehr darauf konzentrieren sich dem Spielrahmen anzupassen, d. h. sich eine neue Rolle auszudenken, sich anders zu verhalten oder mehr dem zu verweigern als Erkenntnisse zu gewinnen, die sie auf ihre Arbeit übertragen können. Deshalb stelle ich mir die Frage, ob der Fokus in der Übung nicht durch die Inszenierung verloren geht. Sehr viel Aufmerksamkeit wird darauf verschwendet, dass man sich über das Spiel ärgert oder sich der Situation entziehen will und damit wenig partizipiert.

Was wäre jedoch, wenn man den Entwicklern ihre Komfortzone lassen und ein Computerspiel als didaktisches Medium nutzen würde? Warum holen wir die Menschen nicht dort ab, wo sie sich wohl fühlen und verlieren dadurch keine Energie auf persönliche Konflikte mit dem Setup der Übung? 

Zocken kann jeder

Zocken ist etwas ganz natürliches für einen Software-Entwickler. Auch wenn sich viele privat nur für Ego-Shooter, Adventure, Taktikspiele oder andere Genres interessieren, haben sich vermutlich die meisten auch an andere Spielarten herangetraut. Damit steigt die Wahrscheinlichkeit, dass sich Entwickler sehr schnell in die Gegebenheiten eines neuen Computerspiels einleben können. 

Sicherlich eignet sich nicht jedes Computerspiel, um agile Konzepte zu vermitteln aber einige gibt es, die es Wert sind gezielt gespielt zu werden. Aus meiner Sicht gehören Besiege und Factorio dazu.

Besiege

Besiege ist ein physikbasiertes Spiel, das von Spiderling Studios entwickelt wurde und seit 2015 am Markt ist. Ziel des Spiels ist es durch eigens zusammengebaute Maschinen - Gebäude, Armeen, Burgen oder Türme - zu zerstören. Mit jedem Level muss eine andere Maschine gebaut werden, die der Mission gerecht wird, z.B. „Zerstöre die Windmühle“ oder „Vernichte 100 Soldaten“. Das bedeutet, dass mit jedem Level sich ein oder mehrere Spieler aufs neue Gedanken machen müssen wie die Maschine beschaffen sein muss, welche Komponenten benötigt werden, was von der bisherigen Bauweise weiterverwendet werden kann und was gänzlich gelöscht werden muss. In jedem Level steigt man in ein neues Experiment ein, das man mehrmals hintereinander auf die Probe stellen kann, um zu sehen ob das ausgearbeitete Design den Anforderungen stand hält und die Maschine das verhalten aufweist, das man sich davon verspricht. Somit testet man unentwegt sein Produkt auf Schwachstellen und verbessert solange bis die Maschine das Ziel zerstört hat.  

Gespielt hat mein Team Besiege in einer Retrospektive zu Beginn 2016. Dafür hat sich das Team in zweier Gruppen aufgeteilt, um die gleichen Missionen durchzuspielen. Drei Fokusthemen der Retrospektive hatten wir zuvor miteinander vereinbart:

  • Sprint Planning 2
  • Pair Programming
  • Refactoring oder Innovation

Die zweier Teams hatten nur wenige Vorgaben:

  • zeichnet die Maschine als Entwurf auf, bevor die Maschine gebaut wird
  • nach je 10 Minuten Spielzeit machen wir eine 5-minütige Retrospektive 
  • nach drei Durchläufen = 30 Minuten Spielzeit übertragen wir die Erkenntnisse aus dem Spiel auf die drei Themenbereiche

Briefing zu Besiege dauerte 3 Minuten (anstatt der geplanten 15 Minuten), denn jeder wusste sofort was zu tun war. Besiege bietet ein kleines Tutorial zum Spiel an, das wir uns zu Beginn gemeinsam angesehen haben. 

Als Scrum Master kann man sehr viele Beobachtungen aus dem Spiel ziehen und einige dieser Fragen schon in den 5-minütigen Zwischenretrospektiven abfragen und auf Post-Its festhalten: 

  • Wie harmonisch arbeiten die zweier Gruppen miteinander?
  • Wie entscheiden sich die Gruppen auf das initiale Design?
  • Wie lange haben die Gruppen benötigt um das initiale Design zu erarbeiten?
  • Wie schwer ist es ihnen gefallen eine Entscheidung zu treffen?
  • Wie schnell haben sie die erste Vorgabe "zeichnet die Maschine als Entwurf auf, bevor die Maschine gebaut wird" verworfen und warum?
  • Wie ist das Verhältnis von Sprechen und Bauen in den zweier Gruppen?
  • Wessen Meinung überwiegt in der Gruppe?
  • Wie häufig verändern die Gruppen die Maschine?
  • Wer neigt zum Over-Engineering?
  • Wer setzt auf ein einfaches Design?
  • Fragen sich die Gruppen gegenseitig um Rat, wenn sie nicht weiter kommen?  

In der anschließenden Gesamtretrospektive habe wir nur einige dieser Fragen gezielt nochmal beleuchtet und unsere üblichen Vorgehensweisen im Sprint Planning 2, beim Pair Programming und hinsichtlich Refactoring dagegen aufgewogen. 

Sprint Planning 2

Für Sprint Planning 2 kamen mehr Erkenntnisse als Folgeschritte heraus:

  • Visualisierung ist notwendig, um Ideen zu übermitteln  
  • Design muss anpassbar sein
  • Entscheidungen waren einfach zu treffen weil das Ziel klar war
  • Realität ist komplizierter als das Spiel

Pair-Programming

Beim Pair-Programming hat das Team sich vorgenommen im nächsten Daily gemeinsam zu entscheiden welche UserStory im Pair-Programming von wem durchgeführt wird. Die darauf folgende Retrospektive soll das Thema nochmal aufnehmen. 

Refactoring oder Innovation

Zu Refactoring oder Innovation gab es die Erkenntnis, dass wir im Team einen Mittelweg finden müssen, um Over-Engineering und Refactoring- bzw. Innovationsgedanken zu kombinieren, da offensichtlich wurde, dass unterschiedliche Vorgehensweisen im Team vorherrschen.

Mein Ziel alle drei Themen zu beleuchten haben wir damit erreicht und einen konkreten nächsten Schritt beim Pair-Programming identifiziert. Die weiteren Themen sind gute Kandidaten für weitere Retrospektiven geworden. 

Die Beteiligung war die gesamte Zeit über sehr hoch und es hat Spaß gemacht über den Vergleich der gebauten Maschinen, den Einfallsreichtum und Denkrichtungen im Team, Visuell darzustellen.

Factorio

Das nächste Spiel, das sich förmlich aufdrängt ist Factorio, das seit 2016 verfügbar ist.

In diesem Strategiespiel baut und pflegt man Fertigungsanlagen, die man fortwährend automatisiert, bis sie sich selbständig versorgen.

Welches Ziel man wohl damit im agilen Umfeld verfolgen könnte ;)

Nadja