Symulacja Scrum przy użyciu LEGO

Obejmująca wiele zespołów, pełny cykl i zorientowana na produkt Symulacja Scrum przy użyciu LEGO Edycja dla małych i średnich firm Może być dostosowana do innych metod Agile opartych na iteracjach. Oryginalnie opublikowano w lutym 2009 Autor: Alexey Krivitsky Aktualna wersja 2.0, październik 2011 info@lego4scrum.com Tłumaczenie na j. polski - Marcin Niebudek, luty 2012 Ten artykuł udostępniany jest na licencji Creative Commons Attribution 3.0 Unported License 1

2 WSTĘP DLACZEGO SYMULACJA Z LEGO? PODZIĘKOWANIA BIEŻĄCA WERSJA LICENCJA SPOŁECZNOŚĆ I TŁUMACZENIE GRA CZAS TRWANIA, ROZMIAR GRUP, MATERIAŁY ROLE Właściciel Produktu Scrum Masterzy Członkowie zespołu Testerzy - Opcjonalnie Nie dopuszczaj obserwatorów CO NALEŻY OBSERWOWAĆ Zachowania Style komunikacji Załamujący się proces ETAPY GRY WSTĘP: Formowanie zespołów WSTĘP: Formowanie wizji WSTĘP: Budowanie backlogu WSTĘP: Szacowanie Najszybsza technika Swimlane sizing Planning poker z wieloma zespołami GRA: Planowanie sprintu GRA: Wykonanie (Sprint) GRA: Ocena efektów sprintu GRA: Cykl ZAKOŃCZENIE: Podsumowanie MODYFIKACJE Dokładanie zmiennych warunków Scrum korporacyjny Masz własną modyfikację? Daj nam znać. DZIĘKUJĘ!

WSTĘP DLACZEGO SYMULACJA Z LEGO? Przez ostatnie kilka lat miałem okazję prowadzić wiele szkoleń Scrum, zarówno tych kończących się certyfikatem, jak i tych bez certyfikatu. Wszystkie te szkolenia obejmowały różnego rodzaju symulacje, ale zawsze miałem wrażenie, że powinny być one lepsze. Poniżej przedstawiam minimalną listę aspektów jakie powinna, według mnie, obejmować gra symulująca Scrum. 1. OTWARTY BACKLOG STYMULUJĄCY NOWE POMYSŁY ponad SZCZEGÓŁOWE INSTRUKCJE, ZA KTÓRYMI NALEŻY PODĄŻAĆ Chcemy rozpocząć grę z otwartym backlogiem jako zaproszenie do współpracy między klientem a zespołem. Backlog może zostać wcześniej przygotowany przez trenerów, ale nie powinien być zamknięty i precyzyjnie określać zrób to, a później zrób tamto. To może brzmieć jak stare dobre podejście dowodzenia i kontroli (ang. command and control). Chcemy przedstawić i nauczyć kompletnie nowego rodzaju współpracy między klientami a zespołami. 2. UWAŻNY ROZWÓJ PRODUKTU ponad SERIĘ ZADAŃ DO UKOŃCZENIA Powinniśmy uczyć rozwoju produktu, a nie mikro-zarządzania na poziomie poszczególnych zadań. Zatem backlog czy instrukcje (do samej gry, przyp. tłum.) nie powinny składać się z listy zadań, ale raczej powinny stanowić wizję produktu - szersze spojrzenie na to co ma zbudować zespół. 3. WSPÓŁPRACA PODCZAS OSIĄGANIA WSPÓLNEGO CELU ponad RYWALIZACJĘ O WYNIK GRY Gra powinna dać się skalować tak aby pasowała do szkoleń dla więcej niż 20 osób. To oczywiście oznaczać będzie podział grupy na mniejsze zespoły. Może to być jednak szansa na przećwiczenie umiejętności współpracy między zespołami. Podział na wiele zespołów powinien być robiony rozważnie, ponieważ bez 3

