Scrumsimulation med LEGO klossar

En produktorienterad Scrumsimulation med LEGO klossar Denna utgåva är anpassad för små och medelstora affärsrörelser. Simulationen är möjlig att anpassa för utbildning i andra iterationsbaserade agila utvecklingsramverk. Originalutgåvan är publicerad i februari 2009 Författare: Aleksey Krivitsky Senaste version 2.0, utgiven oktober 2011 Översatt till Svenska av Erik Hamrin, erik.hamrin@gmail.com Detta verk är tillgängligt under följande licens; Creative Commons Attribution 3.0 Unported license

Innehåll Scrumsimulation med LEGO klossar... 1 Förord... 3 Varför en Legobaserad simulator?... 3 Författarens tack... 4 Nuvarande version... 4 Licensieringen av detta arbete... 4 Webbcommunity och översättningsprojektet... 4 Spelet... 5 Tidsåtgång, teamens storlek och material... 5 Roller... 5 Saker att titta efter... 6 Spelets olika stadier... 7 Innan spelet... 7 Pågående spel... 12 Efter avslutat spel... 15 Variationer av spelet... 16

Förord Varför en Legobaserad simulator? Under de senaste åren har jag varit med och hållit ett dussin scrumkurser, både certifieringar och icke certifierande utbildningar. Alla dessa kurser har haft olika moment som simulerar exekveringen av scrum, men jag har alltid tyckt att det borde finnas bättre verktyg för detta. Nedan listar jag de attribut som, enligt min åsikt, ett minimalt spel/verktyg för scrumutbildning borde ha. Öppen backlog som ger upphov till idéer istället för detaljerade instruktioner att följa Vi vill börja spelet med en öppen backlog. Det inbjuder till samarbete mellan kunderna och teamet. En backlog kan förberedas av de som håller i utbildningen, men de ska inte vara stängda och överdrivet detaljerade. Det kommer att påminna för mycket om det gamla hederliga ledarskapsstilen command and control. Vi vill lära ut och demonstrera en helt annan typ av relation mellan kunderna och de utvecklare som ska omsätta kundernas önskan till en produkt. Genomtänkt produktutveckling istället för en lista av uppgifter som ska utföras Vi behöver lära ut produktutveckling, och inte hur man bedriver managment på mikronivå. Därför ska inte backlogs eller instruktioner bestå av en lista av exakta steg som ska göras. De ska snarare vara visionen av den färdiga produkten det överliggande målet för teamet. Team som jobbar för gemensam framgång istället för team som tävlar för högst poäng Spelet bör gå att skala till kurser med 20 deltagare eller fler. Detta innebär att gruppen ska delas upp i olika lag. Det ger en möjlighet för deltagarna att öva sina färdigheter i samarbete mellan olika team. Att verka för samarbete måste ofta göras explicit eftersom team som inte får instruktioner att samarbeta ofta börjar betrakta varandra som konkurrenter om resurser. Användabara mått som visar på fördelarna med agile istället för mått som kursledarna ber att få Alla mått som man efterfrågar måste tydligt vara knutna till något som teamen tjänar på att notera. Detta för att spelet syftar till att lära teamen hur deras egen process bör se ut. Löpande förbättringar istället för att vinna eller förlora spelet Spelet bör vara utformat så att teamen för flera chanser att spela det. Varje spel genererar lärdomar och ger möjlighet att identifiera förbättringar till befintliga processer.

