In jedem Team gibt es:

• Writer (Autoren) - Die Writer entscheiden, was in der Geschichte passieren wird und schreiben das Drehbuch.
• Illustrator - Sie zeichnen die Bilder und müssen mit den Entscheidungen der Writer und Redakteure übereinstimmen.
• Editor (Redakteure)  - Die Editoren entscheiden über das allgemeine Aussehen des Buches, die Gestaltung der Seiten, Grammatik und Kontinuität.

Die Teams müssen soweit auseinander sitzen, wie möglich.
Und los geht’s!

1. Planning (10min)
Die Teams teilen sich die Arbeit auf und verteilen die Rollen (Writer, Illustrator und Editor) untereinander. Sie überlegen sich, wie sie die Erstellung des Kinderbuchs organisieren wollen.

2. Sprint 1 (10min)
Im nächsten Schritt erstellen die Teams einen groben Entwurf.

3. Retro (5min)
Teaminterne Retrospektive
(Besprechung des abgeschlossenen Sprints, Diskussion sowohl über Probleme oder Hindernisse, welche entstanden sind, als auch darüber, was gut lief und beibehalten werden sollte. Hierbei geht es nicht um fachliche Aspekte, sondern die menschliche Zusammenarbeit im Team selbst, was das Teamwork und die Produktivität steigern soll.)

4. Sprint 2 (10min)
Im zweiten Sprint wird die endgültige Fassung des Kinderbuchs erstellt.

5. Demo und Rückblick/Retro 2
Die Teams stellen ihr fertiges Produkt dem Creator vor. Er bewertet, ob die Teams die Anforderungen erfüllt haben und ob ihm das Ergebnis gefällt.

Anschließend können alle Teams über Schwierigkeiten/Erfolge während der Sprints diskutieren.

Lucky Lachs

Lucky Lachs könnt ihr schnell und einfach als kleine Aktivierungsübung einsetzen. Das Spiel ist schnell erklärt und fast genauso schnell gespielt.

Und so funktionierts:

Wer?
3-6 Personen

Wie lange?
10 Minuten

Was brauchen wir?
- das Spiel "Lucky Lachs"

Wie?
Stellt euch im Kreis auf. Jeder Spieler erhält ein Kartenset einer Farbe.
Es gibt vier Aktionen:

• High Five
  
• Checker-Faust
• Tausch Rausch (die Plätze tauschen)
• Lucky Lachs (sich gegenseitig auf den Unterarm klatschen)

Mischt die Karten nochmal durch und haltet sie verdeckt in der Hand. Alle Spieler decken gleichzeitig die oberste Aktionskarte ihres Stapels auf und müssen so schnell wie möglich einen Mitspieler finden, der die gleiche Aktionskarte oben auf seinem Stapel hat, um mit diesem gemeinsam die abgebildete Aktion auszuführen. Kann die Aktion nicht ausgeführt werden, wird die Karte wieder unter den Stapel geschoben. Danach geht es mit der nächsten Karte im Stapel weiter und die „gespielte“ Karte wird einfach auf den Boden geworfen. Ziel ist es, seinen Stapel so schnell wie möglich los zu werden.

Danish Clapping Game

Dieses Bewegungsspiel kann gut als Energizer eingesetzt werden. Ihr könnt den Kreislauf in Schwung bringen, euch vom vorherigen Termin ablenken und eine offene Haltung einnehmen, die zum Beispiel für kreative Aufgaben nützlich ist.

Und so funktioniert's:

Wer?
eine gerade Anzahl an Personen, egal wie viele

Wie lange?
5 Minuten

Was brauchen wir?
- nichts

Wie?
Die Mitspieler finden sich zu zweit zusammen und stellen sich gegenüber. Zuerst klatscht ihr mit beiden Händen auf eure Oberschenkel und streckt anschließend die Arme gerade nach oben. Dann klopft wieder auf die Oberschenkel und bewegt beide Arme nach links. Klopft wieder auf die Oberschenkel und streckt die Arme nach rechts. Klopft noch einmal auf die Oberschenkel und gebt euch ein doppeltes High-Five.

Nun kennt ihr alle Bewegungen des Spiels und schon kann es losgehen.

Klopft alle gleichzeitig auf eure Oberschenke. Als nächstes entscheidet jeder selbst, ob er seine Hände nach oben, rechts oder links bewegt. Haben du und dein Gegenüber dieselbe Bewegung gewählt, gebt euch ein doppeltes High-Five, ansonsten klopft wieder auf die Oberschenkel. Nun wählt eure nächste Bewegung und versucht immer schneller zu werden. Nach 5 Minuten ist das Spiel vorbei.

User Story Tabu

Ziel des Spiels ist es, den Teilnehmern des Workshops zu vermitteln wie gute User Stories geschrieben werden können. Dabei dürfen bestimmte Wörter aber nicht verwendet werden. Den Teilnehmer sollen die Perspektive wechseln, damit sie erkennen, dass Stories wie "Als Server möchte ich ..." nicht zielführend sind. Vielmehr sollen die Teilnehmer lernen, was es bringt, sich Gedanken dazu zu machen, wer bei einer User Story von einer Funktionalität profitiert und warum. Die User Stories werden am Beispiel von Anforderungen für ein erweitertes Schiffe versenken geschrieben. 

Info: Eine User Story, oder Anwendergeschichte, ist eine Anforderung des Kunden an das Produkt, also ein Item aus dem Product Backlog, dass noch bearbeitet werden muss. Die User Stories sind bewusst kurz und knapp gehalten und werden meist in Umgangssprache formuliert. Im Gegensatz zu klassischen Requirements erläutern User Stories auch den Grund, warum etwas getan werden muss. Der Grund oder der Anlass ist für das Team wichtig, um eine passende Lösung zu entwickeln.