konkretnych wskazówek naturalnym jest, że zaczną one rywalizować ze sobą (zamiast współpracować - przyp. tłum.) 4. UŻYTECZNE METRYKI DO OCENY ZALET AGILE ponad SUCHE DANE, O KTÓRE PROSZĄ TRENERZY Wszystkie metryki, o których zbieranie proszą trenerzy, powinny stanowić oczywistą pomoc dla zespołu, ponieważ gra powinna nauczyć uczestników kształtowania własnego procesu. 5. CIĄGŁE DOSKONALENIE UMIEJĘTNOŚCI ponad WYGRANĄ CZY PRZEGRANĄ W PIERWSZYM PODEJŚCIU Gra powinna być tak zaprojektowana, aby zespół mógł zagrać w nią wielokrotnie. Każda nowa sesja gry powinna dostarczać materiału do kolejnych ulepszeń procesu jaki symuluje zespół. PODZIĘKOWANIA Na początku 2009 roku Mykola Gurov pomógł mi dostrzec potencjał LEGO jako API 1 dla symulacji rozwoju produktów. Później tego samego roku, po dyskusjach z Williamem Wake iem, Jurgenem De Smet, Yves em Hanoulle oraz Xavierem Quesadą Allue, stworzyłem wczesną wersję gry o nazwie LEGO w zaawansowanej symulacji SCRUM (tyt. oryginalny LEGO for extended SCRUM simulation ). Od czasu pierwszej publikacji na stronach Scrum Allience otrzymałem wiele wiadomości e-mail ze słowami uznania za to opracowanie. W tym miejscu chciałbym dla odmiany skorzystać z szansy na podziękowanie wszystkim, którzy skontaktowali się ze mną aby podzielić się swoimi doświadczeniami z przeprowadzonych w ten sposób symulacji: 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. Specjalne podziękowania kieruję do Robina Dymonda i Sergeya Dmitrieva, którzy pozwolili mi przeprowadzić tę grę podczas ich kursów Certified Scrum Master. 1 Nie jesteś pewien co to API? Sprawdź http://en.wikipedia.org/wiki/application_programming_interface 4

BIEŻĄCA WERSJA Od czasu publikacji pierwszego dokumentu w 2009 roku, wielu trenerów wypróbowało tę grę. Bieżąca, udoskonalona, wersja opisanej tutaj symulacji odzwierciedla zgłoszone przez nich komentarze i obserwacje. LICENCJA Ten artykuł udostępniany jest na licencji Creative Commons Attribution 3.0 Unported License Ta licencja zezwala innym na rozprzestrzenianie, remiksowanie, zmienianie Twojego utworu, nawet do celów komercyjnych, pod warunkiem, że zaznaczą, że jesteś autorem oryginału. Jest to najbardziej pojemna z oferowanych licencji. Zalecana dla maksymalnego udostępnienia i użytku licencjonowanego materiału. SPOŁECZNOŚĆ I TŁUMACZENIE Zdecydowaliśmy się stworzyć miejsce gdzie ludzie zainteresowani uczeniem Scrum przy pomocy LEGO mogą zajrzeć i wymienić się doświadczeniem. www.lego4scrum.com - Dołącz do nas i pomóż rozpowszechnić tę grę. Jednym z trwających obecnie projektów prowadzonych przez naszą społeczność jest tłumaczenie tego artykułu. Sprawdź zaawansowanie tych prac i rozważ pomoc w tym przedsięwzięciu. Naprawdę doceniamy Twój wysiłek. 5

