Lego®+Scrum, dein nächster Workshop?

Teile diesen Beitrag mit deinen Freunden!

Was ist besser als ein Scrum Workshop? Ein Scrum Workshop, bei dem etwas gebaut wird. Einen Eindruck von Scrum kann man am besten bekommen, wenn man einfach mal einen Sprint-Zyklus erlebt hat und durch die einzelnen Events und Phasen durchgegangen ist. Ein Scrum Workshop, bei dem wirklich etwas gebaut wird, kann in einer spielerischen Weise die agile Software-Entwicklung mit dem Scrum-Framework für die Teilnehmer erlebbar machen.

Weil echte Software-Entwicklung den Zeitrahmen für einen Workshop sprengen würde, sollte ein Artefakt auf andere Weise entstehen. Es sollte innerhalb von kurzer Zeit von allen Teilnehmern erstellt werden können, die Möglichkeit der Teamarbeit bieten und von seiner Beschaffenheit einen iterativen und inkrementellen Entwicklungsansatz unterstützen. Refaktoring sollte ohne hohe Aufwände möglich sein. Außerdem sollte bewusst eine ausreichend große Distanz zur täglichen Entwicklungsarbeit entstehen, um Raum für „Aha“-Erlebnisse zu schaffen.

Verwenden wir doch die allseits bekannten Lego®-Steine um zu bauen! Mit meiner Kollegin Wiebke Gercken habe ich einen solchen Workshop konzipiert und erfolgreich durchgeführt. Diese Idee ist nicht neu und auch nicht von uns ersonnen worden[1], erfreut sich aber bei uns wachsender Beliebtheit und eignet sich gut, um Frontal-Unterricht mit aktiven Phasen in einem übergreifenden Scrum-Workshop zu kombinieren. Die abschließende Nachbesprechung (Debriefing) mit den Erfahrungen der Teilnehmer in dem so einfachen Lego®-Umfeld kann das Erkennen von Problemen, typischen Verhaltensweisen und Unzulänglichkeiten der Scrum-Implementierung in der täglichen Software-Entwicklungsarbeit deutlich machen[2].

In der kompakten Version können 2 Sprints innerhalb von 60 min durchlaufen werden, dass ist aber dann aber schon stressig für manche Teilnehmer. Besser ist es, eine halbe Stunde mehr einzuplanen, dann kann noch ein Debriefing durchgeführt werden. Üblicherweise gibt es viele Dinge, über die die Teilnehmer reden wollen, da die Erfahrungen der vorangegangenen Stunde intensiv waren.

Für uns war wichtig, dass wir eine reale Spielumgebung schaffen. In unseren Workshops nehmen wir Trainer die Rolle als Product Owner ein und stellen unsere Product Vision vor.

Die Produkt-Vision


Die Lego-Bausätze, welche heute angeboten werden, sind aus oftmals aus speziellen Bausteinen aufgebaut, um möglichst vorbildgetreue Bauten erstellen zu können (z.B. StarWars® Raumschiffe). Wir möchten aber mit unserem Startup Unternehmen einen Bausatz anbieten, der die Kreativität der Kinder (wieder) mehr fördert und mit Standard-Bausteinen auskommt. Welche Bausteine und in welcher Menge ein solcher Bausatz enthalten soll, wissen wir nicht. Auf einer Spielwarenmesse möchten wir unseren Bausatz präsentieren. Das DevTeam hat nun den Auftrag alle Bausteine zu bestimmen, die der Bausatz enthalten sollte, um eine Stadt bauen zu können. Der Bausatz sollte die Möglichkeit für eine Schule, einen Bahnhof, einige Häuser und einen Spielplatz haben.

Der initiale Backlog

Unser Backlog besteht aus User Storys, die z.B. lauten

  • Als Spieler möchte ich eine Brücke haben, damit meine Figur in die Nordstadt kommen kann.
  • Als Spieler möchte ich einen Bahnhof haben, damit meine Figur mit dem Zug an- und abreisen kann.
  • Als Spieler möchte ich einen Kindergarten im Stadtzentrum haben, damit meine Figur keine langen Wege gehen muss.
  • Als Spieler möchte ich einen Spielplatz haben, damit meine Figuren dort spielen können.

 

Der Ablauf

Zu Beginn stellen wir die Produkt-Vision vor und erläutern kurz, welche Aktivitäten in den einzelnen Phasen durchgeführt werden. Wir bringen für jedes Team einen identischen Bogen Flipchart Papier mit, auf welchem ein Fluss und der Teil einer Eisenbahn-Strecke eingezeichnet sind. Das ist unser „Abnahme-System“.

Bei mehreren ScrumTeams teilen wir uns als Trainer auf und gehen nun als deren Product Owner zum DevTeam und präsentieren unserer Backlog. Von da an arbeitet jedes Scrum Team mit seinem Product Owner für sich. Es werden dann zwei Sprints durchlaufen und zum Abschluss schauen wir auf die Entwicklung der Velocity je Team. Wir als ProductOwner prognostizieren dann, wann die Version 1.0 unseres Bausatzes fertig sein könnte.

 

 

 

Einige Stimmen aus einem Workshop:

„Super coole Idee, Scrum näher zu bringen“

„Erwartungen wurden komplett erfüllt, sogar übertroffen“

„Session hat mir gefallen, war aber sehr hektisch (…). Eine Stunde ist eventuell zu wenig.“

„Meine Erwartungen wurden voll erfüllt, super für die knappe Zeit“

„Fand es sehr gut, dass so einfache Bauten gefordert wurden. Lego Vorkenntnis ist nicht erforderlich“

 

Impressionen
Im Sprint
Schulgebäude
Das Abnahmesystem
Eine Fußgängerbrücke
Ein Spielplatz
Im Sprint
Review
Im Sprint

 

Je nach Situation können die ScrumTeams durch das Einstreuen von Impediments herausgefordert werden. Jetzt müssen sie zeigen, wie sie mit besonderen Situationen umgehen und schnell wieder in einen Arbeitsrhythmus zurückfinden können. Hier können sich die Spielleiter austoben, z.B.

  • Der P.O. erklärt, dass kleine Steine zu gefährlich für Kindergartenkinder sind. Daher müssen alle 1x1er (und 1x2er) Steine entfernt werden
  • Ein Team-Mitglied fällt aus
  • Erkenntnisse aus einem Usability-Test müssen berücksichtigt werden

 


[1] Alexey Krivitsky wird auf der Seite https://www.lego4scrum.com/ als Erfinder von Scrum4Lego im Jahr 2009 angegeben. Auch ein Guide kann heruntergeladen werden.

[2] Z.B. Entstehender Klärungsbedarf während des Sprints; Fehlende Zusammenarbeit mit dem P.O.; Arbeiten an der „Goldkante“; mangelnde Zusammenarbeit; zu viele Storys in WORK, nichts in DONE; um einige zu nennen.

Teile diesen Beitrag mit deinen Freunden!

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind markiert *