LeSS Simulation: Create a City Guide
LeSS Simulation: Create a City Guide
Die LeSS-Simulation zur Erstellung eines Stadtführers ist eine interaktive, praxisnahe Aktivität, die Teilnehmer in die Dynamik mehrerer Teams eintauchen lässt, die gemeinsam an einem einzigen Produkt arbeiten. Als Weiterentwicklung der Nexus Zoo-Simulation verlagert diese Übung den Fokus auf ein praktisches und nachvollziehbares Projekt: die Erstellung eines Stadtführers für die Stadt, in der das Training stattfindet. Sie führt typische Ereignisse von LeSS-Einführungen ein, wie den Workshop zur Selbstorganisation von Teams und das Multi-Team-Refinement, um den Teilnehmern die Besonderheiten von LeSS (Large-Scale Scrum) näherzubringen und sie mit traditionellem Scrum zu vergleichen.
Die Simulation beleuchtet die Komplexitäten und Herausforderungen der Skalierung von Scrum und bietet den Teilnehmern wertvolle Einblicke in Teamarbeit, Produktintegration und systemische Verbesserungen.
Warum die Stadtführer-Simulation?
Diese Aktivität spiegelt reale Herausforderungen wider, indem die Teilnehmer ein greifbares Produkt mit Kundenwert erstellen. Sie wird normalerweise vor der formellen Einführung von LeSS-Events durchgeführt, um den Teilnehmern ein besseres Verständnis dafür zu vermitteln, wie sich LeSS von Scrum unterscheidet, und ein tieferes Lernen zu fördern.
Benötigte Materialien
- Farbige Punktaufkleber in 4 Farben (z.B.: grün, rot, blau, gelb)
- Große Haftnotizen
- Farbige A4-Papiere
- Stifte und Marker
- Transparenter Ordner und Locher
- Stoppuhr oder Timer
Simulationsschritte
1. Übung zur Teams-Zusammensetzung (Self-Designing Team Workshop)
Die Simulation beginnt mit einer Übung, in dem die Teilnehmer ihre eigenen Teams bilden. Farbige Punkte repräsentieren dabei wichtige Fähigkeiten:
- Grün: Kenntnis der Stadt
- Rot: Kann zeichnen
- Blau: Schöne Handschrift
- Gelb: Hat die Tripadvisor App
Die Teilnehmer wählen Punkte entsprechend ihrer Fähigkeiten aus, die sie auf ihrem Namensschild sichtbar machen. Anschließend werden Teams aus 4-5 Mitgliedern durch selbst-organisation so gebildet, dass in jedem Team alle Fähigkeiten vertreten sind.
2. Multi-Team-Product-Backlog-Refinement
Der Product Owner (PO), in der Regel der Trainer oder Co-Trainer, präsentiert das Produktziel: einen lokalen Stadtführer in DIN A4 Papierform erstellen und so schnell wie möglich Feedback dazu einholen.
Ursprüngliche Backlog-Elemente:
- Titelseite
- Sehenswerte Attraktionen
- Museen
- Restaurants
- Versteckte Schätze
- Aktuelle Veranstaltungen
Die Teilnehmer refinen die Elemente in gemischten Gruppen über die Teams hinweg. Jede Gruppe erstellt:
- Eine vorgeschlagene Liste (z. B. die Top-5-Attraktionen)
- Ein Seitenlayout (z. B. Zeichnungen, Karten oder Textanordnung)
Nach einer zeitlich begrenzten Refinement-Sitzung gehen alle Teilnehmer durch den Raum, und jede Gruppe präsentiert ihre Arbeit. Eine zweite Refinement-Soitzung kann folgen, um weitere Details hinzuzufügen. Alternativ kann eine Person bei einer Station bleiben, während die anderen Teilnehmer der Gruppe die Arbeit an einem anderen Whiteboard fortsetzen.
Am Ende des Multi-Team-Refinements sammelt der PO die Haftnotizen mit den interessantesten Elementen (z. B. Sehenswerte Attraktionen, Museen), um das Product Backlog zu aktualisieren.
3. Definition of Done (DoD)
Der PO definiert die "Definition of Done", die Folgendes umfasst:
- Eine Seite pro Element (Attraktion, Museum, etc.)
- Keine zwei aufeinanderfolgenden Seiten in derselben Farbe
- Ein integriertes Gesamtprodukt
- Ein gemeinsames Copyright unten mittig auf jeder Seite
- Klare Handschrift und fehlerfreie Grammatik
4. Sprint Planning
Während der Sprint-Planung stellt der PO die obersten Backlog-Elemente nacheinander in einer bestimmten Reihenfolge vor. Für jedes Element fragt der PO, welches Team die Verantwortung übernehmen möchte. Sobald sich ein Team freiwillig für ein Element meldet, geht der PO zum nächsten über. Dieser Prozess stellt sicher, dass die Elemente in der Reihenfolge der Priorität übernommen werden, wobei die verbleibenden Kapazitäten der Teams berücksichtigt werden. Die Liste könnte wie folgt aussehen:
- Titelseite
- Sehenswerte Attraktion 1
- Sehenswerte Attraktion 2
- Museum 1
- Museum 2
- Sehenswerte Attraktion 3
- Museum 3
5. Der Sprint
Mit einem sichtbaren Timer arbeiten die Teams daran, ein Inkrement zu erstellen, das der Definition of Done entspricht. Der PO gibt Feedback und beantwortet Fragen, greift jedoch nicht direkt ein.
6. Sprint Review
Wenn der Sprint endet, findet direkt im Anschluss das Sprint Review statt, während dessen die abgeschlossene Arbeit begutachtet wird. Der Trainer stellt einen Timer, um das Sprint Review knapp und präzise zu halten.
7. Retrospektiven
Nach dem Sprint Review hält jedes Team eine Team-Retrospektive ab, um zu besprechen, was gut gelaufen ist und was verbessert werden könnte. Anschließend nimmt die gesamte Gruppe, einschließlich des Product Owners, an einer Übergreifenden Retrospektive teil. Diese Retrospektive konzentriert sich auf systemische Verbesserungen für die nächste Iteration.
Häufige Herausforderungen und Lernmöglichkeiten
Die Simulation zeigt typische Herausforderungen in Umgebungen wo mehrere Teams zusammen ein Produkt entwickeln und bietet wertvolle Lernmöglichkeiten für die Teilnehmer:
- Unzureichende PO-Interaktion: Teams fragen den PO oft nicht nach wichtigen Details zum Produkt, z. B. dem Titel des Stadtführers oder dem Copyright. In LeSS (wie in Scrum) ist der PO dafür verantwortlich, den Wert des Produkts zu maximieren und das Team in Produktentscheidungen einzubeziehen, während er die Autorität über Schlüsselentscheidungen behält.
- Fehlende Integration: Teilnehmer übersehen oft die Werkzeuge für die Integration von Seiten (z. B. Locher und Ordner) und präsentieren normalerweise nur einzelne Seiten. In LeSS ist es wichtig, ein integriertes Produkt zu haben, das am Ende des Sprints an Stakeholder (z. B. Kunden) übergeben wird.
- Verzögerte Integration: Teams integrieren ihre Seiten oft erst am Ende des Sprints, anstatt sie kontinuierlich zu integrieren. In LeSS wird kontinuierliche Integration gefördert, um Last-Minute-Probleme zu vermeiden und durch Beobachtung der Inhalten von anderen Teams zu lernen.
- Schlechte Kommunikation zwischen Teams: Teams haben oft Schwierigkeiten, sich über Elemente abzustimmen, die auf allen Seiten einheitlich sein sollten (z. B. Copyright). Dies unterstreicht die Bedeutung direkter Kommunikation und Zusammenarbeit in Echtzeit.
- Unfertige Arbeit: Wenn Seiten am Ende des Sprints unvollständig sind (z. B. unvollendete Zeichnungen), kann der PO diese Elemente dem Backlog für die nächste Iteration hinzufügen.
Schritt 8: Nachbesprechung und Schlüsselerkenntnisse
Die Simulation umfasst normalerweise mindestens eine weitere Iteration, um den Teams zu ermöglichen, ihre Verbesserungsstrategien und Erkenntnisse anzuwenden. Am Ende der Simulation findet eine Nachbesprechung statt, um die wichtigsten Erkenntnisse hervorzuheben. Typische Fragen sind:
- Welche Unterschiede sehen die Teilnehmer zwischen Scrum und der Arbeitsweise in der Simulation (LeSS)?
- Was hat in Bezug auf die Kommunikation zwischen den Teams gut funktioniert? Welche Herausforderungen gab es bei der Abstimmung zwischen den Teams? Wie hat man für Konsistenz zwischen den verschiedenen Seiten gesorgt?
- Welche Hauptprobleme gab es bei der verzögerten Integration, und wie hätten diese gemindert werden können?
Vorgeschlagene Zeitpläne
- Multi-Team-PBR: 8 Minuten
- Sprint: 10 Minuten
- Sprint-Review: 3 Minuten
- Team-Retrospektive: 3 Minuten
- Andere Events: Flexibel, jedoch sollte sichergestellt werden, dass genügend Zeit für sinnvolle Diskussionen bleibt, ohne den Zeitplan zu überziehen.
Moderationstipps
- Multi-Team-PBR: Der PO sollte ein Element nach dem anderen anbieten (ein Element für eine Gruppe von 3-4 Personen). Teams, die an ihren Tischen sitzen, sollten entscheiden, wie sie sich in verschiedene Refinement-Gruppen aufteilen. Während des Refinements sollte der PO zur Verfügung stellen Fragen zu beantworten, sich dabei jedoch nicht zu sehr in Details einmischen.
- Um dem PO das Erstellen des Backlogs am Ende des PBR zu erleichtern, sollten große Haftnotizen verteilt und die Teams gebeten werden, diese für die vorgeschlagenen Attraktionen, Museen usw. zu verwenden.
- Sprint-Planung: Es sollte sichergestellt werden, dass statt eine Team ähnliche Elemente auswählt (z. B. zwei Museen), diese Elemente auf mehrere Teams verteilt werden, um interdisziplinäres Lernen und Anpassungsfähigkeit zu fördern.
- Sprint-Durchführung: Geben Sie als Moderator und/oder PO ehrliches Feedback zur Arbeit der Teilnehmer, vermeiden Sie jedoch direkte Anweisungen, wie sie vorgehen sollen. Stattdessen sollten die Teilnehmer dazu angeregt werden, selbst zu denken. Wenn sie beispielsweise nach spezifischen Produktdetails (z. B. Copyright) fragen, antworten Sie mit Fragen, die die Teilnehmer dazu bringen, eigene Lösungen zu entwickeln. Wenn gefragt wird, wie sichergestellt werden kann, dass jedes Team dasselbe Copyright verwendet, könnten Sie antworten: "Ich weiß es nicht. Was denkt Ihr?"
Fazit
Die LeSS-Simulation zur Erstellung eines Stadtführers ist eine wirkungsvolle Methode, um die Dynamik von Multi-Team-Scrum zu demonstrieren. Durch den Fokus auf Zusammenarbeit, das Managen von Abhängigkeiten, und kontinuierliche Verbesserung gewinnen die Teilnehmer praktische Einblicke in die effektive Skalierung von Scrum.