GRA CZAS TRWANIA, ROZMIAR GRUP, MATERIAŁY Zostało już sprawdzone, że grę można zaadaptować do różnych potrzeb trenerów oraz dla różnych ilości uczestników. Standardowa gra została opisana poniżej, ale zachęcamy do dostosowania jej do własnych potrzeb. Czas gry: 100-120 minut 100 minut - jeśli używana jest technika szybkiej estymacji zespołowej 120 minut - jeśli używamy gry planning poker lub innej podobnej Rozmiar grupy: 4-25 osób Idealnie 2-3 zespoły po 4-6 osób (co daje 8-18 osób) Można rozszerzyć o Scrum Master ów Zestawy LEGO: pudełko LEGO na zespół 4-6 osobowy Używam zestaw podstawowy o numerze #6177 2 Potrzeba czterech takich zestawów na 20 osób Rekwizyty: standardowy pakiet szkoleniowy Karteczki samoprzylepne, papier do flipchartów, markery Karty do planning pokera (mogą być zrobione ręcznie) Wyposażenie sali: stół dla każdego zespołu 4-6 osobowego Dodatkowa przestrzeń (stół lub miejsce na podłodze) dla finalnego produktu jest bardzo pomocna ROLE Właściciel Produktu Rolę właściciela produktu pełni prowadzący. Celem jest pokazanie jak zachowuje się właściciel produktu, czego zwykle oczekuje i wymaga, które z działań zespołu docenia, a których nie. 2 Odwiedź oficjalny sklep LEGO: http://shop.lego.com/en-us/lego-basic-bricks-deluxe-6177 6

Scrum Masterzy Ta gra może być prowadzona bez specjalnie wyznaczonych Scrum Masterów. Czasami w grze, jako Scrum Masterzy, biorą udział zaproszeniu dodatkowi trenerzy. Inną opcją jest poproszenie zespołów, żeby wybrały swoich Scrum Masterów. Posiadanie znających temat współprowadzących Scrum Masterów, którzy cały czas skupieni są na procesie, oraz osobnego trenera grającego rolę biznesową (właściciel produktu - przyp. tłum.) sprawia, że przeprowadzenie gry staje się łatwiejsze. Członkowie zespołu Uczestnicy szkolenia zostają członkami zespołów. Testerzy - Opcjonalnie Członkami zespołów mogą być też testerzy. Ich głównym zadaniem będzie pomoc w dokumentowaniu ustaleń na temat wymagań i przeprowadzenie testów akceptacyjnych. Wadą, jaką doświadczyłem osobiście jest to, że testerzy, zamiast budować z klocków LEGO, obserwują jakość. Jako, że celem gry jest nauka przez działanie, myślę, że warto zachęcać wszystkich do aktywnego udziału w procesie tworzenia produktu. Nie dopuszczaj obserwatorów Ta gra sprawia tyle przyjemności, że bierni obserwatorzy będą tracić więcej niż faktycznie wynosić z gry (to moja opinia). Jeśli jednak macie inne doświadczenia w tej kwestii, chętnie o tym usłyszę. CO NALEŻY OBSERWOWAĆ Zachowania Z moich obserwacji wynika, że konkretne zachowania, jakie ludzie prezentują podczas gier, są odzwierciedleniem ich nawyków z miejsca pracy. W sytuacji stresowej ludzie maja tendencję do ujawniania swoich naturalnych zachowań. Ta gra jest celowo zaprojektowana tak, aby była stresująca na tyle, żeby uwidocznić zachowania, które mogłyby źle wpłynąć na adopcję praktyk Agile. Moim celem, jako trenera, jest wskazanie takich zachowań grupie i obrócenie ich w naukę oraz pokazanie zagrożeń, na które należy mieć oko. 7

Style komunikacji Zwróć uwagę na managerów, dyktatorów, donośne głosy i podobne postawy. Mogą one stanowić bogaty materiał do podsumowań oraz osobistego coachingu. Załamujący się proces Zwracaj uwagę na elementy procesu, w których zespoły popełniają błędy. Na przykład podczas dyskusji w trakcie zbierania wymagań zespoły mogą nie zadawać dostatecznej liczby pytań wyjaśniających wątpliwości. Prawdopodobnie zespoły będą miały podobne problemy w trakcie prawdziwych projektów. Zwrócenie uwagi na takie błędy podczas podsumowań jest jednym ze sposobów poradzenia sobie z nimi. ETAPY GRY Symulacja ma naturalne trzy etapy: przygotowanie, gra i podsumowanie. Przygotowanie Formowanie zespołów Definiowanie procesu Formowanie wizji Budowanie backlogu Szacowanie Gra Planowanie sprintu Wykonanie (Sprint) Ocena efektów sprintu Zakończenie Podsumowanie 8