Författarens tack Tidigt under 2009 hjälpte Mykola Gurov mig att förstå potentialen hos Lego som ett API 1 för simuleringar av produktutveckling. Senare samma år skapade jag en tidig version av detta spel som hette Lego for extended scrum simulation. Detta gjordes efter diskussioner med William Wake, Jurgen De Smet, Yves Hanoulle och Xavier Quesada Allue. Sedan den första publiceringen på Scrum Alliance hemsida har jag fått dussintals mejl som uttrycker uppskattning av detta arbete. Nu skulle jag vilja ta detta tillfälle i akt för att i min tur tacka alla som har kontaktat mig för att dela sina idéer och erfarenheter av att köra dessa simulationer. Gerry Kirk, Tim Yevgrashyn, Steve Rogalsky, Andriy Yevtushenko, Geoff Watts, Laurent Godé, Radu Davidescu, Martine Devos, Jo Newcombe Cook, Jakob Frandsen, Martin Müntzing, Ola Ellnestam, Dusan Kocurek, Danny (Danko) Kovatch, Gustavo Quiroz, Jukka Lindström, Eduardo Bregaida, and Nathaniel Cadwell. Särskilt vill jag tacka Robin Dymond och Sergey Dmitriev för att jag fick använda detta spel som en del i deras kurser för att certifiera scrum masters. Nuvarande version Sedan detta arbete publicerades under 2009 har flertalet coacher använt detta spel. Den nuvarande, förbättrade, versionen av simulationen som beskrivs i detta dokument reflekterar vissa delar av den feedback jag fått och de observationer som gjorts av dessa coacher. Licensieringen av detta arbete Denna utgåva distribueras under Creative Commons Attribution 3.0 Unported License Denna licens tillåter andra att distribuera, förändra samt bygga vidare på originalverket, för såväl privata som kommersiella syften. Detta är förbehållet kravet att man ger upphovsmannen erkännande för hans eller hennes verk vid varje publicering. Detta är en av de mest tillåtande licenser som finns. Den rekommenderas i de fall då upphovsmannen vill uppnå så stor spridning och användning av verket som möjligt. Webbcommunity och översättningsprojektet Vi har beslutat att skapa en plats som personer som är intresserade av att lära ut scrum med Lego som ett hjälpmedel kan besöka och samarbeta via; www.lego4scrum.com Gå med i vår community och hjälp oss sprida detta arbete. 1 Osäker på vad API betyder? Kolla; http://sv.wikipedia.org/wiki/application_programming_interface

Ett av de pågående projekten i vår community är att översätta detta arbete till olika språk. Kolla hur det går, och fundera på om du vill hjälpa till. Alla insatser uppskattas väldigt mycket. Spelet Tidsåtgång, teamens storlek och material Man har provat att anpassa spelet till olika utbildares specifika behov och för spel med deltagargrupper av olika storlekar. Nedan beskrivs spelet i sitt standardutförande, men användare uppmanas att anpassa och omforma spelet så att det passar deras specifika behov. Tidsåtgång: 100-120 minuter 100 minuter Vid användande av snabbare estimeringstekniker 120 minuter Vid användande av planeringspoker eller liknande estimeringstekniker Deltagarantal: 2-25 personer Ideala förutsättningar är 2-3 team med 4-6 personer i varje (8-18 deltagare) Man kan utöka antalet deltagare utöver detta antal genom tillägg av scrum masters LEGO: En förpackning lego räcker till ett team på 4-6 personer I normalfallet används Basic Brick Set #6177 2 På 20 personer så räcker 4 förpackningar med Lego Övrigt: Vanligt presentationsmaterial Post- its, blädderblock, merkeringspennor, whiteboardpennor Kortlek för planeringspoker ( eller hemmagjorda dito) Lokal: Ett arbetsbord till varje team Extra utrymme (ett bord eller golvyta) för den kompletta produkten är trevligt Roller Produktägare Som kursledare är det jag som spelar produktägarens roll. 2 Besök LEGOs webshop; shop.lego.com/en- SE/

Målet med detta är att visa hur produktägare agerar, vilka förväntningar och krav de generellt sett har samt vilka typer av beteenden från ett team som de uppskattar och vilka de inte uppskattar. Scrum master Detta spel kan spelas utan dedikerade scrum masters. Om man önskar lägga till denna funktion i spelet så görs det bäst genom att låta erfarna scrum coacher fyller dessa roller. Man kan även be medlemmar i teamet att vara scrum masters under övningen. Om man har möjligheten att ha coacher som scrum masters så kan de fokusera på just processen och arbetsflödet, medan kursledaren kan spela rollen som produktägare. Detta ger spelet ett mer naturligt flöde vilket leder till att spelet uppfattas enklare och klarare. Teammedlemmar Kursdeltagarna utgör teammedlemmarna. Testare varlfri roll Du kan utse testare inom teamen. Deras huvudsakliga ansvar blir att hjälpa utvecklarna att dokumentera de överenskomna kraven på design så att de kan göra acceptanstest av det som utvecklarna levererar. En negativ effekt som jag upplevt är att testarna inte bygger LEGO utan bara utvärderar vilken kvalitet det som levereras har. Eftersom målet med ett spel som detta är att lära genom att prova sig fram, så tycker jag att det är vettigare att uppmuntra alla deltagare i teamet i själva byggandet. Det som händer annars är att man delar upp teamet i två funktioner på ett väldigt strikt sätt, något som man inom agila utvecklingsmetodiker försöker undvika. Tillåt inga observatörer Spelet är i sig så roligt att spela att, enligt min mening, någon som tittar på snarare förlorar än vinner något på detta. Om ni inte anser att så är fallet så vill jag gärna hör era berättelser om varför. Saker att titta efter Beteenden Från mina observationer drar jag slutsatsen att vissa beteenden som deltagare visar upp under spelets gång är indikationer av vanor i en arbetssituation. Under stressiga förhållanden tenderar människor att falla tillbaka på sina naturliga beteenden. Detta spel är medvetet utformat för att vara just stressigt, så att det kan exponera dåliga vanor som skulle kunna hindra eller rent av skada anpassningen av en befintlig verksamhet till agila värderingar. Mitt mål som ledare och coach är att peka ut dessa beteenden inför gruppen och vända dem till någonting som gruppen lär sig av och lär sig hålla utkik efter.

