Agilität erleben

Scrum-Simulation mit Lego

Mein Team baut eine Stadt mit Lego. Und lernt dabei spielerisch, wie Scrum wirklich funktioniert.

von Christian

Während das Team diese Lego-Stadt gebaut hat, lernten alle viel über Teamdynamiken, Teamarbeit und das Scrum-Framework.
In diesem Beitrag erfährst du...
  • wie die Scrum-Simulation "Stadtbau mit Lego" funktioniert
  • den Erfahrungsbericht eines Teams, das ich durch diese Simulation begleiten durfte
  • Lernerlebnisse und Konfliktlösung im Zeitraffer

Für Einsteiger ist das Scrum-Framework mit all seinen Rollen, Events und Artefakten sicherlich sehr kompliziert und undurchdringlich. Zum Glück kann man anhand von spielerischen Simulationen Scrum hautnah erlebbar und erfahrbar machen.

Anfangs mutet es vielen sicherlich etwas seltsam an, wenn erwachsene Menschen mit Lego spielen (wieso eigentlich? 🤔). Dabei kann man mit LEGO Serious Play oder einer LEGO-Stadtbau-Simulation sich nicht nur kreativ ausprobieren, sondern lernt dabei gleichzeitig etwas über Teamdynamik und Scrum.

Dürfen/sollen/müssen erwachsene Menschen spielen?
Warum? Warum nicht? Diskutiere gerne mit!

Ich habe schon bei mehreren Teams eine Scrum-Simulation mit Lego angeleitet. In diesem Beitrag möchte ich exemplarisch anhand eines sehr lieb gewonnenen Teams einige Lernsituationen und Erfahrungen aufzeigen:

Team-Rollen

Als Rollen benötigt man zuerst einmal einen Produktverantwortlichen, den sogenannten Product Owner.

Seine Aufgabe ist es, dem Team die klare Produktvision zu vermitteln. Außerdem achtet er darauf, dass zu jeder Zeit der Kunde im Fokus bleibt und bei jeder "Runde" (=Sprint) ein Baustein (=Inkrement) mit echtem Kunden-Mehrwert geschaffen wird.

Die zweite wichtige Rolle ist der Scrum Master, der als unterstützende Führungskraft dem Team zur Seite steht. Der Scrum Master moderiert die Events, behält die Uhr im Blick und achtet auf eine klare, fokussierte und gemeinschaftliche Zusammenarbeit. Außerdem hilft er dem Team dabei, den Überblick zu behalten und räumt Hürden (=Impediments) aus dem Weg.

Alle anderen Teilnehmer sind Lego-Stadtbau-Experten und bilden das Entwicklungs-Team (=Developer).


Insbesondere die Rolle des Scrum-Masters ist sehr herausfordernd und erfordert einen wachen Verstand.

Da wir mit meinem Team bereits im dritten, Tag eines intensiven Workshops waren, haben wir also kurzerhand die Person freiwillig auserkoren, die am besten geschlafen hatte. Wie sich später herausstellte, war das eine perfekte Wahl

Die Produktvision des Product Owners

Im Rollenspiel als Product Owner und Endkunde durfte die "Kundenkäppi" natürlich nicht fehlen.

Als Coach und Facilitator übernahm ich die Rolle des Product Owners. Im initialen Meeting, dem Project-Kickoff-Event, stellte ich mich also vor das Team und erklärte deutlich, was wir in den nächsten zwei Stunden erreichen wollen:

Der Endkunde möchte allen zeigen, dass die Mitarbeiter dieses Teams nicht nur richtig klasse agil zusammenarbeiten können, sondern darüber hinaus mit einem guten Blick für's Wesentliche und viel Geschmack in kürzester Zeit eine stilvolle Legolandschaft erschaffen können.

Dazu wünscht er sich eine schöne Stadt aus Lego, mit Häusern, einem Fluss und einer Brücke als Wahrzeichen.

Am Ende der Iteration möchte der Kunde gerne Fotos machen und sie stolz auf seiner Webseite und seinen Social-Media-Kanälen präsentieren.

