To o co chodzi z tym LEGO w Scrumie?

Mniej więcej siedem lat temu Alexey Krivitsky wpadł na pomysł, jak łatwiej, szybciej i ciekawiej wytłumaczyć zasady Scruma. Do tego celu wykorzystał stare, dobre klocki LEGO, z których uczestnicy szkoleń w trzech sprintach budują miasto na podstawie enigmatycznych, hasłowych zadań z backlogu (np. most, kino, hotel). W czasie pracy nad miastem uczestnicy mają szansę poznać znaczenie i zadania każdej z ról w Scrumie, zrozumieć istotę i przebieg ceremonii oraz oswoić się i popracować z Product Backlogiem, Sprint Backlogiem i historyjkami.

scrum-legoCo więcej, w grze tej jest czas na uchwycenie sensu wartości z Agile Manifestu – dlaczego komunikacja jest tak ważna, dlaczego agile koncentruje się na ludziach, o co tak naprawdę chodzi w tym szybkim dostarczaniu oprogramowania. Wystarczy, jeśli napiszę, że od tego czasu gra ta doczekała się własnej strony, ogromnego grona zagorzałych zwolenników, do którego i ja należę, tłumaczeń na kilkanaście języków, zapewne milionów przypadków użycia i kilku wariacji na temat (np. budowa lotniska).

Jednak gra ta ma jeszcze parę ukrytych walorów, o których rzadko się mówi, a które mogą mieć ogromne znaczenie dla zespołów pragnących w pełni korzystać z dobrodziejstw Scruma. Po przeprowadzeniu kilkudziesięciu szkoleń z użyciem kloców LEGO mogę śmiało napisać, że zrozumienie zasad Scruma to jedynie pierwszy stopień wtajemniczenia. Jeśli kiedykolwiek chcielibyście spróbować zagrać w LEGO, poniżej znajdziecie parę obserwacji i wniosków, do których wykorzystania szczerze zachęcam, abyście wykorzystali tę grę naprawdę w stu procentach.

  1. Charakter zespołu

Używając LEGO w nowych, dopiero co uformowanych zespołach, dobry Scrum Master bądź coach szybko odkryje, że gra ta pozwala przyjrzeć się naturalnym rolom w zespole (czy ktoś pamięta test Belbina?), charakterom osób oraz zidentyfikować potencjalne przyszłe problemy. W czasie gry, gdy członkowie zespołu zostają postawieni przed trudnym zadaniem i muszą się samodzielnie zorganizować najlepiej widać, kto ma zdolności przywódcze, kto łatwo się zniechęca, kto może protestować przeciwko wybranym rozwiązaniom, kto ma najbardziej kreatywne pomysły, kto motywuje zespół do dalszej pracy, a kto szuka najlepszych rozwiązań. Jest to przebogaty materiał do dalszej pracy z zespołem, i takiego wykorzystania najlepszych cech każdej osoby, by stworzyć efektywną, zgraną i lubiącą swoją pracę ekipę.

  1. Powrót do podstaw

LEGO to również idealne ćwiczenie dla doświadczonych teamów pracujących Scrumem rok, dwa lata bądź dłużej. Takie zespoły mają czasami tendencję do tworzenia zasad naruszających framework Scruma, do zapominania, o co tak naprawdę w tej metodzie chodziło, i zatrzymania się na mechanicznym odtwarzaniu ceremonii. Przeprowadzenie symulacji pracy Scrumem pozwala zespołom przypomnieć sobie podstawy Scruma, zweryfikować, z którymi praktykami mają największy problem i jakie mają skłonności do błędów. Z praktyki mogę w ciemno przy każdym teamie obstawiać brak komunikacji z Product Ownerem i doprecyzowania kryteriów akceptacji, decydowanie bez jego udziału o ostatecznym kształcie miasta (przed oczami staje mi zawsze obraz bardzo rzutkiego Scrum Mastera, który w pierwszych minutach gry samodzielnie rozdysponował po mieście wszystkie budynki, przekonał do swojego ustawienia zespół i już, już, nie czekając na rozpoczęcie sprintu zabierał się do budowania), rozmawianie o produkcie w trakcie retrospektywy, czy brak choćby szczątkowego DoD skutkujący targowaniem się z PO podczas review o to, czy dana historyjka faktycznie jest wykonana. I znów, jest to ogromne źródło wiedzy dla zespołu o tym, co powinni zmienić w swojej codziennej pracy, do których korzeni Scruma powrócić, co na nowo zaadaptować. Wiadro zimnej wody dla osób przekonanych, że doskonale znają Scruma, zazwyczaj powoduje ogromny skok jakościowy w dalszej pracy zespołu.

  1. Rywalizacja a wyniki