WSTĘP: Formowanie zespołów Zajmie 5 minut. Nie ma powodów, aby wykluczać tę część z gry - to dodatkowa okazja do nauki. Starając się zademonstrować samoorganizację w akcji, proszę zwykle uczestników do zorganizowania się w grupach 4-6 osobowych i przygotowanie sobie miejsca do pracy. Jest to dobre zajęcie na rozgrzewkę, ponieważ może wymagać przestawiania i uporządkowania stołów. WSTĘP: Formowanie wizji Zajmie 10 minut. Minęło do tej pory 5 minut gry. Jako trener odgrywający rolę właściciela produktu powinienem w tym momencie przekazać następujące informacje: 1. Wszystkie zespoły będą budowały jeden wspólny produkt - nie konkurujemy ze sobą, tylko pracujemy dla tego samego dostawcy. 2. Produktem jest MIASTO z konkretnymi cechami. 3. Głównym budulcem są klocki LEGO, ale można użyć innych materiałów jako dodatków. 4. Ja podejmuję główne decyzje na temat produktu - to jest moje miasto. 5. Będę zaangażowany w proces budowy poprzez odpowiadanie na pytania i zapewnianie komentarzy na temat powstałego produktu. Przeprowadzenie tej części jako wspólnego formowania wizji może być dobrym wyborem. Celem jest dbanie o to, aby zespoły ćwiczyły Scrum przez tworzenie produktu przy pomocy klocków LEGO. Trudność kryje się za pytaniem w jaki sposób połączyć rolę właściciela produktu (nie mającego wpływu na proces) i trenera (zainteresowanego tym, aby wszystko odbyło się zgodnie ze Scrum)? Jest kilka sposobów, jakie wypróbowałem: 1. Zmiana wcieleń - wyjaśnij zasady Scrum zespołom Jawnie ogłaszam czy aktualnie gram rolę właściciela produktu czy trenera tak, aby uczestnicy nie mieli wątpliwości. 2. Granie roli początkującego właściciela produktu - pozwól zespołowi sprzedać Ci Scrum Zazwyczaj gram właściciela produktu, który nie wie zbyt dużo na temat Agile czy Scrum i po przedstawieniu mojej wizji miasta proszę zespół, aby pomógł 9

zaprojektować proces, który najlepiej będzie tu pasował. Osobiście lubię drugie podejście bardziej, ponieważ wzmacnia naukę wynoszoną ze szkolenia i pozwala uczestnikom poćwiczyć przedstawianie zalet podejścia Agile. WSTĘP: Budowanie backlogu Zajmie 15 minut. Minęło do tej pory 15 minut gry. Kiedy nakreśliłeś już wizję i uzgodniłeś proces czas na przedstawienie cech miasta. Zwykle robię to pokazując zespołom zestaw przygotowanych wcześniej na kartkach user stories przyczepionych do arkusza flipchart. Najczęściej zawierają one następujące elementy: budynek jednopiętrowy (kilka takich, po jednym na kartkę), budynek dwupiętrowy (kilka), sklep, szkoła, kościół, szpital, przedszkole, przystanek autobusowy, skrzyżowanie (może być narysowane), park (może być narysowany), rzeka (może być narysowana), most. Niektóre z elementów mogą być narysowane na arkuszu z flipcharta, na którym potem budujemy budynki z LEGO. Można podejść do tematu kreatywnie i zbudować coś ciekawszego niż proste miasto. Raz rozgrywaliśmy tę grę z zespołem start-up i budowaliśmy krzemowe miasteczko. Oczywiście do zbudowania były nieco inne budynki, jak sala do prezentacji z ipadem udającym ekran, kilkoma miejscami do co-workingu na terenie miasta, bezpiecznym budynkiem na serwerownię czy pomnikiem bohatera przedsiębiorców (fantazyjnym pomnikiem na szynach). Było to bardzo zabawne! Podczas prezentacji backlogu wyjaśniam krótko jak wyobrażam sobie każdy z elementów, starając się odłożyć dyskusje (na temat szczegółów - przyp. tłum.) na później. 10

