Agilität erleben: Scrum-Simulation mit Lego
- 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.
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
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?
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
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.:
- Ein mehrstöckiges Haus
- Eine Brücke mit Bögen und einer definierten Länge
- Ein Traktor
- Eine Garage für den Traktor
- Öffentliche Verkehrsmittel
- Eine Bushaltestelle
- Eine Eisdiele
- 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!
- Das Team sollte für den Sprint ein gemeinsames Ziel formulieren, damit nicht "jeder irgendwas" macht, sondern alle an einem Strang ziehen.
- 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.
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.
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.
Konflikte im Team lösen
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
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
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.
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
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.
- 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.
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.
Weitere Beiträge
Agilität erleben: Scrum-Simulation mit Lego
Mein Team baut eine Stadt mit Lego. Und lernt dabei spielerisch, wie Scrum wirklich funktioniert.
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.
Einen Kommentar schreiben