Kommunikationsstilar Var uppmärksam på följande stilar; chefen, diktatorn, gaphalsen och liknande projektioner. Det är ett bra område att ta upp under samtalet efter ni har spelat och kan också vara ett bra område för personlig coachning av dessa individer. Scrum handlar om teamet, inte om vem som helst vill bestämma vad andra ska göra. Icke fungerande processer Håll ögonen öppna och leta efter de steg i processen som teamen kan bli bättre på. Till exempel, under den del av sprintplaneringen som handlar om att definiera uppgifter så kanske inte teamet ställer så många frågor som de behöver göra för att skaffa sig en korrekt bild av de user stories som tillhör sprinten. Det är sannolikt att teamet har detta problem, eller kommer att ha detta problem, inom någon del av det riktiga projektet. Det är därför viktigt att ta med dessa potentiella problemytor i den debrief som man gör efter spelet. Spelets olika stadier Detta spel har tre olika delar; innan spelets start, själva spelandet och debriefen efter dess avslut. Innan spelet Organisera de team som deltar Definiera processen som ska följas Projektinformation Skapa en backlog Estimera arbetsåtgång för ingående user stories Pågående spel Sprintplanering Sprintexekvering Sprintutvärdering Releasecykel Efter avslutat spel Debrief Innan spelet Organisera de team som deltar Tidsåtgång: 5 minuter Denna del av förberedelserna kan med fördel betraktas som en del själva spelet, det är ett lärande i sig.

För att visa på att scrum vill ha team som är självorganiserande på alla sätt så brukar jag be gruppen att dela in sig i grupper om 4-6 personer och förse sig själva med en arbetsplats. Projektinformation Tidsåtgång: 10 minuter. Du är nu 5 minuter in i spelet Som kursledare spelar jag rollen som produktägare och jag behöver förmedla följande information om det projekt som teamen nu ska jobba inom; 1. Alla team jobbar med ett och samma projekt det är inte en konkurrenssituation utan ett samarbete åt gemensam beställare 2. Produkten är en stad med vissa specifika byggnader och funktioner 3. Huvudsakligt byggnadsmaterial är LEGO, men det är tillåtet att använda andra material utöver detta. 4. Produktägaren är beslutsfattare gällande produkten det är min stad 5. Som produktägare kommer jag att vara tillgänglig under utvecklingsprocessen för att svara på frågor och ge feedback på det som levereras Att köra denna aktivitet som collaborative chartering kan vara en bra idé. Mitt mål är att se till att teamen praktiserar scrum när de bygger produkter med LEGO. Det som är lite svårt är att kombinera mina två roller. Dels är jag produktägare där jag bara drivs av dennes värderingar vilka inte fokuserar primärt på processen och dels är jag kursledare med målet att lära gruppen hur just den processen fungerar. Det finns många olika sätt som jag har provat att göra detta; 1. Genom att byta hatt förklara scrum regler för teamet Jag är tydlig och berättar explicit om jag talar i rollen som produktägare eller kursledare så att deltagarna vet vem de pratar med 2. Nybliven produktägare låter teamet sälja idén med scrum till mig Oftast agerar jag som en produktägare som inte vet så mycket om scrum eller agile. Jag presenterar min vision av staden och ber teamet om hjälp med att ta fram en agil process. Personligen så föredrar jag den sista metoden eftersom den förstärker inlärningsprocessen för deltagarna då de får öva sig på att förklara de värderingar som ligger bakom agil utveckling. Skapa en backlog Tidsåtgång: 15 minuter. Du är nu 15 minuter in i spelet. När ni har skissat upp en plan för projektet och kommit fram till hur processen ska se ut så är det dags att presentera informationen om hur staden ska se ut.