WSTĘP: Szacowanie Zajmie 20 minut. Minęło do tej pory 30 minut gry. Szacowanie. Jakimś sposobem najtrudniejsza część. Mogę tutaj: 1. Zrezygnować z szacowania (jak radzą guru Agile). 2. Zrobić to szybko i prosto. 3. Poświęcić trochę czasu na poćwiczenie planning pokera. RT @RonJeffries: Każdego roku pojawia się nowa technika szacowania. Prawdziwym podejściem agile byłoby wyrzucenie go całkowicie. - @agilemanager [TAK!] W zależności od tego ile czasu mamy, mogę zdecydować czy wykorzystamy prostszą technikę, czy pokera. Najszybsza technika Swimlane sizing Nauczyłem się jej z www.theagilepirate.net. Wygląda na to, że używam jej mniej wyrafinowanej wersji. Sprawdź opis poniżej. Bazując na technice triangulacji 3 i swimlane sizing 4 ustalamy kolumny odpowiadające różnym wielkościom user stories (1, 2, 3, 5, 8, 13 jeśli preferujesz skalę Fibonacciego - odrobina nauki zawsze jest dobra) i prosimy uczestników, aby umieścili kartki user stories w kolumnach odpowiadających ich oszacowaniom. Robimy to w grupach lub wszyscy razem. Całość można też przeprowadzić po cichu. 3 Triangulation i inne koncepcje szacowania i planowania Agile, autorstwa Mike a Cohn a 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 11

Rysunek 1: Kolumny dla szacowania grup Jeśli zespół jest zbyt duży aby zmieścić się przed tablicą, proszę o wyznaczenie pary uczestników. Kiedy para dokona swojego szacowania, proszę następną parę, aż wszyscy będą mieli szansę dostać się przed tablicę. Po zakończeniu pytam zespół czy efekt jest zadowalający i czy możemy rozpocząć prawdziwą pracę. Planning poker z wieloma zespołami Stosowanie planning pokera 5 z wieloma zespołami wymaga ustalenia na początek bazowego oszacowania z całą grupą. Wybierzcie element (backlogu - przyp. tłum.), który jest odpowiednio mały i prosty, ale nie trywialny i przydzielcie mu 2. Zwykle wszyscy zgadzają się aby jednopiętrowym budynkom przydzielić dwójki. Innym podejściem dla ustalenia bazowego oszacowania może być zastosowanie rozmiarów koszulek 6 (XS, S, M, L, XL), a następnie przydzielenie user stories o rozmiarze S wartości 2 i kontynuowanie planning pokera. Chciałbym podzielić się spostrzeżeniami, które pomagają mi przeprowadzić planning 5 Planning Poker został opisany po raz pierwszy przez James a Grening a w 2002 roku i spopularyzowany przez Mike a Cohn a: http://en.wikipedia.org/wiki/planning_poker 6 Szacowanie przy pomocy rozmiarów koszulek http://blogs.msdn.com/b/oldnewthing/archive/2009/05/12/9605143.aspx 12

