Scrum Simulation mit LEGO Steinen - Eine ganzheitliche, produktorientierte
←
→
Transkription von Seiteninhalten
Wenn Ihr Browser die Seite nicht korrekt rendert, bitte, lesen Sie den Inhalt der Seite unten
Eine ganzheitliche, produktorientierte
Scrum Simulation mit LEGO Steinen
für mehrere Teams
Die kleine & mittlere Unternehmensedition
Kann adaptiert werden, um andere iterationsbasierte, agile Rahmenwerke
zu lehren.
Original Schriftstück veröffentlicht im Februar
2009
Verfasst von Alexey Krivitsky
Aktuelle Version 2.0, Oktober 2011
info@lego4scrum.com
Diese Arbeit wird verteilt unter einer
Creative Commons Attribution 3.0 Unported License
1
VORWORT
WARUM EINE LEGO SIMULATION?
ANERKENNUNGEN UND DANKSAGUNGEN
AKTUELLE VARIATION
LIZENZ DIESER ARBEIT
WEB GEMEINSCHAFT UND ÜBERSETZUNGSPROJEKT
DAS SPIEL
DAUER, GRUPPENGRÖßE, MATERIALEN
ROLLEN
Product Owner
Scrum Master
Team Mitglieder
Tester – Optionale Rolle
Keine Beobachter erlauben
WAS GILT ES ZU BEOBACHTEN
Verhalten
Kommuniktationstile
Verletzter Prozess
STUFEN DES SPIELS
VORSPIEL: Organisieren der Teams
VORSPIEL: Projektbekanntgabe
VORSPIEL: Erstellen des Backlogs
VORSPIEL: Schätzen
Die schnellste Techik - Schwimmbahndimensionierung
Planungs Poker mit mehreren Teams
SPIEL: Sprint Planung
SPIEL: Sprinten
SPIEL: Review
SPIEL: Release Zyklus
NACHSPIEL: Nachbesprechung
VARIATIONEN
Fluktuationen hinzufügen
Unternehmensweites Scrum
Hast Du Deine eigene Variation? Lass es uns wissen
VIELEN DANK!
2
VORWORT
WARUM EINE LEGO SIMULATION?
Über die letzten Jahre habe ich ein dutzend Scrum-Klassen als Co-Trainer ausgebildet,
sowohl mit Zertifizierung als auch ohne. All diese Klassen hatten unterschiedliche
Simulationseinheiten, aber ich hatte immer das Gefühl, dass es hier etwas besseres
geben sollte.
Nachfolgend nenne ich die Merkmale, die ein minimales Spiel über Scrum meiner
Meinung nach haben sollte.
1. OFFENE BACKLOGS, DIE IDEENFINDUNG MOTIVIEREN
über DETAILIERTE ANWEISUNGEN,
DIE BEFOLGT WERDEN MÜSSEN
Wir wollen ein Spiel mit einem offenen Backlog starten - eine Einladung zur
Kollaboration zwischen Kunde und Teams.
Backlogs können von Trainern vorbereitet werden, aber sie sollten nicht geschlossen
und präzise sein wie “tu dies, dann mach jenes”. So etwas klingt nach dem “guten,
alten” Befehl und Kontrolle.
Wir wollen eine ganz andere Art der Beziehung zwischen Kunde und Teams lehren
und demonstrieren.
2. ACHTSAME PRODUKTENTWICKLUNG
über EINE SERIE VON FERTIG ZU
STELLENDEN AUFGABEN
Wir müssen Produktentwicklung lehren, nicht Mikromanagement auf Aufgabenniveau.
Daher sollten Backlogs und Anweisungen nicht als eine Serie von Aufgaben
komponiert werden. Statt dessen sollten sie eher eine Produktvision darstellen - ein
große Sache, die größere Teams erstellen sollten.
3. TEAMS ARBEITEN ZUSAMMEN AM GEMEINSAMEN ERFOLG
über WETTKAMPF UM DEN PUNKTESTAND
Das Spiel sollte skalierbar sein, um auf Gruppengrößen von 20 Personen und
mehr zu passen. Das wird wiederum dazu führen, die Teilnehmer in Teams
aufzuteilen. Dies sollte als Chance genutzt werden, die Fähigkeiten zur Kollaboration
zwischen Teams zu praktizieren. Das sollte gewollt und ohne spezifische
Anweisungen geschehen, da es für Teams natürlich ist, in den Wettbewerb zu treten.
3
4. NÜTZLICHE METRIKEN ZUR BEWERTUNG DER VORTEILE VON
AGIL
über FIGUREN, DIE DIE TRAINER EINFORDERN
Alle Metriken, welche die Trainer von den Teilnehmern einfordern, sollten einen
offensichtlichen Vorteil für die Teams haben und das Spiel selbst sollte ihnen den
eigenen Fortschritt lehren.
5. KONTINUIERLICHE VERBESSERUNG
über GEWINNEN ODER VERLIEREN DES SPIELS MIT
EINEM VERSUCH
Das Spiel sollte so ausgelegt sein, dass Teams mehrere Versuche haben. Jede Sitzung
generiert Erfahrungen und Erkenntnisse und hilft ihnen, bessere Prozesse
herauszufinden.
ANERKENNUNGEN UND DANKSAGUNGEN
Anfang 2009 hat Mykola Gurov mir dabei geholfen, das Potential von LEGOs als
eine Art “API” für Produktentwicklungsimulationen zu erkennen.
Später im selben Jahr habe ich dann nach Diskussionen mit William Wake, Jurgen De
Smet, Yves Hanoulle und Xavier Quesada Allue eine frühe Version eines Spiels mit
dem Namen “LEGO für erweiterte SCRUM Simulationen” erstellt.
Seit der ersten Veröffentlichung auf der Scrum Alliance Website habe ich dutzende
eMails mit Danksagungen für diese Arbeit erhalten. Nun möchte ich diese
Gelegenheit nutzen und im Gegenzug jedem, der mich kontaktiert hat, um Ideen zur
und Erfahrungen mit dieser Simulation zu teilen, zu danken:
Gerry Kirk, Tim Yevgrashyn, Steve Rogalsky, Andriy Yevtushenko, Geoff Watts,
Laurent Godé, Radu Davidescu, Martine Devos, Jo Newcombe Cook, Jakob
Frandsen Martin Muntzing, Ola Ellnestam, Dusan Kocurek, Danny (Danko) Kovatch,
Gustavo Quiroz, Jukka Lindström, Eduardo Bregaida, and Nathaniel Cadwell.
Insbesondere danke ich Robin Dymond und Sergey Dmitriev für die Gelegenheiten,
dieses Spiel in ihren Certified Scrum Master Klassen zu spielen.
AKTUELLE VARIATION
Seit der ersten Veröffentlichung des Dokuments in 2009 haben dutzende Trainer
dieses Spiel ausprobiert. Die aktuelle, verbesserte Version der Simulation, die in
4
diesem Dokument beschrieben wird, reflektiert die Rückmeldungen und
Beobachtungen, die gemacht wurden.
LIZENZ DIESER ARBEIT
Die aktuelle Arbeit wird unter folgender Lizenz verteilt:
Creative Commons Attribution 3.0 Unported License
This license lets others distribute, remix, tweak, and build upon your work, even commercially, as long
as they credit you for the original creation. This is the most accommodating of licenses offered.
Recommended for maximum dissemination and use of licensed materials.
WEB GEMEINSCHAFT UND ÜBERSETZUNGSPROJEKT
Wir haben uns entschieden, einen Ort zu erstellen, an dem Personen mit dem
Interesse, Scrum mit LEGOs zu unterrichten, zusammenkommen und
zusammenarbeiten können.
www.lego4scrum.com - Trete der Gemeinschaft bei und hilf uns, es zu
verbreiten.
Eines der fortlaufenden Projekte dieser Gemeinschaft ist die Übersetzung des
Dokuments in alle Sprachen dieser Welt. Prüft den aktuellen Status und denkt darüber
nach, uns zu helfen. Wir wissen eure Bemühungen wirklich zu schätzen.
DAS SPIEL
DAUER, GRUPPENGRÖßE, MATERIALEN
Es hat sich gezeigt, dass das Spiel den jeweiligen Bedürfnissen des Trainers und den
unterschiedlichen Gruppengrößen angepasst werden kann.
Ein “standard” Spiel ist nachfolgend beschrieben, aber fühle Dich ermutigt, es
Deinen individuellen Bedürfnissen anzupassen.
Zeitvorgabe: 100-120 Minuten
● 100 Minuten - bei Anwendung schneller Schätzverfahren für Teams
● 120 Minuten - bei Anwendung von Planungs Poker oder anderen
Schätzverfahren
Gruppengröße: 4-25 Personen
● Ideal sind 2-3 Teams von 4-6 Personen Größe (ergibt 8-18 Personen
insgesamt)
● Kann um Scrum Master erweitert werden
5
LEGO Boxen: eine LEGO Box für ein Team von 4-6 Personen
1
● Ich benutze “LEGO Grundbausteine #6177”
● Es braucht vier Boxen für 20 Personen
Stationär: Standard Training Paket
● Sticker, Flip Chart Papier, Textmarker
● Planning Poker Karten (oder selbstgemachte)
Raumgestaltung: ein Tisch für ein Team von 4-6 Personen
● Extra Raum (ein Tisch oder eine Ecke im Flur) für das integrierte Produkt ist
nützlich
ROLLEN
Product Owner
Als Trainer spiele ich die Rolle des Product Owner.
Das Ziel ist, das Verhalten von Product Ownern zu zeigen, was sie typischerweise
erwarten und brauchen, welche Verhaltensweisen der Teams sie begrüßen und welche
nicht.
Scrum Master
Dieses Spiel kann ohne dedizierte Scrum Master gespielt werden.
Manchmal habe ich Scrum Master im Spiel durch Einladen von Co-Instruktoren.
Eine weitere Option ist, das Team zu bitten, einen Scrum Master auszuwählen.
Wenn man erfahrene Prozessbegleiter in der Rolle von Scrum Mastern hat, die
konstant auf den Prozess fokusiert sind und einen dedizierten Trainer, der die
Geschäftsrolle spielt, wird das Spiel wesentlich realistischer und entspannter.
Team Mitglieder
Andere Studenten sind Teammitglieder
Tester – Optionale Rolle
1
Visit the online LEGO store: http://shop.lego.com/en-US/LEGO-Basic-Bricks-Deluxe-6177
1
6Du kannst Tester im Team haben. Ihre Hauptaufgabe wärees , ihren Teams zu helfen, Vereinbarungen bzgl. Anforderungen und Designs zu dokumentieren, um Akzeptanztesten zu ermöglichen und durchzuführen. Die Kehrseite, die ich erfahren habe, ist, dass Tester eher die Qualität beobachten, als mit LEGOs zu bauen. Da jedoch das Ziel solcher Spiel “learning by doing” ist, macht es meiner Meinung nach Sinn, jeden zu animieren, sich am Bauprozess zu beteiligen. Keine Beobachter erlauben Das Spiel macht so viel Spaß beim Spielen, dass Beobachter mehr verlieren als gewinnen würden - meiner Meinung nach. Auf der anderen Seite würde ich es lieben, gute Geschichten von euch zu hören. WAS GILT ES ZU BEOBACHTEN Verhalten Meinen Beobachtungen zur Folge gibt es in Spielen bestimmte Verhaltensweisen, welche die Spieler an den Tag legen, die Arbeitsgewohnheiten widerspiegeln. Und unter Stress neigen Menschen dazu, in ihre natürlichen Verhaltensmuster zurückzufallen. Das Spiel ist bewusst so gestaltet, dass es stressig ist. Darum kann es gegebenenfalls schlechte Verhaltensmuster aufdecken, die wirklichen agilen Einführungen im Wege stehen können. Mein Ziel als Trainer ist es, diese Verhaltensweisen für die Gruppe hervorzuheben und zu Lernerfahrungen und Warnungen zu machen, auf die es ein Augenmerk zu legen gilt. Kommuniktationstile Achte auf: “Manager”, “Diktatoren”, “Lauten Stimmen” und ähnliche Projektionen. Das ist fruchtbarer Boden für Nachbesprechungen und persönliches Coaching. Verletzter Prozess Halte die Augen offen auf Teile des Prozesses, die die Teams nicht so gut machen. Zum Beispiel, wenn das Team während der Anforderungsdiskussion nicht so viele klärende Fragen stellt, wie es stellen sollte. Höchstwahrscheinlich haben sie das gleiche Problem oder werden das gleiche Problem haben, wenn sie in eine ähnliche Situation in einem realen Projekt kommen. Hervorheben und Besprechen des Problems mit dem Team wäre ein Weg, damit umzugehen. STUFEN DES SPIELS 7
Die Simulation hat drei natürliche Teile: Vorspiel, Spiel und Nachspiel oder
Nachbesprechung.
Vorspiel
● Organisiere der Teams
● Definiere den Prozess
● Projekt bekanntgeben
● Erstellen des Backlogs
● Schätzen
Spiel
● Sprint Planung
● Sprinten
● Sprint Review
Nachspiel
● Nachbesprechung
VORSPIEL: Organisieren der Teams
Dauert ca. 5 Minuten
Es gibt keine Grund, warum diese Aktivität nicht Teil des Spiels ist - als Lernprozess.
Ich strebe die Demonstration von Selbstorganisation in Aktion an und bitte dazu die
Teilnehmer, sich in Gruppen von 4-6 Personen zu organisieren und sich dann einen
Arbeitsbereich zu suchen.
Das ist eine gute Aufwärmübung, da es vielleicht nötig ist, Tische zu bewegen und
aufzuräumen.
VORSPIEL: Projektbekanntgabe
Benötigt 10 Minuten. Du spielst jetzt seit 5 Minuten das Spiel.
Als Trainer, der den Product Owner spielt, muss ich folgende Botschaften
kommunizieren:
1 Alle Teams arbeiten an einem einzigen Produkt - sie sind nicht konkurrierend,
vielmehr arbeiten sie für denselben Lieferanten.
2 Das Produkt ist eine STADT mit bestimmten Eigenschaften.
3 Das Hauptbaumaterial sind LEGOs, wobei anderes Material in Ergänzung
dazu benutzt werden kann.
4 Ich bin der Hauptentscheider für das Produkt - es ist meine Stadt.
85 Ich bin dahingehend in den Entwicklungsprozess involviert, als das ich
verfügbar bin, um Fragen zu beantworten und Feedback zu geben.
Diese Aktivität als kollaborative Bekanntgabe durchzuführen, mag ein guter Weg sein.
Mein Ziel ist es sicherzustellen, dass die Teams beim Bauen der “Produkte” mit
LEGOs Scrum praktizieren. Nun ist die Herausforderung, wie man diese beiden
Rollen kombiniert: ein Product Owner (dem nicht der Prozess gehört) und den
Trainer für die Klasse (der ein Interesse daran hat, diese Simulation mit Scrum
durchzuführen).
Da gibt es mehre Wege, mit denen ich das versucht habe:
1 Wechsle die Hüte – beschreibe dem Team die Scrum - Regeln
Ich mache explizit deutlich, ob ich in diesem Moment als Product Owner
agiere oder als Trainer, so dass die Teilnehmer nicht verwirrt sind.
2 Spielen eines neuen Product Owner – lass das Team Dir Scrum
verkaufen
Meistens spiele ich einen Product Owner, der nicht viel über Agil oder Scrum
weiss. Und nach der Präsentation meiner Vision einer Stadt bitte ich das Team
um Hilfe bei der Ausgestaltung eines Prozesses, der dafür passt.
Persönlich mag ich den zweiten Ansatz mehr, da er hilft, das Lernen der Klasse
unterstützt und die Teilnehmer das Artikulieren agiler Werte praktizieren lässt.
VORSPIEL: Erstellen des Backlogs
Benötigt 15 Minuten. Du spielst das Spiel jetzt 15 Minuten.
So bald man sich auf Projekt und Prozess verständigt hat, ist es Zeit, die
Eigenschaften der Stadt dem Team mitzuteilen.
Ich mache das üblicherweise so, dass ich dem Team einen Satz vorbereiteter Post-Its
zeige, die ich auf ein Flipchart hänge.
Normalerweise sind folgende Dinge enthalten:
● Einstöckiges Haus (mehrere davon, eines pro Post-It)
● Zweistöckiges Haus (mehrere)
● Geschäft
● Schule
● Kirche
● Krankenhaus
● Kindergarten
● Bushaltestelle
● Kreuzung (kann gezeichnet werden)
● Park (kann gezeichnet werden)
9● Fluss (kann gezeichnet werden)
● Brücke
Einige der Dinge können auf Flipchart-Papier gezeichnet werden mit den LEGOs
oben drauf.
Hier kannst Du kreativ werden und etwas unterhaltsameres bauen als eine einfache
Stadt.
Wir haben das Spiel einmal mit einem Start-Up Team gespielt, darum haben wir dann
ein “Silicon Village” gebaut. Das brauchte dann offensichtlich ein paar andere Dinge,
die gebaut werden mussten wie zum Beispiel eine Präsentationshalle mit einem iPad
(das einen Bildschirm darstellt), ein paar Co-Working-Plätze in der Stadt, ein sicheres
Gebäude für Webserver und ein Denkmal eines heldenhaften Existensgründers (ein
ausgefallenes Denkmal auf Schienen). Das war ein Spaß!
Während das Backlog präsentiert wird, beschreibe ich kurz wie ich denke, dass jedes
Element aussehen könnte. Und ich versuche, Diskussionen auf später zu verschieben.
VORSPIEL: Schätzen
Wird bis zu 20 Minuten dauern. Du spielst das Spiel jetzt seit 30 Minuten.
Schätzungen. Der härteste Teil, irgendwie.
Ich würde vielleicht:
1 Schätzungen weglassen (wie agile Gurus es empfehlen würden)
2 Es schneller und einfacher machen
3 Ein bisschen Zeit investieren, um Planing Poker zu praktizieren
RT @RonJeffries: "Jedes Jahr gibt es ein neues Schätzverfahren. Der wahre agile
Ansatz würde Schätzungen hinauswerfen" - @agilemanager [JA!]
Abhängig davon, wie viel Zeit wir haben, kann ich zwischen der einfachsten
Technik oder Poker wählen.
Die schnellste Technik - Schwimmbahndimensionierung
Ich habe diese Technik von www.theagilepirate.net gelernt. Anscheinend mache ich
das aber in einer weniger ausgeklügelten Art und Weise.
Sieh Dir mal die Zeichnung weiter unten an.
10Basierend auf dem Konzept der Triangulation 2 und der Dimensionierung von
Schwimmbahnen3 teilen wir einfach Rubriken ein, um unterschiedliche Größen von
Stories zu markieren (1 2 3 5 8 13, wenn Du Fibonacci bevorzugst - ein wenig
Beigeschmack von Wissenschaft ist immer gut) und bitten die Teilnehmer, Stories in
die Bahnen zu ziehen, welche die passende Größe der Story repräsentieren. Wir
machen das in Gruppen oder alle gemeinsam.
Diese Aktivität kann ebenso im Stillen durchgeführt werden.
Abbildung 1: Schwimmbahnen für Gruppenschätzungen
Wenn eine Gruppe so groß ist, dass sie in Gesamtheit nicht vor das Board passt, bitte
ich jedes Team darum, Paare zu schicken. Wenn diese Paare fertig sind, kommen die
nächsten und zwar so lange, bis jeder die Gelegenheit hatte, mit dem Board zu
arbeiten.
Wenn wir fertig sind, frage ich die Gruppe, ob es “gut genug” ist, um zu starten und
ob sie nun richtige arbeiten wollen.
2
Triangulation and other concepts of Agile estimating and planning, by Mike Cohn
http://www.mountaingoatsoftware.com/presentations/85-an-introduction-to-agile-estimating-and-planning
2
2
3
Swimlane Sizing – Complete & Fast Backlog Estimation
3
http://theagilepirate.net/archives/109
3
11Planungs Poker mit mehreren Teams
Planungs Poker4 mit mehreren Teams zu spielen, erfordert zu erst das Verständigen
auf eine Beispielgröße als gesamte Gruppe.
Das Verständigen auf eine Größe ist einfach: Nimm ein Element, das klein und
einfach genug ist, aber nicht trivial und weise diesem den Wert “2” zu. Üblicherweise
stimmen alle Teilnehmer überein, dass einstöckige Häuser als zwei gewertet werden.
Ein anderer Ansatz ist der, Beispiel-Stories auszuwählen, diesen T-Shirt Größen5 (XS,
S, M, L, XL) zuzuweisen und dann alle Stories der Größe S mit “2” zu markieren, um
dann mit Poker weiterzumachen.
Ich möchte gern einige Tipps mit euch teilen, die mir helfen, Mulitteam Planungs
Poker Sessions zum Laufen zu kriegen:
● Organisiere eine Wand mit Schwimmbahnen (siehe Skizze oben)
● Bitte die Teams, Stories einzeln nacheinander zur Schätzung zu ziehen.
● Bitte die Teams, Details an jede Story zu hängen, so bald Klärungen vom
Product Owner gekommen sind (da es vielleicht ein anderes Team sein könnte,
das diese Story umsetzt).
● Ermutige Teammitglieder dazu, Fragen zur Klärung zu stellen, die helfen
können, Größen zu definieren und würdige dies.
● Einmal geschätzt muss eine Story an die Wand getan werden, so dass andere
Teams von dieser neuen Information profitieren können.
● Wenn die Schätzung erledigt ist, bitte die Teilnehmer, zur Wand zu gehen und
einen Vernunftscheck mit gegebenenfalls notwendigen Änderungen
durchzuführen (meiner Erfahrung nach werden Änderungen kaum benötigt).
Wenn die Teams nicht viel über Planungs Poker wissen, ist es sinnvoll, einen
Testlauf zu machen, so dass Du beobachten kannst, ob die Teilnehmer die Technik
korrekt anwenden. Ich frage Teams üblicherweise:
“Wie viel kostet ein Pint Guinness in U.K?”
4
Planning Poker is found by James Grening in 2002 and popularized by Mike Cohn:
4
http://en.wikipedia.org/wiki/Planning_poker
4
5
T-shirt sizing
5
http://blogs.msdn.com/b/oldnewthing/archive/2009/05/12/9605143.aspx
5
12Das impliziert, das Fragen gestellt werden, wie Punkte hier angewandt werden
können, nach Ort und Datum, wo das Guiness gekauft wird etc. - das ist ebenfalls
eine gute Aufwärmübung zum Schätzen von Stories.
Interessanterweise liefern beide Techniken, Schwimmbahnen und Planungs Poker die
notwendige Präzision für Release Planung, was durch Hunderte von Release Burn-
Down Charts belegt wurde.
SPIEL: Sprint Planung
Du spielst das Spiel jetzt seit 50 Minuten.
(Und es sind keinerlei Dinge gebaut worden bis jetzt! Beweist das nicht genug, dass
Schätzungen verschwenderisch sind?)
Nun, da die Stories geschätzt sind, musst Du diese von der Schwimmbahnen Wand in
das Backlog bewegen.
Da wir die Sprint Planung maximal sichtbar machen wollen, erstellen wir eine
spezielle Planungswand, welche die Pläne aller Teams für alle Sprints in dem Spiel
zusammenfasst.
Abbildung 2: Multi-team Planungswand, vor der Planung von Sprint #1
13Abbildung 3: Multi-team Planungswand, innerhalb von Sprint #2 Wir setzen eine Time-box für die Sprintplanungsaktivitäten von drei Minuten an, in der wir die Teams bitten, ihre Sprintbox mit Stories zu füllen. Wenn alles erledigt ist, fragen wir die Teams, ob sie sich unwohl genug mit ihren Plänen fühlen, um es zu versuchen! SPIEL: Sprinten Braucht ca. 7 Minuten. Wir bevorzugen 7-Minuten Sprints, da es grade genug Zeit ist, mehrere Elemente in Zusammenarbeit mit mehreren Personen zu bauen, ohne zu viel “Politur” an die Elemente kommen zu lassen. 14
Um sicher zu gehen, dass die Teilnehmer gestresst genug sind, verwenden wir eine
große, für alle sichtbare Stoppuhr via Notebook oder Beamer:
Abbildung 4: Eine Stoppuhr von www.online-stopwatch.com - Zeitgeber in verschiedenen
Formen, können auch offline genutzt werden.
SPIEL: Review
Braucht ca. 5 Minuten.
Wenn die Zeit um ist, stelle ich sicher, dass die Teilnehmer wirklich mit Bauen
aufgehalten haben und fange an zu fordern: “Wo ist meine Stadt?”
Es hat sich gezeigt, dass Teams erst nach dem zweiten Sprint mit der kontinuierlichen
Auslieferung von Stories in die Demonstrationsumgebung (ein Flipchartpapier)
beginnen. So wird in den meisten Fällen niemand daran gedacht haben, wie die
Demonstration zu organisieren ist. Klingt das nicht ähnlich wie im realen Leben?
Ich bekomme immer Kommentare in der Nachbesprechung, dass ich den gütigsten
Product Owner spiele, den man je gesehen hat. Trotzdem wird in den meisten Fällen
nach dem ersten Sprint nichts akzeptiert, da ich nach dem Zeigen der ersten Gebäude
“zu realisieren beginne”:
● Ich mag Symmetrie.
● “Alles in der gleichen Farbe” bedeutet aktuell “einfarbige Gebäude, wobei die
Gebäude nicht alle gleichfarbig sind.”
● Gebäude sind entweder zu klein, zu groß oder zu verschieden.
● Fenster auf unterschiedlichen Ebenen sind nicht in einer Reihe.
●
Unfertige Elemente gehen zurück von der Planungswand in das Backlog.
Verbleibende Arbeit kann neu geschätzt werden, wenngleich wir selten Schätzungen
aktualisieren.
15So bald Stories akzeptiert wurden, wird das Release Burndown Chart vom PO
aktualisiert, der klar und laut ankündigt, dass das Release in drei Sprints fertig sein
muss und es bis jetzt so aussieht, als wären wir nicht in der Lage, alle Stories zu
schaffen.
Ein paar Minuten sollten retrospektiv der Frage “Wie können wir uns im nächsten
Sprint verbessern?” gewidmet werden.
SPIEL: Release Zyklus
Ohne viel Zeit mit der Diskussion von Fehlern im ersten Sprint zu verschwenden,
was immer ein Desaster ist, gehen wir direkt zur Sprint Planung.
Ich habe gelernt, dass es durchschnittlich drei Sprints braucht, um 80% des Backlogs
mit erwarteter Qualität fertigzustellen, so dass der volle Zyklus in der Regel so
aussieht:
1 Sprint #1
a Planung – 3 Minuten
b Sprinten – 7 Minuten
c Review – 5 Minuten
2 Sprint #2
a Planung – 3 Minuten
b Sprinten – 7 Minuten
c Review – 5 Minuten
3 Sprint #3
a Planung – 3 Minuten
b Sprinten – 7 Minuten
c Review – 5 Minuten
Zwischensumme: 45 Minuten
Da uns die Vorbereitung ungefähr eine Stunde gekostet hat (von der Bekanntgabe bis
zum geschätzten Backlog), die Sprints 45 Minuten brauchen und es ungefähr 15
Minuten zu Nachbesprechung braucht, dauert das ganze Spiel um die 120
Minuten.
Einmal gemacht und mit der Hilfe von Co-Trainern, welche die Scrum Master spielen,
kann es auch ein wenig schneller gehen.
16NACHSPIEL: Nachbesprechung
Es ist wahrscheinlich vernünftig, nach dem letzten Sprint eine kurze Pause zu machen,
um die Gemüter sich beruhigen zu lassen und kurz Luft zu holen, bevor wir dann in
die Nachbesprechung gehen (Habe ich erwähnt, dass das Spiel so augelegt ist, dass es
erschöpft? Und zwar nicht nur die Teams...)
Wenn wir wieder zusammengekommen sind, machen wir eine moderierte Diskussion
um folgene offenen Fragen:
● Was haben die Teilnehmer beobachtet?
● Wie fühlten sie sich, in einem Scrum Team zu sein?
● Wie liefen die kurzen Iterationen?
● Wie genau waren die Schätzungen (vorausgesetzt, das Release Burndown ist
da)?
● Was würden wir von Anfang an anders machen, wenn wir die Chance hätten,
das Spiel ein zweites Mal zu spielen?
● Was waren die Aufgaben des Product Owner?
● Wie fühlte es sich nach dem ersten Sprint an, als nachezu alle Elemente
nachbearbeitet werden mussten?
● Was haben die Scrum Master getan?
● Wie würde sich eure Vorgehensweise ändern, wenn ihr wüsstet, dass der
Product Owner während der Sprints nicht verfügbar ist?
● Wie lief die Kommunikation zwischen den Teams? Gab es Abhängigkeiten?
Wie wurden diese aufgelöst?
● Was haben die Studenten gelernt?
VARIATIONEN
Fluktuationen hinzufügen
Gute Freunde von mir (Askhat Urazbaev and Nikita Filippov) haben ein ähnliches
Spiel entworfen, das willkürliche Fluktuationen hinsichtlich Teamgröße und
Komplexität beinhaltet.
Dazu wird einfach nach der Sprint Planung und vor dem eigentlichen Sprinten ein
Würfel geworfen, der Schätzungen in Story Point multipliziert oder einige
Teammitglieder für diesen Sprint “krank” werden lässt, wobei das Team den
Sprintplan halten muss.
Dieses Spiel möchte hervorheben, dass Kollaboration im und zwischen Teams
essentiell ist für die Aufgabenabstimmung innerhalb der Sprints, da es gern anders als
geplant läuft.
17Unternehmensweites Scrum Ich war in der Lage, die Simulation mit LEGOs so zu skalieren, dass ich mit 100 Teilnehmern in 12 Teams 4 Städte gleichzeitig bauen konnte. Es bedarf dazu zwar ein paar Tonnen LEGOs, aber es scheint ein guter Weg zu sein, Scrum auf unternehmensweiter Ebene zu demonstrieren. Dazu braucht es aber einen weiteren Artikel, um all die Regeln und Rahmenparameter abzudecken. Hast Du Deine eigene Variation? Lass es uns wissen Wir würden gern Deine Geschichten, Deine Variation des Spiels hören – schließe Dich uns bitte an unter www.lego4scrum.com und schicke uns deine Ideen an info@lego4scrum.com 18
VIELEN DANK! Hab verspielte Projekte! Alexey Krivitsky www.lego4scrum.com 19
Sie können auch lesen