Normalt så gör jag detta genom att visa teamet en förberedd uppsättning av post- its på ett blädderblockspapper. Vanligtvis ingår följande objekt; Envåningshus (Ett flertal, en per post- it) Tvåvåningshus (Ett flertal) Affär Skola Kyrka Sjukhus Dagis Busshållplats Vägkorsning Park Vattendrag Bro Några av dessa objekt kan ritas direkt på blädderblocksblad och sedan ställs LEGO- objekten på dessa blad. Denna del av spelet tillåter dig som kursledare att vara hur kreativ som helst, för att bygga något mer underhållande än en vanlig stad. En gång när jag spelade detta med ett startup- team så byggde vi en Silicon Village. Självklart blev listan över saker som skulle byggas då lite annorlunda. Vi behövde ha en aula med en skärm för presentationer (som byggdes av en ipad), ett knippe öppna kontorlandskap på olika ställen i staden, en säkrad byggnad för våra webservrar samt ett hjältemonument över en entreprenör (ett pråligt monument on rails ). Det blev ett roligt projekt! Medan jag presenterar backlogen så förklarar jag i korthet hur jag tycker att varje del borde se ut. Vidare diskussioner och frågor försöker jag senarelägga till estimeringsdelen. Estimera arbetsåtgång för ingående user stories Tidsåtgång: Upp till 20 minuter. Du är nu cirka 30 minuter in i spelet Att uppskatta arbetet som föreligger är, av någon anledning, den svåraste uppgiften. Det är möjligt att jag vill: 1. Hoppa över estimaten (som gurus inom Agile skulle rekommendera) 2. Förenkla processen så det går snabbare 3. Spendera lite tid på att köra planning poker RT @RonJeffries: Every year there is a new estimation technique. The real Agile approach would be to throw estimations out. - @agilemanager [YES!]

Beroende på hur mycket tid jag har till mitt förfogande brukar jag välja mellan den enklaste tekniken för estimering eller planeringspoker. Den snabbaste tekniken swimlane sizing Denna teknik kommer från www.theagilepirate.net. Tydligen utövar jag denna teknik på ett mindre sofistikerat sätt. Se skissen nedan. Baserat på the triangulation concept 3 och swimlane sizing 4 ordnar vi helt enkelt kolumner för att rymma olika storlek på user stories. 1, 2, 3, 5, 8, 13 och så vidare om du föredrar Fibonacci, lite vetenskap är aldrig fel. Sedan får teamdeltagarna helt enkelt sätta de olika uppgifterna i den swimlane som de tycker representerar tiden som det kommer att ta att genomföra uppgiften. Det steget kan göras i de olika teamen eller tillsammans som en stor grupp. Det kan också utföras under tystnad. Figur 1: Swimlanes vid estimering i grupp Om gruppen är för stor för att alla ska få plats vid tavlan samtidigt så ber jag varje team skicka fram ett par var. När denna grupp är klar kommer nästa grupp fram, tills alla har fått en chans att jobba vid tavlan. 3 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 4 Swimlane Sizing Complete & Fast Backlog Estimation http://theagilepirate.net/archives/109

När alla fått denna chans frågar jag gruppen av kursdeltagare i sin helhet om detta är bra nog till att börja med, och om de skulle vilja göra lite riktigt arbete nu. Planeringspoker med flera team Att köra planeringspoker 5 med flera team kräver att teamen först enas om ett storleksexempel på en uppgift. Att göra detta är relativt enkelt. Välj någon uppgift ur backlogen som är liten och tämligen enkel (utan att vara trivial) och tilldela den värdet 2. Normalt sett går alla med på att envåningshusen är tvåor. En annan metod som kan användas är att använda estimering efter t- shirtstorlekar 6 (XS, S, M, L, XL). Markera alla stories som får värdet S som tvåor och fortsätt sedan med planeringspokern. Jag skulle vilja dela med mig av tips som har hjälpt mig att få estimeringsövningar med multipla team att fungera bra; Organisera swimlanes på en vägg som beskrivet ovan Be teamen att uppskatta en user story i taget Be teamen att lägga till ytterligare information på varje user story allt eftersom de får den från produktägaren (eftersom det kanske blir det andra teamet som tar uppgiften) Uppmuntra och visa uppskattning när teammedlemmar ber om klargöranden för att bättre kunna avgöra uppgiftens storlek Så fort ett estimat är färdigt för en user story måste den upp på väggen igen så att andra team kan ta del av den nya informationen Innan ni avslutar övningen så be alla att komma upp och göra en sista kontroll av tavlan så att den vettig (en sanity check). Min uppfattning är att förändringar sällan görs vid denna kontroll. Om deltagarna inte vet hur planeringspoker går till så är det värt att köra en testrunda med något estimat som inte tillhör uppgiften. Det ger dig som kursledare en chans att kontrollera så att deltagarna använder tekniken korrekt eller lär sig använda den. Jag brukar be teamen göra en uppskatta/gissa följande; Hur mycket kostar en pint Guinness i Storbritannien? 5 Planeringspoker skapades av James Grening 2002 och gjordes populärt av Mike Cohn; http://sv.wikipedia.org/wiki/planning_poker 6 T- shirt sizing; http://blogs.msdn.com/b/oldnewthing/archive/2009/05/12/9605143.aspx