Und so funktionierts:

Wer?
4-16 Personen

Wie lange?
60-90 Minuten

Was brauchen wir?
- die Anforderungen, ausgedruckt
- Flipchart

Wie?
Vorbereitung
Die verbotenen Wörter auf ein Flipchart schreiben:

Teilt euch in Gruppen von maximal 4 Personen auf. Jeder Gruppe wird ein Teil der Anforderungen zugewiesen (am besten gleich viele).

Runde 1: User Stories schreiben
Klärt miteinander, dass eine gute User Story beschreibt, wer etwas haben möchte, was er/sie haben möchte und warum er es/sie haben möchte.
Dabei bietet das Template "Als <Rolle> möchte ich <Funktionalität> damit ich <Nutzen> habe" meist eine gute Grundlage.
Nun kann sich jeder die verbotenen Wörter anschauen.

Anschließend werden die User Stories geschrieben, was manchmal 2-3 Iterationen in Anspruch nimmt, bis die User Stories die Anforderungen erfüllen und alle verbotenen Wörter eliminiert sind.

Runde 2: Akzeptanzkriterien erklären.
Info: Ein Akzeptanzkriterium ist eine niedergeschriebene fachliche Anforderung, welche ein Produkt zum Zeitpunkt der Abnahme erfüllen muss.

Jede Gruppe wählt sich nun 2 User Stories aus Runde 1 aus und schreibt hierzu die Akzeptanzkriterien auf (hier dürfen die Teilnehmer auch gerne zusätzlich kreativ sein).

Runde 3: Epics identifizieren.
Die Teilnehmer sollen nun die geschriebenen Stories nach Stories und Epics bewerten.

Info: Epics sind größere Aufgabeneinheiten, die in mehrere kleinere Aufgaben (namens Storys) unterteilt werden können.

Mob is You

Mit Mob is You kann sich euer Team ans Mob-Programming herantasten und ist auch für Nicht-Programmierer geeignet. Die Session kann auch remote stattfinden, wenn ihr ein Video-Konferenztool nutzt, bei dem die Teilnehmer die Kontrolle über Maus und Tastatur bekommen können.

Info:

Beim Mob-Programming geht es um einen Entwicklungsprozess, bei dem das gesamte Team gleichzeitig arbeitet. Am selben Ort und am selben Computer. Im Gegensatz zum Pair-Programming sitzen hier nicht nur zwei Personen, sondern fünf oder mehr Teilnehmer an einem Projekt. Dazu kommt die unterschiedliche Rollenverteilung:

• Es gibt einen einzigen Driver: Die einzige Person mit einer Tastatur und Maus in der Hand ist auch die Person, die den Code ändern darf.

• Jeder andere übernimmt die Rolle des Navigators. Während der Driver mit physischen Aufgaben beschäftigt ist, hat der Navigator die Zeit, die er braucht, um zu denken, zu rezensieren, zu diskutieren und zu beschreiben.

Die Rollen werden nach einer bestimmten Zeit getauscht getauscht. Zum Mob gehören tatsächlich alle Mitglieder des jeweiligen agilen Projektteams – Product Owner, Scrum Master, Entwickler, Designer. Alle nehmen an den Sessions teil, auch wenn sie selbst keine Programmierkenntnisse besitzen.

Und so funktionierts:

Wer?
Dein ganzes Team

Wie lange?
45 Minuten

Was brauchen wir?
- Game: “Baba is you”
- Rollenbeschreibungen von Willem Larsen
- großer Bildschirm
- Tastatur
- Rechner, auf dem das oben genannte Spiel läuft
- Timer

Wie?
Teil 1: Basic Mobbing
Nachdem ihr Setting und Ziele des Spiels geklärt habt, könnt ihr entscheiden, wer mit welcher Rolle starten möchte. Setzt den Timer auf 3 Minuten, startet das Spiel und lasst den Mob rotieren.

Zwischendurch ist Zeit für ein paar situationsabhängige Fragen:

• Warum hat der Driver nicht auf den Navigator gehört? 

• Ist es okay für euch, dass der Navigator die Ideen aus dem Mob komplett ignoriert?

• Warum hat einer aus dem Mob entschieden, was als nächstes gemacht wird und nicht der Navigator? 

• Was wäre, wenn es keinen Navigator gebe und der Mob bestimmt, was der Driver tut? 

• Was könntet ihr tun, damit Navigator/Driver/Mob besser ihre Rolle ausüben können?

Teil 2: Die Rollenkarten
Teilt die Rollenbeschreibungen von Driver, Navigator und Mob von Willem Larsen aus. Nun geht es darum, wie oft man in seiner Rolle genau das getan hat, was laut Rollenbeschreibung auf dem Zettel steht. Das Ankreuzen der eigenen Taten gibt noch einmal einen tieferen Einblick in die Rolle des Drivers, Navigators und Mobs.

Teil 3: Das Debrief
Besprecht die Session nochmal. Was habt ihr mitgenommen? Was habt ihr gelernt?
Folgende Fragen könnten beispielsweise gestellt werden:

• Wärt ihr in diesem Spiel auch so weit gekommen, wenn ihr alleine gespielt hättet? 

• War die Session für jemanden langweilig? 

• Hat sich jemand verloren gefühlt oder ist nicht mitgekommen? Warum bist du nicht komplett ausgestiegen?

• War es schlimm, wenn jemand einen Fehler gemacht hat? Wie habt ihr euch darüber geäußert?

• Wie empfandet ihr den Wechsel zwischen Driver, Navigator und Mob? Hatte es positive Auswirkungen auf das Spiel?  

• Würdet ihr Mob Programming nun auch im daily Business ausprobieren?