An allererste Stelle stehen hier nicht explizite Handlungsaufforderungen (in Form von konkret definierten Tickets, wie z.B.: ein zweistöckiges Haus, eine Brücke, eine Bushaltestelle, ...).

Stattdessen legt der Product Owner Wert darauf, die Produktvision spürbar zu machen: Wovon träumt der Kunde? Was wünscht er sich? Und vor allem: WARUM eigentlich?

Ohne ein tiefes Verständnis der Produktvision kann das Team keine selbstständigen Entscheidungen im Sinne des Kunden treffen.

Der Grund ist klar: Nur, wenn das Team ganz genau weiß, wieso es arbeitet, dann kann es das Projekt auch aus Kundenperspektive betrachten, jederzeit einen klaren Fokus behalten, eigene Ideen einbringen und darauf achten, dass die Lego-Stadt am Ende jeder Iteration immer hübsch, präsentabel und fotogen sein wird.

Product Backlog und Sprint Planning

Um gut abschätzen zu können, wie komplex und aufwändig eine Aufgabe sein wird, hilft das Planning Poker. Alle halten verdeckt ihre Schätzung in die Mitte...

Nachdem das Team jetzt genau weiß, WARUM es an diesem Projekt arbeiten wird, kommt nun das WAS an die Reihe.

Im Sprint Planning stellt der Product Owner die konkreten Aufgaben (=Kundenwünsche) vor und gibt eine Rangfolge vor, was dem Kunden am Wichtigsten ist, z.B.:

  1. Ein mehrstöckiges Haus
  2. Eine Brücke mit Bögen und einer definierten Länge
  3. Ein Traktor
  4. Eine Garage für den Traktor
  5. Öffentliche Verkehrsmittel
  6. Eine Bushaltestelle
  7. Eine Eisdiele
  8. Ein Baukran

 

Das ist das priorisierte Product Backlog.

Auch hier ist es wichtig, dass das Team bei jedem einzelnen Task genau versteht, wieso der Kunde sich das wünscht. Häufig wird das in Form von kleinen Geschichten, den User Stories, beschrieben, um dem Team den Blick aus der Kundenperspektive zu vereinfachen.

Das Entwicklerteam sucht sich von den angebotenen Tasks diejenigen raus, die es zuerst umsetzen will. Aufgaben mit Unklarheiten/Rückfragen (die der Product Owner als Stellvertreter des Kunden nicht beantworten kann) werden zurückgestellt.

Wenn das Team Hürden identifiziert und einen besseren Ansatz hat, dann schreibt es sich gerne eigene Tasks, die zuerst bearbeitet werden.

Dieses konkrete Team hat sich beispielsweise entschlossen, zuerst einmal einen Grundriss der Stadt zu bauen (=eigener Task) und eine Bestandsaufnahme der verfügbaren Legosteine (=noch ein eigener Task) zu machen, um sich eine zuverlässige Arbeitsgrundlage zu schaffen. Wir erkannten schnell, dass das eine geradezu phantastische Idee war!

Egal, welche Aufgabenpakete sich das Team zusammenstellt, es sollte immer zwei Dinge berücksichtigen:
  1. Das Team sollte für den Sprint ein gemeinsames Ziel formulieren, damit nicht "jeder irgendwas" macht, sondern alle an einem Strang ziehen.
  2. Am Ende des Sprints sollte IMMER ein Inkrement herauskommen, dass dem Kunden Mehrwert bietet. Egal wie gering. Denn ohne ein Inkrement mit klarem Mehrwert kann ja überhaupt niemand entscheiden, ob das Projekt sich in die richtige Richtung entwickelt.
... dann drehen alle gleichzeitig um und jeder sieht auf einem Blick, ob bei der Aufwandseinschätzung Übereinstimmung herrscht oder ob noch Klärungsbedarf besteht.

Manche Teams möchten hier gerne das Schätzen von User Stories ausprobieren. Dazu biete ich Story-Point-Karten an.

