1. No category

Holdopdelt og produktorienteret
SCRUM-simulering med LEGO-klodser
udgave for små og mellemstore virksomheder
Kan tilpasses andre iterationsbaserede metoder.
Original version fra februar 2009
skrevet af Alexey Krivitsky
Seneste version 2.0, oktober 2011
[email protected]
Oversættelse til dansk af Jakob Frandsen, Janurary 2012.
Dette dokuments distribution er underlagt
Creative Commons Attribution 3.0 Unported License
1
FORORD
HVORFOR LEGO?
PÅSKØNNELSER
NUVÆRENDE VERSION
RETTIGHEDER
WEBSITE OG OVERSÆTTELSESPROJEKT
SPILLET
VARIGHED, GRUPPESTØRRELSER, MATERIALER
ROLLER
Produktejer
Scrum Masters
Holdmedlemmer
Testere - valgfri rolle
Tillad ikke tilskuere
HVAD DU SKAL LÆGGE MÆRKE TIL
Adfærd
Kommunikationstil
Når processen knækker
SPILLETS GANG
FORBEREDELSE: Holddannelse
FORBEREDELSE: Projektdefinition
FORBEREDELSE: Opbyggelsen af backloggen
FORBEREDELSE: Estimering
Den hurtige teknik - “sortering i svømmebaner”
Planning poker med flere hold
SPILLET: Iterationsplanlægning
SPILLET: Iterationerne
SPILLET: Iterationsevaluering
SPILLET: Iterationernes cyklus
EFTER SPILLET: Slutevaluering
VARIATIONER
Uventede påvirkninger
Enterprise Scrum
Lad os høre om dine erfaringer
TAK!
2
FORORD
HVORFOR LEGO?
Gennem de sidste par år har jeg været træner på mange SCRUM-kurser, en del af dem
certificerede. Disse kurser har altid gjort brug af SCRUM-simuleringer, men jeg har
altid følt at de kunne være bedre.
SCRUM-simuleringer skal efter min mening føles som spil, og skal som minimum
indeholde:
1. ÅBNE BACKLOGS DER FORDRER IDÉER
fremfor DETALJEREDE INSTRUKTIONER
Vi starter spillet med en åben backlog. Det er ment som en invitation til samarbejde
mellem kunden og holdene.
Man kan som træner vælge af have backloggen fyldt ud fra starten, men i så fald bør
man undgå at det er præcise “kommandoer”.
Pointen er nemlig at vi med øvelserne vil demonstrere et helt andet forhold mellem
kunde og produktionsholdet end deltagerne måske er vant til.
2. REFLEKTERENDE PRODUKTUDVIKLING
fremfor EN PRÆCIST SPECIFICERET OPGAVELISTE
Vi skal lave produktudvikling, ikke micromanagement. Derfor skal backloggen
indeholde visioner, der viser retningen for det endelige produkt i stedet for fuldt
udspecificerede opgaver.
3. HOLD, DER SAMARBEJDER OM EN FÆLLES MÅL
fremfor KONKURRENCE OM HVEM DER FÅR FLEST POINTS.
Spillet fungerer for op til omkring 20-25 personer, der selvfølgelig holdopdeles. Det
vil normalt være naturligt for holdene at konkurrere mod hinanden, så det er vigtigt at
nævne at det er meningen at deltagerne skal samarbejde på tværs af holdene.
4. MENINGSFYLDTE OG BRUGBARE MÅLERESULTATER
fremfor TAL FOR TALLENES SKYLD
Når trænerne beder deltagerne om at rapportere målinger er det vigtigt at holdet kan se
meningen hermed, så der bliver skabt en ansvarsfølelse. Holdet skal eje processen.
3
5. LØBENDE FORBEDRINGER
fremfor ALT ELLER INTET
Efter hver iteration lærer deltagerne mere og mere. Derfor er det vigtigt at spillet
tilrettelægges så holdene kan bruge deres erfaringer til at forbedre processen
undervejs.
PÅSKØNNELSER
Tidligt i 2009 hjalp Mykola Gurov mig til at se LEGOs potentiale som et “API”1 for
simulering af produktudvikling.
Senere samme år skabte jeg den første version af spillet kaldet “Udvidet SCRUM
simulering med LEGO” efter diskussioner med William Wake, Jurgen De Smet, Yves
Hanoulle og Xavier Quesada Allue.
Siden den første udgivelse på Scrum Alliances hjemmeside har jeg modtaget mange emails med positive tilkendegivelser for mit arbejde. Jeg vil gerne takke alle dem, der
har bidraget med input og erfaringer med simulationer:
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 og Nathaniel Cadwell.
En særlig tak til Robin Dymond og Sergey Dmitriev for at lade mig afprøve spillet på
deres Certified Scrum Master kurser.
NUVÆRENDE VERSION
Siden førsteudgaven blev udgivet i 2009 har masser af trænere anvendt spillet. Deres
feedback og observationer har gjort mig i stand til at udgive denne forbedrede
version.
RETTIGHEDER
Distributionen af dette dokument er underlagt
Creative Commons Attribution 3.0 Unported License
Alle kan videredistribuere, rette, ændre og bygge videre på dette værk, selv til kommercielle formål, så længe de
kreditterer den oprindelige forfatter. Dette er den mest imødekommende licens der kan tilbydes og anbefales
1Læs mere om “API” her: http://en.wikipedia.org/wiki/Application_programming_interface
4
for maksimal udbredelse af licenserede materialer.
WEBSITE OG OVERSÆTTELSESPROJEKT
Vi besluttede os for at skabe et sted, hvor andre med interesse for at bruge LEGO i
deres SCRUM-undervisning kunne tage hen og bidrage med deres erfaringer og selv
finde inspiration:
www.lego4scrum.com - Deltag i fællesskabet og hjælp os med at sprede ordet.
Et af vores løbende projekter er at oversætte dette dokument til andre sprog. På
hjemmesiden kan du se, hvilke sprog dokumentet findes på allerede og få oplysninger
om, hvordan du kan hjælpe med at oversætte til nye sprog. På forhånd tak for din
interesse og hjælp.
SPILLET
VARIGHED, HOLDSTØRRELSER, MATERIALER
Her vises et “standard”-eksempel, som du kan tilpasse efter dine egne og deltagernes
behov.
Tidsforbrug: 100-120 minutter
● 100 minutter - ved brug af hurtige holdestimeringsteknikker
● 120 minutter - ved brug af planning poker eller andre estimeringsværktøjer
Størrelse på grupperne: 4-25 deltagere
● Det optimale er 2-3 hold med 4-6 personer på hvert hold (ialt 8-18 deltagere)
● Kan udvides med Scrum Masters
LEGO-æsker: Ca. en LEGO-æske per hold med 4-6 deltagere
● Jeg anbefaler at bruge “Basic Brick Set #6177”2
● Det passer meget godt med fire æsker for 20 deltagere
Andet udstyr
● Post-its, flip-over ark, tusser, gerne tavler
● Planning poker kortsæt (evt. hjemmelavede)
Fysisk opstilling: et bord per 4-6 personers hold
● Ekstra plads (et bord eller gulvplads) til at stille det samlede produkt
2 Besøg online LEGO-butik: http://shop.lego.com/en-US/LEGO-Basic-Bricks-Deluxe-6177
5
ROLLER
Produktejer
Som træner påtager jeg mig rollen “produktejer”.
Målet er at illustrere, hvordan produktejeren opfører sig, og hvad de typisk forventer
sig af holdene.
Scrum Masters
Dette spil kan spilles uden dedikerede Scrum Masters, men af og til inviterer jeg andre
instruktører med i spillene for at agere som Scrum Masters. Alternativt kan hvert
hold udnævne en Scrum Master.
Fordelen ved at have erfarne Scrum Mastere med er at de konstant vil være
fokuserede på process, hvilket giver plads til at produktejeren kan være fokuseret på
sin egen rolle, og hele spillet glider mere naturligt.
Holdmedlemmer
Alle andre deltagere er “menige” holdmedlemmer.
Testere - valgfri rolle
Hvis du synes kan du tilknytte testere til holdene. Det vil i så fald være deres ansvar
at hjælpe deres hold med at dokumentere aftaler om krav og design, så de kan lave
kvalitetskontrol.
Problemet ved at have dedikerede testere, som jeg har oplevet det, er at testerne
i stedet for at bygge LEGO bruger deres tid til at overvåge kvalitet. Siden målet
med spillet er at lære ved at “få hænderne beskidte” mener jeg det er vigtigt at få alle
engageret i selve byggeprocessen.
Ingen tilskuere!
Spillet er så sjovt at spille at tilskuere efter min mening vil spilde deres tid. Hvis du
har andre erfaringer hører jeg meget gerne fra dig.
HVAD DU SKAL LÆGGE MÆRKE TIL
6
Adfærd
Jeg har lagt mærke til at deltagerne tager deres arbejdsvaner med ind i legen, og især
under pres ser jeg en tendens til at falde tilbage til at bruge “gammelkendte” metoder
og adfærd.
Dette spil er bevidst designet til at sætte deltagerne under pres, netop for at udstille
dårlige vaner der kan blokere for indlæringen af Agile metoder. Mit mål som træner
er at udstille disse dårlige vaner så alle kan se, hvad de skal være opmærksomme på og
undgå.
Kommunikationstil
Vær opmærksom på “ledere”, “diktatorer”, “højtråbere” og lignende. Det er godt
input til efterfølgende evalueringer og personlig coaching.
Når processen knækker
Hold godt øje med de dele af processen som holdene ikke klarer så godt.
Et eksempel kan være under diskussionen om krav, hvor holdene måske ikke stiller
nok afklarende spørgsmål.
De problemer du identificerer her kan meget vel være problemer, som deltagerne
også vil få i et rigtigt projekt. De skal konkretiseres og fremlægges i evalueringen efter
spillet.
SPILLETS GANG
Simulationen er delt op i tre dele; forberedelse, spillet og efterspillet.
Forberedelse:
● Holddannelse
● Projektdefinition
● Opbyggelse af backloggen
● Estimering
Spillet:
● Iterationsplanlægning
● Selve iterationsafviklingen
● Iterationsevaluering
Efter spillet:
7
●
Slutevaluering
FORBEREDELSE: Holddannelse
Tager 5 minutter.
Denne aktivitet kunne også sagtens være en del af spillet.
Selvorganisering klares nemt ved blot at bede deltagerne organisere sig i grupper af 46 personer og sørge for at hver gruppe har plads til at arbejde.
Dette er god opvarmning fordi der ofte skal ryddes lidt op og flyttes borde omkring.
FORBEREDELSE: Projektdefinition
Dette vil tage 10 minutter. Du har nu været igang i 5 minutter.
Som produktejer har jeg brug for at kommunikere følgende:
1.
2.
3.
4.
5.
Alle hold skal samarbejde om et enkelt produkt. De er altså ikke konkurrenter,
men arbejder for den samme kunde.
Holdene skal bygge en by med en række bestemte detaljer.
De primære byggeklodser er LEGO, selvom andre materialer også gerne må
bruges.
Jeg (produktejeren) er den primære beslutningstager - det er min by..
Jeg står til rådighed for spørgsmål og feedback gennem udviklingsprocessen.
Hele denne aktivitet kan eventuelt køres som “collaborative chartering”.
Målet er at få holdene til at anvende SCRUM gennem byggeprocessen. Udfordringen
er at kombinere disse to roller: en produktejer (der ikke ejer selve processen) og en
underviser (der har interesse i at SCRUM bliver anvendt).
Jeg har prøvet at løse denne udfordring på to forskellige måder:
1.
2.
8
Brug kasketter - forklar SCRUM til holdene
Undervejs i undervisningen gør jeg det helt klart, hvilken kasket jeg har på - om
jeg er produktejer eller underviser - så ingen på noget tidspunkt er forvirrede
over hvilken rolle jeg spiller.
Foregiv at være en “grøn” produktejer – lad holdene overbevise dig om
at bruge SCRUM
For det meste spiller jeg en produktejer, der ikke ved meget om Agile og
SCRUM. Efter at have præsenteret min vision for byen beder jeg om hjælp fra
holdene om at designe en passende process.
Personligt kan jeg bedst lide den sidste tilgang fordi den lader deltagerne artikulere
Agile værdier og derved forstærker indlæringen.
FORBEREDELSE: Opbyggelsen af backloggen
Dette vil tage 15 minutter. Du har nu været igang i 15 minutter.
Når projektet er blevet defineret og der er enighed om processen er det på tide at gå i
detaljer med byen.
Som regel har jeg forberedt en række post-its, som jeg har hængt op på en tavle eller
et flip-over ark.
På disse post-its kan der stå:
● En-etages bygning (flere af disse, een per post-it)
● To-etages bygning (flere)
● Butik
● Skole
● Kirke
● Hospital
● Børnehave
● Busstoppested
● Vejkryds (kan tegnes)
● Park (kan tegnes)
● Flod (kan tegnes)
● Bro
Nogle af disse elementer kan eventuelt tegnes på et stort ark papir (f.eks. fra en flipover), og de tilsvarende LEGO-elementer kan bygges ovenpå.
Det er en god mulighed for at være kreativ og bygge noget underholdende fremfor en
simpel by.
F.eks. byggede vi engang en “IT-by” (inspireret af “Silicon Valley”).
I den inkluderede vi selvfølgelig specielle bygninger som f.eks. et auditorium med
en iPad som “storskærm”, åbne områder, en sikker bygning til webservere og et
monument over en berømt IT entreprenør - det var sjovt!
Imens jeg præsenterer backloggen fortæller jeg kort om hvordan jeg synes hvert
element skal se ud, og forsøger at udsætte diskussioner til senere.
FORBEREDELSE: Estimering
9
Dette vil tage omkring 20 minutter. Du har nu været igang i 30 minutter.
Estimering - på mange måder den sværeste del af øvelsen.
Her kan jeg vælge at:
1.
2.
3.
Droppe estimering helt (som agile guruer faktisk anbefaler)
Gøre det hurtigt og simpelt
Bruge tid på øvelser med planning poker
RT @RonJeffries: "Hvert år hører vi om en ny estimeringsteknik. Den rigtige Agile
tilgang vil være slet ikke at estimere." - @agilemanager [YES!]
Alt efter hvor meget tid, der er til rådighed vælger jeg enten den simple teknik
eller planning poker.
Den hurtige teknik - sortering i “svømmebaner”
Jeg lærte om denne teknik fra www.theagilepirate.net. Min anvendelse er dog knap så
sofistikeret.
Se tegningen nedenfor.
Baseret på “triangulation concept”3 og svømmebanerne (swimlane sizing4) optegner
vi ganske enkelt kolonner med baner og tildeler hver bane forskellige opgavestørrelser
(1, 2, 3, 5, 8, 13, osv. hvis du foretrækker Fibonacci - lidt matematik er altid godt).
Herefter sætter deltagerne opgaverne (user stories) over i de kolonner der passer til
deres størrelser. Dette gøres i grupper eller i plenum og kan evt. gøres i stilhed.
3 “Triangulation and other concepts for Agile estimation and planning”, af Mike Cohn http://
www.mountaingoatsoftware.com/presentations/85-an-introduction-to-agile-estimating-and-planning
4 Swimlane Sizing – Complete & Fast Backlog Estimation
http://theagilepirate.net/archives/109
10
Figur 1: Svømmebanerne for estimering
Hvis der er for mange deltagere til at alle kan være foran tavlen så beder jeg hvert hold
sende to deltagere op af gangen indtil alle har haft mulighed for at komme til.
Når alle opgaver er estimerede spørger jeg alle om det er “godt nok” til at starte med,
og om de er klar til at lave noget rigtigt arbejde nu.
Planning poker med flere hold
At bruge planning poker5 med flere hold kræver at alle deltagere på tværs af holdene
først bliver enige om en grundstørrelse.
Det er simpelt: vælg en opgave, som er lille og enkel, men ikke helt triviel og beslut at
det er en 2’er. Som regel bliver alle hurtigt enige om at bygningen i een etage passer
godt her.
Alternativt kan man lave t-shirt estimater6 (XS, S, M, L, XL) og derefter beslutte at
alle “S” opgaverne er 2’ere og så fortsætte med poker.
Her er nogle tips, der hjælper mig til at få planning poker til at fungere:
● Forbered en tavle med svømmebanerne (se skitsen ovenfor)
5 Planning Poker is found by James Grening in 2002 and popularized by Mike Cohn:
http://en.wikipedia.org/wiki/Planning_poker
6 T-shirt sizing
http://blogs.msdn.com/b/oldnewthing/archive/2009/05/12/9605143.aspx
11
●
●
●
●
●
Bed deltagerne estimere opgaverne een efter een ved at trække dem over i
svømmebanerne.
Bed deltagerne skrive noter på hver opgave efterhånden som de modtager
detaljer og afklaringer fra produktejeren (det kan jo være et andet hold, der
ender med at bygge den opgave).
Aktivt opfordre til og påskønne når deltagere stiller afklarende spørgsmål som
hjælper til at bestemme størrelsen på opgaverne.
Når en opgave er estimeret skal den op på tavlen/væggen, så de andre hold kan
drage nytte af den nye information.
Når alle opgaverne er estimeret inviterer jeg alle til at komme op for at
dobbelttjekke tavlen og evt. ændre det de synes er nødvendigt (det er der
sjældent behov for oplever jeg).
●
Hvis deltagerne ikke kender så meget til planning poker i forvejen kan det være en
god idé at tage en prøverunde først så du er sikker på at de bruger den rigtige teknik.
Som regel beder jeg dem gætte på følgende:
“Hvad koster et stort glas Guinness i Storbritannien?”
Dette tvinger deltagerne til at diskutere hvilke point de skal bruge, hvor glasset
bliver købt samt hvornår – alt sammen god opvarmning før de skal til at estimere
de “rigtige” opgaver.
Det viser sig i øvrigt at begge teknikker, både svømmebanerne og planning poker
giver tilstrækkeligt med præcision for planlægning af udgivelser (releases). Denne
påstand er bevist hundredevis af gange med burn down charts.
SPILLET: Iterationsplanlægning
Du er nu 50 minutter inde i spillet.
(Og intet er bygget endnu! Er det et udtryk for at estimering er spild af tid?)
Nu hvor opgaverne er estimeret flyttes de tilbage til backloggen.
Det er vigtigt at gøre iterationsplanlægningen meget synlig og derfor bygger vi en
speciel tavle/væg, hvor alle kan overskue planlægningen af alle iterationer.
12
Figur 2: Planlægningstavle for flere hold - før planlægning af iteration #1
Figur 3: Planlægningstavle for flere hold - midt i iteration #2
13
Selve planlægningen tidsafgrænses til tre minutter, hvor alle hold trækker opgaver ind i
kassen for deres hold.
Når de tre minutter er gået spørger jeg om alle er tilstrækkeligt ukomfortable med
planen til at vi kan begynde!
SPILLET: Iterationerne
Tager 7 minutter hver.
7-minutters iterationer anbefales da det giver nok tid til at samarbejde om
konstruktionen af nogle bygninger, men ikke nok tid til at færdigpolere dem.
Gennem iterationen viser vi et stopur på en storskærm for at lægge pres på holdene:
Figur 4: Stopur fra www.online-stopwatch.com - ure i andre former kan også findes og
bruges offline.
SPILLET: Iterationsevaluering
Tager 5 minutter.
Når tiden er gået sikrer jeg at deltagerne stopper helt med at bygge og spørger derefter
krævende: “hvor er min by?”
Efter den første iteration oplever jeg ofte at ingen har tænkt på at samle færdige
bygninger på f.eks. et centralt placeret bord, dvs. overvejet hvordan resultatet skal
organiseres og demonstreres indenfor tidsgrænsen - lyder det bekendt? Efter den
første iteration begynder holdene, kloge af skade, typisk at samle byen løbende.
14
Jeg får tit at vide at jeg er den mest venlige produktejer de har arbejdet sammen med.
Alligevel ender det som regel med at intet er accepteret efter første iteration fordi når
jeg ser byen “kommer jeg pludselig i tanke om at”:
●
●
●
●
●
Jeg kan lide symmetri
“Alt i samme farve” betyder faktisk “kun een farve per bygning, men
forskellige farver for hver bygning.”
Bygningerne er for små, for store eller for forskellige.
Vinduerne for hver etage skal være på en lige linie
<find selv på flere grunde>
Ikke-færdige opgaver sættes tilbage til backloggen fra planlægningsvæggen. Man kan
vælge at re-estimere udestående opgaver, selvom det er sjældent vi retter i estimaterne.
Når opgaver er blevet løst tilfredsstillende, og dermed accepteret, opdaterer
produktejeren burndown-chart’et og annoncerer klart og tydeligt at der kun er tre
iterationer ialt og at det nu ser ud som om at det ikke bliver muligt at fuldføre alle
opgaverne.
Brug eventuelt et par minutter på at overveje “hvordan kan vi gøre næste iteration
bedre?”.
SPILLET: Iterationernes cyklus
Den første iteration er næsten altid en katastrofe, så uden at spilde for meget tid på at
diskutere hvor galt det gik går vi igang med planlægningen af næste iteration.
Jeg har erfaret at man med tre iterationer bygger cirka 80% af backloggen i en rimelig
kvalitet, så den fulde cyklus ser omtrent sådan ud:
1.
Iteration #1
a. Planlægning – 3 minutter
b. Selve iterationen – 7 minutter
c. Evaluering – 5 minutter
2.
Iteration #2
a. Planlægning – 3 minutter
b. Selve iterationen – 7 minutter
c. Evaluering – 5 minutter
3.
Iteration #3
a. Planlægning – 3 minutter
b. Selve iterationen – 7 minutter
c. Evaluering – 5 minutter
Ialt: 45 minutter
15
Eftersom forberedelserne tager cirka en time og iterationerne tager 45 minutter, er der
omkring 15 minutter tilbage til en generel evaluering. Hele spillet tager fra start til
slut 120 minutter.
Med øvelse og assistance fra hjælpetrænere, der agerer som Scrum Mastere, kan
spilletiden nedbringes lidt.
EFTER SPILLET: Slutevaluering
Det kan være en god idé at afsætte tid til en kort pause efter at den tredje iteration er
evalueret, så alle kan køle lidt ned og samle sig inden vi begynder slutevalueringen (fik
jeg sagt at spillet er designet til at være udmattende? Og ikke kun for deltagerne...)
Når alle er tilbage i en cirkel faciliteres en diskussion om disse åbne spørgsmål:
● Hvad observerede deltagerne?
● Hvordan føles det at være en del af et SCRUM-hold?
● Hvordan var det at have korte iterationer?
● Hvor præcise var estimaterne? (forudsat at der blev vedligeholdt et burndownchart)
● Hvad ville vi have gjort anderledes fra starten hvis vi fik mulighed for at spille
spillet forfra?
● Hvad var produktejerens job?
● Hvordan føles det at skulle lave så meget om efter den første iteration?
● Hvad lavede Scrum Masterne?
● Hvad vil du gøre anderledes hvis du ved at produktejeren er fraværende i løbet
af iterationerne?
● Hvordan gik det med kommunikationen mellem holdene? Var der situationer,
hvor et hold afhang af et andet? Hvordan blev problemerne løst?
● Hvad har deltagerne lært?
VARIATIONER
Uventede påvirkninger
Nogle af mine venner (Askhat Urazbaev og Nikita Filippov) har designet et lignende
spil, som tilføjer uventede påvirkninger til holdstørrelserne og kompleksiteten.
Efter iterationsplanlægningen og lige inden hver iteration begynder kaster man
ganske enkelt en terning, som enten ændrer estimaterne på en opgave eller gør et
af holdmedlemmerne “syge” for en iteration, men stadig kræver at holdet fuldfører
iterationen efter planen.
Pointen ved at tilføje disse tilfældige ydre påvirkninger er at samarbejde bliver
16
essentielt for at kunne balancere opgaverne.
Enterprise Scrum
Det lykkedes mig at opskalere simulationen med LEGO til omkring 100 deltagere i 12
hold, der byggede fire byer samtidigt. Det krævede tonsvis af LEGO, men det var en
god måde at demonstrere SCRUM på enterprise niveau. Erfaringer og detaljer herfra
gav mig nok stof til en helt ny artikel.
Lad os høre om dine erfaringer
Vi hører meget gerne fra dig om dine egne erfaringer - historier fra kurser og
eventuelt dine egne variationer af spillet. Find os på www.lego4scrum.com og send emails med dine idéer til [email protected].
17
TAK!
Jeg ønsker dig masser af gode projekter - fyldt med leg!
Alexey Krivitsky
www.lego4scrum.com
18