poker dla wielu zespołów: Zorganizuj tablicę z kolumnami (patrz rysunki powyżej). Poproś zespoły aby dobierały user stories do szacowania jedną po drugiej. Poproś zespoły o dołączanie szczegółów do user story w momencie, kiedy uzyskują wyjaśnienia od właściciela produktu (ponieważ story może być później wykonywane przez inny zespół). Aktywnie zachęcaj i doceniaj uczestników zadających pytania pomagające lepiej ustalić oszacowanie dla user story. Kiedy user story zostanie oszacowane, powinno być umieszczone na tablicy, tak aby pozostałe zespoły mogły skorzystać z nowej informacji. Po zakończeniu poproś aby uczestnicy podeszli do tablicy i dokonali ostatniego sprawdzenia spójności oszacowań i ewentualnych korekt (z mojego doświadczenia zmiany nie są zwykle konieczne). Jeśli zespoły nie wiedzą zbyt wiele na temat planning pokera, warto zrobić próbne szacowanie aby móc zaobserwować czy będą stosować tę technikę poprawnie. Zwykle proszę wtedy zespoły o zgadnięcie: Ile w U.K. kosztuje pół kwarty (ang. pint) Guinnessa? To wymusza zadanie pytań o to, jaką skalę punktową należy użyć oraz gdzie i kiedy dokonujemy zakupu. Stanowi to dobrą rozgrzewkę przed właściwym szacowaniem. Interesujące jest to, że obie techniki - swimlanes i planning poker - dają wystarczającą precyzję potrzebną do planowania, co zostało potwierdzone przez setki wykresów burndown. GRA: Planowanie sprintu Minęło do tej pory 50 minut gry. (I nic nie zostało jeszcze zbudowane! Czy to wystarczający dowód na to, że szacowanie jest marnotrawstwem?) Teraz kiedy user stories zostały oszacowane, powinieneś przenieść je z kolumn na tablicy do backlogu. W związku z tym, że chcielibyśmy dokładnie pokazać planowanie sprintu, budujemy specjalną Tablicę Planowania, która zawierać będzie plany wszystkich zespołów na każdy sprint. 13

Rysunek 2: Tablica Planowania dla wielu zespołów. Przed planowaniem sprintu nr 1. Rysunek 3: Tablica planowania podczas sprintu nr 2. 14

Ograniczamy czas planowania sprintu do 3 minut i prosimy zespoły aby wybrały user stories do swoich pól sprintu na tablicy. Po zakończeniu pytamy zespoły czy czują się wystarczająco niekomfortowo z ich planami aby można było spróbować je wykonać! GRA: Wykonanie (Sprint) Zajmie 7 minut. Preferujemy sprinty 7-minutowe, ponieważ to wystarczająco dużo czasu aby kilka osób zbudowało kilka elementów bez nadmiernego dopracowywania ich. Aby upewnić się, że uczestnicy są wystarczająco zestresowani, pokazujemy na notebooku lub przez projektor, w widocznym miejscu, duży zegar z upływającym czasem: Rysunek 4: Zegar z www.online-stopwatch.com - zegary w różnych formach, których można używać również offline. GRA: Ocena efektów sprintu Zajmie 5 minut. Kiedy czas się kończy upewniam się, że uczestnicy faktycznie przestali budować i zaczynam dopytywać się gdzie jest moje miasto? Z obserwacji wynika, że dopiero po drugim sprincie zespoły zaczynają na bieżąco dostarczać budynki z ukończonych user stories na miejsce prezentacji (arkusz z flipcharta). W większości przypadków po pierwszym sprincie nikt tak faktycznie nie 15

miał jeszcze pomysłu na to, jak dokonać prezentacji efektów pracy. Brzmi znajomo? Podczas podsumowań zawsze słyszę od uczestników, że gram najmilszego właściciela produktu jakiego widzieli. Mimo to, w większości przypadków, po pierwszym sprincie nic nie zostaje zaakceptowane, ponieważ po prezentacji budynków zdaję sobie sprawę, że: Lubię symetrię. Wszystko w tym samym kolorze faktycznie znaczyło jednolite kolory budynków, ale każdy z nich w innym kolorze. Budynki są zbyt małe, zbyt duże lub zbyt różnorodne. Okna na poszczególnych piętrach nie są w jednej linii. <wymyśl własne powody> Niedokończone elementy zostają cofnięte z Tablicy Planowania do backlogu. Pozostała praca może zostać przeszacowana, ale rzadko zmieniamy oszacowania. Kiedy user stories zostają przyjęte, właściciel produktu aktualizuje wykres burndown, głośno przy tym ogłaszając, że wydanie produktu ma się odbyć po trzecim sprincie, i że wygląda na to, iż nie uda się nam ukończyć wszystkich user stories. Można poświęcić kilka minut na retrospekcję na temat tego, co możemy zrobić lepiej w kolejnym sprincie?. GRA: Cykl Bez tracenia zbyt dużej ilości czasu na dyskutowanie porażek pierwszego sprintu, który zwykle jest katastrofą, przechodzimy do planowania kolejnego. Nauczyłem się, że potrzeba średnio trzech sprintów, aby zbudować 80% backlogu z zachowaniem oczekiwanej jakości, więc pełny cykl zwykle wygląda tak: 1. Sprint #1 a. Planowanie 3 minuty b. Wykonanie (Sprint) 7 minut c. Ocena 5 minut 2. Sprint #2 d. Planowanie 3 minuty e. Wykonanie (Sprint) 7 minut f. Ocena 5 minut 16 3. Sprint #3 g. Planowanie 3 minuty h. Wykonanie (Sprint) 7 minut