Syftet är att köra denna övning är att uppmuntra deltagarna att ställa frågor om hur poängen används, vart ölen skulle köpas och när. Det är en bra uppvärmning och visar hur viktigt det är att ställa frågor om alla saker som ska göras så att man har rätt uppfattning av uppgiften innan man sätter igång produktionen. Intressant nog så har båda teknikerna, swimlane sizing och planning poker, tillräckligt bra precision för att man ska kunna göra tillförlitliga releaseplaner baserat på dem. Detta har bevisats över tid genom flera hundra release burndown- kartor. Pågående spel Sprintplanering Tidsåtgång: 3 minuter. Du är nu cirka 50 minuter in i spelet. Så vi har använt 50 minuter, och vi har inte byggt någonting än? Skulle ni säga att det är nog med bevis för att estimering är slöseri med tid? Nu när alla user stories är estimerade så ska de flyttas från sina swimlanes till vår backlog. Eftersom vi vill att det ska vara mycket tydligt vad det är som vi jobbar med så skapar vi en speciell yta där vi kan samla alla olika teams planer för de alla sprinter som vi ska köra under spelets gång. Den kan se ut som bilden nedan; Figur 2: En planeringsvägg för multipla team innan sprint #1 planerats

Figur 3:En planeringsvägg för multipla team under pågående sprint #2 Vi kör sprintplaneringen som en kort timebox på tre minuter. Under denna tid så ber vi teamen att plocka userstories in i sina sprintboxar. När det är klart så frågar man om teamen känner sig obekväma nog sina planer för att försöka sig på att jobba efter dem. Sprintexekvering Tidsåtgång: 7 minuter Vi föredrar en sprintlängd på sju minuter, det brukar ge tillräckligt med tid för teamen att bygga ett par av de saker som de planerat om de samarbetar. Det är dessutom tillräckligt lite tid för att de inte ska hålla på och finslipa på sina user stories allt för länge. För att skapa en lite starkare känsla av stress så brukar vi köra ett stort tidtagarur på en projektor eller laptopskärm. Denna måste stå så att teamen tydligt kan se denna utan att behöva gå från sina arbetsplatser.

Figur 4: På www.online- stopwatch.com hittar man tidtagarur i olika utföranden som kan användas offline Sprintutvärdering Tidsåtgång: 5 minuter När tiden för sprinten tar slut, brukar jag se till att deltagarna omedelbart slutar att bygga. Sedan börjar jag fråga; Ok, var är min stad? Det jag har noterat är att det är först under den andra sprinten som teamen börjar kontinuerliga leveranser av färdiga user stories till demoarean (en karta som ritats på blädderblockspapper). Så i de flesta fall är det ingen som under den första sprinten tänker på att det är teamets uppgift att sätta ihop en demo. Låter det som något ni känner igen från verkliga projekt? Jag brukar få kommentarer under de debriefer som jag kör att jag är den snällaste produktägaren som någonsin skådats. Detta till trots så brukar det efter den första sprinten vara väldigt få saker som accepteras av mig som produktägaren. När jag får se byggnaderna så brukar jag komma på att; Jag gillar symmetri eller assymetri, beroende på vad som är vanligast Alla hus ska ha samma färg betyder egentligen En färg på varje hus, men olika färger på varje. Husen är för stora, för små eller för enhetliga Fönstren sitter inte där de borde <Sätt in egna påhittade fel här> De jobb som på grund av detta inte anses färdiga av mig som mottagare sätts tillbaka på vår planeringsvägg. Kvarvarande jobb kan man göra nya estimat för, men när jag kör spelet så görs detta sällan. Allt eftersom user stories accepteras av produktägaren så uppdaterar denne teamets burndown- graf. Eftersom så mycket måste göras om efter sprint ett så passar