Das Team einigt sich auf nachvollziehbare Referenzstories und kann dann messen, wieviele Story Points es in einem einzelnen Sprint geschafft hat und wie sich die Geschwindigkeit über den einzelnen Iterationen hinweg entwickelt.

Das Schätzen der Aufgabenpakete kann ganz unterschiedlich stattfinden. Der Klassiker sind Story-Points (häufig unter Verwendung der Fibonacci-Skala, d.h. je komplexer die Aufgabe, desto weniger kommt es auf genaue Nummern an).

Manchmal entscheidet das Team sich aber auch, stattdessen in T-Shirt-Größen, Obstsorten oder Tierarten zu schätzen.
Das wichtigste ist hierbei, ein gemeinsames, vergleichbares und personenunabhängiges Maß der Komplexität einzelner Aufgaben zu finden.

Hürden ansprechen und beseitigen

Nachdem das Team sich entschieden hat, was es im Sprint konkret tun möchte, startet die Arbeit.

In dieser Simulation sind die Zeiten für alle Events (Sprint Planning, Sprint, Sprint Retrospektive, Sprint Review) immer 8 Minuten lang. Das macht es dem Scrum Master einfacher, die Zeiten im Blick zu halten

Als das Entwicklerteam während der Bestandsaufnahme feststellte, dass die Lego-Kiste offenbar unvollständig war (möglicherweise war diese "Ressourcenknappheit" ja beabsichtigt?), holte es sich den Scrum Master als Unterstützung hinzu.

Diese Hürde (=Impediment) konnten wir gemeinsam sehr schnell lösen: Der Product Owner, der Scrum Master und ein Entwickler organisierten einfach noch einige zusätzliche Kisten und stellten sie dem Team zur Verfügung.

Merke: Der erste Schritt zur Problemlösung ist immer, das Problem zu erkennen und klar anzusprechen!

Konflikte im Team lösen

Der Grundriss und die ersten Konstruktionen nehmen Gestalt an. Während des Sprints ist alles noch eine ziemlich unordentliche Baustelle. Das ist aber in Ordnung, solange zum Ende des Sprints alles wieder aufgeräumt ist.

Am Ende des ersten Sprints war der Grundriss fertig (=Inkrement mit sichtbarem Mehrwert) und das Team konnte besser einschätzen, wie es die zukünftigen Aufgaben abarbeiten wollte.

Doch als das Team im Sprint Review stolz die Ergebnisse präsentierte, machte sich eine "leichte Verstimmung" bemerkbar: Der Product Owner (also ich) war eingeschnappt, dass doch irgendwie so wenig geschafft wurde und dass noch nicht alles wieder ordentlich aufgeräumt war. Er fühlte sich vom Team im Stich gelassen und machte seinem Frust auch sehr deutlich und ziemlich emotional Luft (hatte ich schon erwähnt, dass ich Rollenspiele mag?).

Glücklicherweise gelang es unserer Scrum Masterin und dem restliche Team, mit Einfühlungsvermögen und professioneller Gelassenheit den Product Owner zu besänftigen und das Review zu einem guten Erfolg zu führen.

In der anschließenden Sprint Retrospektive konnten wir diese Teamdynamik noch einmal reflektieren. Ich als Product Owner nahm mir vor, dem Team zukünftig mehr Vertrauen entgegenzubringen und mein Projektleiter-Mikromanagement-Syndrom (PMS) ein wenig zurückzustellen. Mal sehen, ob mir das gelungen ist

Der ganz große Vorteil einer Scrum Simulation ist, dass man unter Stress und Zeitdruck sehr schön Teamdynamiken im Zeitraffer erkennen und benennen (und ja, manchmal auch mutwillig herauskitzeln) kann.
Wer spricht wie viel? Wer zieht sich raus? Wer lenkt sich ab oder ist gerade schon einen Schritt weiter? Wie geht das Team mit Krisen und Konflikten um?

Ständig neue Herausforderungen

Die Lego-Stadt nimmt Gestalt an. Am Ende hat das Team deutlich mehr geschafft als sie ursprünglich gedacht hatten.