i. Ocena 5 minut Razem: 45 minut W związku z tym, że przygotowania zajęły nam ok. 1 godzinę (od określenia wizji do oszacowanego backlogu), sprinty zajęły 45 minut, 15 minut zajmie podsumowanie, więc cała gra trwa 120 minut. Raz przećwiczona i przy pomocy współprowadzących, którzy grają rolę Scrum Masterów, można ją rozegrać nieco szybciej. ZAKOŃCZENIE: Podsumowanie Prawdopodobnie dobrym pomysłem jest zrobienie krótkiej przerwy po ocenieniu ostatniego sprintu i przed przejściem do podsumowania, aby uspokoić emocje i krótko odpocząć (Czy mówiłem, że gra zaprojektowana jest, aby być wyczerpującą? Nie tylko dla zespołów...) Po zebraniu się z powrotem w kole, rozpoczynamy dyskusję pokierowaną wokół następujących pytań otwartych: Co uczestnicy zaobserwowali? Jakie to uczucie być w zespole Scrum? Jak poszły krótkie iteracje? Jak dokładne okazały się oszacowania (zakładając, że mamy przed sobą wykres burndown) Co zrobilibyśmy inaczej od samego początku, jeśli mielibyśmy jeszcze jedną okazję, aby rozegrać tę grę? Jakie było zadanie właściciela produktu? Jakie to uczucie, gdy po pierwszym sprincie prawie wszystko wymaga przeróbek? Co robili Scrum Masterzy? Jak zmieni się wasza strategia, jeśli będziecie wiedzieć, że właściciel produktu nie jest dostępny podczas sprintów? Jak poszła komunikacja pomiędzy zespołami? Czy pojawiły się jakieś zależności? Jak zostały rozwiązane? Czego się nauczyli uczestnicy? 17

MODYFIKACJE Dokładanie zmiennych warunków Moi dobrzy przyjaciele (Askhat Urazbaev i Nikita Filippov) zaprojektowali podobną grę, która zawiera losowe zmiany rozmiaru zespołu oraz skomplikowania zadań. Po prostu, po planowaniu sprintu, ale tuż przed rozpoczęciem budowy, zespół rzuca kostką i albo zwiększa oszacowania user stories, albo niektórzy z członków zespołu zostają wysłani na chorobowe na czas sprintu, podczas gdy zespół będzie musiał wykonać zaplanowaną już pracę. Celem takiej gry jest pokazanie, że współpraca w zespole jest kluczowa dla zrównoważenia zadań wykonywanych w trakcie sprintu, ponieważ coś może pójść inaczej niż to było planowane. Scrum korporacyjny Udało mi się wyskalować symulację z LEGO do 100 osób grających w 12 zespołach, które budowały jednocześnie 4 miasta. Wymaga to całkiem sporo klocków LEGO, ale wydaje się być dobrym sposobem na zademonstrowanie Scrum w warunkach korporacyjnych. Opis zasad i przygotowań zasługuje na osobny artykuł. Masz własną modyfikację? Daj nam znać. Chcielibyśmy usłyszeć twoje relacje oraz pomysły na modyfikację gry - dołącz do nas na www.lego4scrum.com albo napisz do nas na adres info@lego4scrum.com 18

DZIĘKUJĘ! Życzę udanych projektów! Alexey Krivitsky www.lego4scrum.com 19