produktägaren här på att göra ett uttalande om att man förmodligen inte kommer att klara av målet att lösa att uppgifter som man tagit på sig inom detta projekt. Innan klockan startas för nästa sprint så spenderar man lite tid på att fundera över vad man vill förändra inför nästa sprint. Detta blir ett slags litet mini- retrospektiv, och det är viktigt att påpeka detta för deltagarna så att det förstår vilket steg i processen som det är man arbetar med. Releasecykel Utan att spendera allt för mycket tid på att diskutera vad som gick fel i sprint #1, eftersom den oftast är en katastrof och ska visa på vanliga felsteg, så hoppar vi tillbaka till sprintplaneringssteget för sprint #2. Jag har insett att det i normalfallet tar tre sprintar för att bygga 80% av backlogen med tillräckligt bra kvalitet. Därför ser körschemat för spelet ut så här; Sprint #1 a. Planering 3 minuter b. Sprintning 7 minuter c. Granskning 5 minuter Sprint #2 a. Planering 3 minuter b. Sprintning 7 minuter c. Granskning 5 minuter Sprint #3 a. Planering 3 minuter b. Sprintning 7 minuter c. Granskning 5 minuter Total tidsåtgång: 45 minuter Eftersom det tar ungefär en timme (från skapandet av vår projektplan till en estimerad backlog) och vårt sprintande tar 45 minuter så har man ungefär 15 minuter på sig att köra debrief. Hela spelet tar cirka två timmar i detta utförande. Om kursledaren är erfaren, deltagarna har spelat tidigare eller om det finns hjälp att få i form av utbildade scrum masters, så kan man spela det hela lite snabbare. Efter avslutat spel Debrief Efter att man avslutar den sista sprinten och dess retrospektiv kan det vara klokt att ta en kortare paus innan man börjar med debriefandet. Det kan lugna ner deltagarnas känslor och ge alla lite tid att återhämta sig. Nämnde jag att spelet är ganska stressigt och påfrestande? Det gäller inte enbart för teammedlemmarna.

När vi sedan samlas sätter jag ofta deltagarna i en cirkel, och hjälper till att moderera en diskussion kring följande frågor; Vad upplevde deltagarna? Hur kändes det att vara utvecklare i ett scrumteam? Hur gick sprinterna?` Hur väl överensstämde estimaten med utfallet? o Denna fråga kräver att ni har burndown- grafen tillgänglig. Vad skulle ni ha gjort annorlunda om vi hade börjat om nu? Vad är produktägarens jobb/uppgift? Hur kändes det när nästan alla user stories i första sprinten krävde omarbete? Om scrum masters har deltagit, vad bidrog dessa med? Hur skulle ni förändra er strategi om ni visste att produktägaren inte är tillgänglig under sprinten? Hur hanterade ni kommunikation inom teamet? o Vilka beroenden såg ni och hur hanterade ni dessa? Vad har ni lärt er? Variationer av spelet Fluktuationer Ett par av mina goda vänner (Askhat Urazbaev och Nikita Fillipov) har designat ett liknande spel, som inkluderar slumpartade variationer i teamets storlek och tillgänglighet. För att få till dessa variationer så gör man, efter sprintplanering och före sprintstart, en multiplicering av estimaten satta på varje user story som teamet har tagit på sig, eller plockar ut en teammedlem som sjuk och därför frånvarande. Trots detta förväntar man sig att teamet ska nå sprintmålet i tid. När man jobbar med sådana variationer blir det ännu viktigare än tidigare att förorda samarbete över teamgränser för att distribuera uppgifter mellan alla i projektet, eftersom det blir tydligt att saker inte alltid blir som man hade tänkt sig. Scrum inom storskaliga operationer Jag har skalat denna simulation med LEGO till att köra med 100 deltagare uppdelade på 12 lag. Dessa lag byggde fyra olika städer samtidigt. Det krävdes ett par ton med LEGO, men det verkar vara ett fungerande sätt att visa hur scrum kan se ut när det bedrivs inom en stor organisation Har du en variation på spelet? Berätta om den! Vi är väldigt intresserade av era berättelser och variationer av simuleringen. Gå med oss på www.lego4scrum.com och skicka oss dina idéer via epost till info@lego4scrum.com.

Tack för att du vill spela lego4scrum! Alexey Krivitsky www.lego4scrum.com