The LeSS City Guide Simulation is an engaging, hands-on activity that immerses participants in the dynamics of multiple teams collaborating on a single product. As an evolved version of the Nexus Zoo simulation, this exercise shifts the focus to a practical and relatable project: creating a city guide paper brochure for the training’s host city. It introduces events typical of LeSS adoptions, such as the Self-Design Team Workshop and Multi-Team Refinement, to help participants experience the unique aspects of LeSS (Large-Scale Scrum) and contrast them with traditional Scrum.
The simulation highlights the complexities and challenges of scaling Scrum, offering participants valuable insights into team collaboration, product integration, and systemic improvement.
This activity mirrors real-world challenges by having participants create a tangible product with customer value. It is typically run before formally introducing LeSS events, allowing participants to better understand how LeSS differs from Scrum and fostering deeper learning.
The simulation begins with participants forming their own teams during a Self-Design Team Workshop. Colored voting dots represent key skills:
Participants choose dots corresponding to their skills, which they display on their name tags. Teams of 4-5 members are then formed through self-organization, ensuring that each team has all 4 required skills.
The Product Owner (PO), typically the trainer or co-trainer, presents the product goal: creating a local city guide paper brochure and gathering feedback as soon as possible.
Initial backlog items:
Participants refine the items in mixed groups across teams. Each group creates:
After a time-boxed refinement session, all participants walk around the room, and each group presents their work. A second round of refinement may follow to add further details if needed. Alternatively, instead of having each group present their work to everyone, one person stays at the board while each group moves to another slot to continue refining what the previous group worked on. At the end of the Multi-Team PBR, the PO collects the post-its with the most interesting items (e.g., Must-See Attractions, Museums) to update the Product Backlog.
The PO establishes a Definition of Done, including:
During Sprint Planning, the PO presents the top backlog items one at a time in a given sequence. For each item, the PO asks which team wants to implement it. Once a team volunteers to take an item, the PO moves on to the next item. This ensures that items are taken in order of priority while respecting the teams' remaining capacities. The list could look as follows:
With a visible timer, teams work to complete an increment meeting the Definition of Done. The PO provides feedback and answers questions but avoids direct intervention.
When the Sprint ends, the Sprint Review takes place immediately, during which the completed work is inspected. The trainer sets a timer to keep the Sprint Review concise.
After the Sprint Review, each team holds a Team Retrospective to discuss what went well and what could be improved. Afterward, the entire group participates in an Overall Retrospective, which includes the PO. This retrospective focuses on systemic improvements for the next iteration.
The simulation reveals challenges typical of large product development environments, offering valuable learning opportunities for participants:
The simulation usually involves at least one more iteration to allow teams to apply their improvement strategies and learnings. At the end of the simulation, a debrief session takes place to highlight key takeaways. Common debrief questions include:
The LeSS City Guide Simulation is a powerful way to demonstrate the dynamics of multi-team Scrum. By focusing on collaboration, dependency management, and continuous improvement, participants gain practical insights into scaling Scrum effectively.
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.
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.
Die Simulation beginnt mit einer Übung, in dem die Teilnehmer ihre eigenen Teams bilden. Farbige Punkte repräsentieren dabei wichtige Fähigkeiten:
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.
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:
Die Teilnehmer refinen die Elemente in gemischten Gruppen über die Teams hinweg. Jede Gruppe erstellt:
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.
Der PO definiert die "Definition of Done", die Folgendes umfasst:
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:
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.
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.
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.
Die Simulation zeigt typische Herausforderungen in Umgebungen wo mehrere Teams zusammen ein Produkt entwickeln und bietet wertvolle Lernmöglichkeiten für die Teilnehmer:
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:
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.
Robert is the CEO of Lean Sherpas and one of 25 certified LeSS Trainers globally and one of the few with hands-on experience in LeSS and LeSS Huge. As a change agent for 15+ years, consulting and coaching, he has worked with over 30 companies, including DAX-listed global brands such as Adidas, BMW, BP, Dr. Oetker, Henkel, Hilti, Hugo Boss, SAP, Volkswagen, and ZF.
From 2015 to 2016 he led a LeSS adoption at a Global Player in the Software Industry, scaling development from 3 to 7 teams and coaching the development and the management team on how to lead a scaled agile organization. In 2018 he contributed to significant improvements in product delivery at one of the biggest LeSS Huge adoptions in the world at BMW AG. Working with over 30 teams, including large groups of over 400 employees, he led them to deliver bi-weekly product increments consisting of hardware and software.
Robert ist der CEO von Lean Sherpas und einer von weltweit 25 zertifizierten LeSS-Trainern und hat praktische Erfahrung sowohl mit LeSS als auch mit LeSS Huge. Als agiler Berater und Coach hat er in den letzten 20 Jahren mit über 30 Unternehmen zusammengearbeitet, darunter DAX-notierte Weltmarken wie Adidas, BMW, BP, Dr. Oetker, Henkel, Hilti, Hugo Boss, SAP, Volkswagen und ZF.
Von 2015 bis 2016 leitete er eine LeSS-Einführung bei einem Global Player in der Softwarebranche, skalierte dabei die Entwicklung von 3 auf 7 Teams und coachte das Entwicklungs- und Managementteam bei der Führung einer skalierten agilen Organisation. Im Jahr 2018 trug er bei einer der weltweit größten LeSS-Huge-Implementierungen bei der BMW AG zu signifikanten Verbesserungen in der Produktentwicklung und -auslieferung bei. In Zusammenarbeit mit über 30 Teams und mehr als 400 Mitarbeitern führte er sie dazu, alle zwei Wochen Produktinkremente, bestehend aus Hardware und Software, zu liefern.
Watch Konstantin Ribel discuss organizational behavior and performance and how LeSS can help manage organizational complexity. The orginal Video is viewable on the TC LeSS YouTube Channel. The original video can be seen on the TC LeSS YouTube Channel.
Sehen Sie, wie Konstantin Ribel über organisatorisches Verhalten und Leistung spricht und wie LeSS helfen kann, die organisatorische Komplexität zu bewältigen. Das Originalvideo ist auf dem TC LeSS YouTube Channel zu sehen.
Konstantin Ribel and Craig Larman discuss how BMW's driverless driving team was built based on LeSS Huge, and the successes and problems encountered along the way.About the conferenceLeSS attempts to define what is just necessary for large-scale development. It avoids adding additional roles
Konstantin Ribel und Craig Larman erörtern, wie das BMW-Team für fahrerloses Fahren auf der Grundlage von LeSS Huge aufgebaut wurde und welche Erfolge und Probleme auf dem Weg dorthin aufgetreten sind.Über die KonferenzLeSS versucht, das für eine groß angelegte Entwicklung gerade noch Notwendige zu definieren. Es vermeidet das Hinzufügen von zusätzlichen Rollen, Artefakten oder Prozessen, da es die Nachteile dieser Zusätze erkennt.Sehen Sie das Original hier -> www.infoq.com