Gdy przeprowadzam LEGO dla kilku nowych zespołów zawsze daję im ten sam Product Backlog, z tymi samymi historyjkami, z tymi samymi wymaganiami, z tą samą wizją miasta i takimi samymi celami na sprint. Po mniej więcej dwóch godzinach gry, w czasie których zespoły w naturalny sposób zaczynają ze sobą rywalizować, zaczynamy porównywać wyniki. I co się okazuje? Że każde miasto jest inne, każdy most wygląda inaczej, stoi gdzie indziej, każdy ratusz jest indywidualnym dziełem sztuki, inaczej prezentują się przedszkola, szkoły, przystanki autobusowe, a mimo to wszystkie wymagania Product Ownera są spełnione i miasta powstały zgodnie z jego wizją. Jest to przyczynek do rozmowy o udziale zespołu w tworzeniu ostatecznego kształtu produktu – często traktowany po macoszemu i pomijany w codziennej pracy zespołów. Ile razy widziałam zespoły pracujące Scrumem, które nie miały nic do powiedzenia na temat wyglądu produktu, jego funkcji i po prostu realizowały kolejne wymagania w formie historyjek przyniesionych im przez Product Ownera. Cóż za marnotrawstwo ludzkiego potencjału! Wielokrotnie przekonywałam się, że w zespołach drzemie najwięcej świetnych pomysłów i to zespoły zasilane regularnie wizją i informacjami od PO potrafią znaleźć najlepsze rozwiązania. LEGO uświadamia i przypomina im fakt, że Scrum zakłada współpracę developerów z PO na każdym etapie tworzenia produktu, otwiera oczy na możliwości i przypomina, co się dzięki tej współpracy zyskuje.

  1. Współpraca między zespołami

W przypadku kilku doświadczonych zespołów często decyduję się na modyfikację gry i przedstawiam im jeden Product Backlog, którym muszą się podzielić, by paroma zespołami stworzyć dla Product Ownera jedno miasto. Ta przeróbka pierwotnych zasad gry świetnie się sprawdza w przypadku zespołów pracujących w dużych firmach, gdzie interakcje, zależności między zespołami i praca kilku z nich na rzecz jednego produktu są nieuniknione i na porządku dziennym. W takim wypadku LEGO stawia na przypomnienie, jak ważna jest komunikacja i sprawna współpraca. Niestety, często zespoły mają skłonność do koncentrowania się tylko na swoich zadaniach i nie widzą tzw. „big picture”. Wiele razy widziałam projekty opóźnione właśnie przez brak efektywnej współpracy między zespołami, dlatego uważam, że ten aspekt należy podkreślać, gdy tylko jest to możliwe. Gdy w czasie gry słyszę po raz pierwszy nieśmiałe słowa „To może usiądziemy razem”, „To może pogadamy z drugim zespołem”, „To może zrobimy razem ceremonie”, wiem, że nadal za mało się mówi o skalowaniu Scruma, ale że po takim szkoleniu zespoły wyjdą z nową wiedzą, z nowymi możliwościami w głowie i być może następnym razem wspólnie łatwiej uporają się z dużym projektem.

I na koniec jedna, istotna uwaga. LEGO uda się tylko wtedy, gdy zarezerwujecie sobie dość czasu na retrospektywę po przeprowadzeniu tej gry. To wtedy jest czas na zadanie pytań o sedno Scruma, o zaobserwowane błędy i skonfrontowanie ich z aktualną sytuacją zespołu, o możliwe zmiany, o wyniesione lekcje i pomysły na przyszłość. Gra musi zostać przepracowana i przegadana z jej uczestnikami. Bez tego elementu będzie to po prostu świetna, kilkugodzinna zabawa.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

Ta strona używa Cookies. Korzystając ze strony wyrażasz zgodę na używanie ciasteczek zgodnie z aktualnymi ustawieniami przeglądarki.
Akceptuję, bo lubię Was czytać.
x