Im zweiten Sprint zogen dann die Anforderungen (und Ablenkungen) deutlich an.

  • Teammitglieder hatten sich überarbeitet und wurden spontan krank (diese Ereigniskarte ziehe ich gerne, wenn ich merke, dass jemand während der Retrospektive unaufmerksam und eigentlich schon wieder am Arbeiten ist).
  • Die Brücke musste wegen gesetzlicher Regulatorien zwischendrin komplett neu gebaut werden.
  • Und der Product Owner kam leider aus seiner Mikromanager-Haut doch nicht heraus und trat ständig ans Team mit Zusatzwünschen und skeptischen Fragen heran.

 

Aber auch hier stellte sich wieder unsere Scrum-Masterin wie eine Löwenmutti mutig vors Team und schützte es vor Ablenkung und Störung.
Gleichzeitig half sie dem Product Owner (also mir), die Arbeitsweise des Teams besser zu verstehen und wertzuschätzen.

Die Rolle eines Scrum Masters ist herausfordernd.
Er oder sie muss gleichzeitig Einfühlungs- und Durchsetzungsvermögen beweisen. Damit sich das Team optimal entfalten kann, sind sowohl Raum (=Vertrauen) als auch Leitplanken (=Führung) nötig.

Ein guter Abschluss

Liebes Team, ich bin sehr stolz darauf, dass ich eure tolle Stadt in diesem Blogeintrag präsentieren darf!

Im dritten Sprint zeigte sich dann die Magie von gut funktionierendem Scrum:

Das Team war mittlerweile super aufeinander eingespielt, die Produktvision war verinnerlicht, die Ressourcen waren bekannt und alle Ablenkungen waren beseitigt (was sicherlich auch daran lag, dass der Product Owner dem Team sein volles Vertrauen aussprach und sich dann kurzerhand in den Urlaub verabschiedete ).

Das Entwicklerteam zog sich eine Aufgabe nach der anderen und wurde viel schneller fertig als ursprünglich geschätzt.

Teams gehen sehr gerne die berühmte "Extrameile" für ihre Kunden und Kollegen. Das klappt aber nur, wenn
  • die Vision bekannt ist,
  • sich das Team auch die Zeit dafür nehmen darf und
  • Kunde und Team respektvoll miteinander umgehen und an einem gemeinsamen Ziel arbeiten.

Nachdem alle Aufgaben aus dem Sprint Backlog abgearbeitet waren, bearbeiteten sie weitere vorbereitete Tasks aus dem Product Backlog nach und stellten auch diese noch fertig.

Da das Team die Produktvision (fotogene Stadt) genau kannte, beschlossen sie selbstständig, die Fußgängerzone zu begrünen, und den Fluss mit einem Boot und dekorativen Fischen auszuschmücken.

Und das anschließende gemeinsame Aufräumen war für das Team natürlich eine Selbstverständlichkeit.

Ich bin sehr dankbar, dass ich mein tolles und motiviertes Team durch diese Scrum-Simulation begleiten durfte.

Hat dieser Erfahrungsbericht dich inspiriert?
Möchtest du auch mal eine Scrum-Simulation ausprobieren?

Melde dich gerne bei mir oder teile deine Erfahrungen in den Kommentaren.

  Zurück zur Newsübersicht

Einen Kommentar schreiben

Bitte addieren Sie 5 und 1.

Weitere Beiträge

von Christian

Agilität erleben

Scrum-Simulation mit Lego

Mein Team baut eine Stadt mit Lego. Und lernt dabei spielerisch, wie Scrum wirklich funktioniert.

Weiterlesen …

von Christian

Agilität erklärt

Der Agile Baum

Agil wird von vielen gleichgesetzt mit Scrum. Dabei ist Agilität viel mehr: eine Grundhaltung, ein Wertesystem, eine gemeinsame Kultur sowie gemeinsame Prinzipien, auf die dann agile Frameworks und Techniken aufbauen.

Weiterlesen …