„Iterate” – recenzja gry planszowej o rozwoju produktu

Od jakiegoś czasu przy okazji wydarzeń społecznościowych w Polsce (np. ostatniego Agile By Example) można było zauważyć, że rośnie rozgłos na temat “Iterate”, gry planszowej rozwijanej od kilku lat przez Tomka Włodarka (wraz z Kamilem Surmaczem i Kasią Gunią). Choć współpracowałem z Tomkiem, nie miałem bezpośredniej okazji do wzięcia udziału w kolejnych iteracjach wersji gry, choć widziałem zawartość pudełka, gdy nie miało ono żadnej profesjonalnej oprawy. Dostałem zaproszenie do dołączenia do otwartego warsztatu opartego o aktualną “produkcyjną” wersję Iterate i dzięki temu mogłem poznać zasady gry a tym artykułem podzielę się wrażeniami z wszystkimi czytelnikami.

Na czym polega gra “Iterate”?

Gracze w Iterate (od 2 do 6 osób) wcielają się w twórców produktu cyfrowego, rozdzielając między siebie role Właściciela Produktu, Scrum Mastera i Zespołu Wytwórczego. Mechanika gry odtwarza koncepcję pracy iteracyjnej – cały zespół planuje swoją pracę (gra zapewnia z góry ustalony Backlog Produktu, który należy poukładać a potem aktualizować według planowanej strategii rozwoju), potem poprzez rzucanie kostką dowiadujemy się jak się udał przebieg sprintu w porównaniu do planów i w zależności od tego rezultatu na podsumowaniu sprintu ustalamy jakie elementy Backlogu Sprintu zostały zakończone, a jakie niestety nie (i wracają do Backlogu Produktu). Jeśli na koniec sprintu zespół zrealizował całe fragmenty produktu nadające się do wdrożenia (kryteria tego definiuje scenariusz gry), Właściciel Produktu może zdecydować o przekazaniu produktu do klientów i od tego momentu zacząć zarabiać. Po podsumowaniu sprintu zespół ustala usprawnienia w ramach Retrospektywy (co symulowane jest przez karty usprawnień, spośród których wybiera zespół) i przechodzi do kolejnego sprintu.

Z powyższego ogólnego opisu można wnioskować, że gra jest prostą powtarzalną zabawą w kulanie kostką i decydowanie o kolejności wdrożenia. Nowy poziom trudności i skomplikowania gry ujawnia się w momencie, gdy zdamy sobie sprawę jaki wpływ na rozgrywkę mają czynniki losowe. Zaplanowanie zakresu sprintu musi się odbyć na samym początku sprintu i niekorzystne losowanie tego, co się udało wytworzyć (“niedowieziony sprint”) przynosi negatywne zjawiska – podwyższa czynnik Stresu Właściciela Produktu (i umownie mówiąc – zdenerwowany PO zaczyna częściej zawodzić, gdy przychodzi czas kulania jego kostką, a przekroczenie Stresu ponad 20 oznacza automatyczną przegraną całego Zespołu), obniża Flow Zespołu (zespół z niskim „flow” w kolejnych sprintach jest w stanie zrealizować mniej funkcji w produkcie) i rozwala plany – poniesione zostały koszty, ale prawdopodobnie nie uda się dostarczyć wersji produktu, za którą można zainkasować nowe przychody, więc zapas gotówki topnieje.

“Dowiezienie” Sprintu też nie jest równoznaczne z samymi dobrymi zjawiskami – co prawda obniży się Stres PO i podwyższy Flow zespołu, uda się też wytworzyć planowany zakres produktu, ale prawdopodobnie Zespół wytworzy dużo Długu Technologicznego. Dług jest losowany z oddzielnej puli kart, w których możemy mieć szczęście i nie ponosić żadnych negatywnych zjawisk, ale może również się okazać, że dodaliśmy do naszego produktu błędy (których usunięcie będzie nas kosztowało moce przerobowe zespołu) albo trafią się nam karty symulujące awarie na produkcji, które mogą nas kosztować gotówkę, skokowe podwyższanie Stresu i obniżanie Flow.

Jeśli czynników losowych byłoby nam mało, to w środku każdego sprintu jako zespół musimy wylosować jedną kartę akcji, która zazwyczaj dość mocno burzy nam idealny plan – np. musimy usunąć jakiś element Backlogu Sprintu z powrotem do Backlogu Produktu, znika nam jeden z członków zespołu na sprint (co obniża szansę na udane “dowiezienie”), dostajemy wysokie kary za nierozwiązane błędy w Backlogu Produktu. Niektóre ze szczególnie bolesnych kart akcji mają opcję wykupienia się, co tylko dodaje dylematów – czy uszczuplić nasz pozostały budżet albo wyraźnie podnieść Stres PO, czy jednak pogodzić się z tym, że ten konkretny sprint będzie zawalony.

Wszystkie te czynniki losowe są wyzwaniem dla graczy, którzy przez cały czas gry muszą szukać sposobów na wybalansowanie między dobrym wynikiem finansowym a minimalizowaniem wpływu czynników negatywnych, adaptowaniem swoich planów w obliczu sytuacji, których nie mogą uniknąć. Jest dokładnie tak, jak napisał Tomek na swoim blogu – na każdym kroku (na odwrocie każdej karty akcji…) widać, że twórcy gry mają masę doświadczeń związanych z rozwojem produktów programistycznych. Jako gracz możesz się wkurzyć, że z powodu jakiegoś drobnego potknięcia nie uda się dokończyć sprintu i zrealizować wdrożenia – po czym łatwo o refleksję, że jest dokładnie tak, jak w życiu rzeczywistym.

Czego gra ma szansę nauczyć

Gra ma walor rozrywkowy (po jednej całodniowej sesji mam silną potrzebę zagrania ponownie i zdaniem twórców gry to popularny odruch 😉 ), ale ma też w założeniu być grą edukacyjną. Ja osobiście widzę tu m.in. szansę na poczucie na własnej skórze takich kwestii jak:

  • Korzyści przyrostowo-iteracyjnego rozwoju produktu (strategie rozwoju produktu najprawdopodobniej w kilka sprintów podlegać będą silnej ewolucji w wyniku rozwoju rozgrywki, konieczność trzymania się pierwotnego planu prawdopodobnie zniechęciła by graczy kompletnie)
  • Przewagę empiryzmu nad predykcyjno-planistycznym postrzeganiem świata (nie mogę się doczekać, gdy zobaczę na żywo reakcje menedżerów albo kierowników projektu, gdy zespół wylosuje na swoich kostkach same najniższe wartości i sprint nie będzie “dowieziony” nawet w 20% planu).
  • Dbanie o balans między tempem wytwarzania a jakością produktu – dbanie o minimalny poziom długu (dosłownie w kilka sprintów prędkość zespołu może zanurkować w okolice zera, jeśli nie zwróci uwagi na niekorzystne efekty długu)
  • Czynnik ekonomiczny związany z wytwarzaniem (wielokrotnie spotykam się w zespołach scrumowych z zapominaniem o tym, że każdy sprint kosztuje a zarobek nie jest z produktu, który jest „ukończony” na środowisku testowym tylko z produktu, który jest ceniony przez klientów, gra to pokazuje bardzo wyraźnie)
  • Zrozumieniu perspektyw różnych ról scrumowych, zwłaszcza roli Właściciela Produktu. (niejednemu PO przyda się też wejść w ramach gry w role Zespołu Wytwórczego i unieść ze spokojem kluczowe pytanie “ile punktów damy radę zrealizować w tym sprincie?” w trakcie Planowania Sprintu)

Jak przebiegała rozgrywka, w której brałem udział

W mojej grze (byłem w zespole z Kamilem i Przemkiem, których pozdrawiam) dodatkowym wymiarem trudności był tryb wielodrużynowy – ponieważ na warsztacie tego dnia jednocześnie były 4 stoliki z graczami, prowadzący grę facylitatorzy dołożyli jeszcze utrudnienie polegające na tym, że wszystkie zespoły działały w symulowanym środowisku jednego rynku. Najważniejszą konsekwencją tej sytuacji było to, że jeśli różne zespoły dostarczały identyczne funkcje produktu, rosło prawdopodobieństwo, że te konkretne funkcje będą przynosiły niższe przychody co sprint (rynek się nasycał a konkretne funkcje przestały być cenioną przewagą konkurencyjną). Obraliśmy jako zespół strategię szybkiego uzyskania dochodu pokrywającego koszty zespołu (wdrożyliśmy pierwszy produkt jako najszybszy zespół w sali) a potem skupiliśmy się zwiększeniu ilości opcji, w stronę których możemy rozwinąć nasz produkt (by być bardziej odpornymi na ewentualne niekorzystne wydarzenia w naszej rozgrywce albo zły rozwój sytuacji rynkowej). Dzięki bardzo udanemu pierwszemu sprintowi mieliśmy też zapas gotówki na zwiększenie wielkości zespołu (skład zespołu jeśli chodzi o ilość osób, ich poziom zaawansowania oraz wynikający z tego koszt oraz skłonność do generowania długu technologicznego to kolejny wymiar gry, na razie o nim nie wspominałem). Ostatecznie udało się nam spłacić inwestora i uzyskać stabilne dochody znacznie przewyższające koszty każdego sprintu (co generowało zapas gotówki na gorsze sprinty, które również się zdarzyły). Mimo to, gdy pod koniec gry nastąpiło u nas rozluźnienie, nie do końca przemyślanymi decyzjami zespołowymi nadzialiśmy się na skokowy wzrost Stresu Właściciela Produktu i byliśmy blisko przegrania gry z tego powodu (ale poszczęściło się nam przy losowaniu Długu Technologicznego). Zdarzyło się nam też niestety nie zrozumieć jednej z zasad gry, co uczyniło nasz wynik trochę nieporównywalny, bo źle liczyliśmy sobie przychody w środkowej części gry 😉

Osobiste lekcje z gry

Dużo śmiechu przy stoliku wywoływały nasze głośne reakcje, gdy uświadamialiśmy sobie jak gra jest bliska rzeczywistości. Kilka moich osobistych lekcji wymienię poniżej, zachowując jednak przy tym odrobinę tajemniczości, by nie zepsuć rozgrywki tym, którzy jeszcze jej nie spróbowali:

  • Fantastycznie pokazany jest aspekt tego, że każdy sprint kosztuje. Każdy członek zespołu (SM, Devi i PO) ma swój koszt co sprint i sumę kosztów całego Zespołu należy wpłacić do banku w momencie rozpoczynania każdego sprintu. Nie wiesz jeszcze ile zespół zrealizuje, czy cokolwiek wdroży i ile się na tym produkcie zarobi – gotówkę na pokrycie kosztów trzeba mieć zabezpieczoną i może się ona nam szybciej skończyć niż planujemy (zwłaszcza jak będziemy mieli pecha do losowania kart wydarzeń i długu). Po tym, jak poczułem to zjawisko na sobie, będę inspirował zespoły, z którymi pracuję, do częstszego wracania do wątku kosztów i przychodów generowanych przez zespół – świadomość tego, zwłaszcza w dużych organizacjach, jest bardzo rozmyta.
  • Gra bardzo dobrze uświadamia też osobom wchodzącym w różne role, jak bardzo potrzebna jest ciągła współpraca. Dobre planowanie to nie jest sekwencja dwóch kroków – Właściciel Produktu mówi co ma być zrobione, zespół z nim negocjuje czy to zrobią (przerysowując oczywiście). Dobre planowanie to ciągła eksploracja różnych opcji, w których wszyscy mogą wnieść swoje zdanie co do zakresu prac, wszyscy też mogą rozmawiać o planach alternatywnych w sytuacji wydarzeń niekorzystnych. Współpraca możliwa jest też w trakcie dalszej części sprintu, gdy karty akcji zespołu, SMa i PO mogą się wzajemnie wspierać, jeśli tylko otworzymy się jako cały Zespół na taką ewentualność.
  • Nie docenialiśmy w zespole roli Doskonalenia Backlogu. Początkowo wydawało się nam, że w sumie niewiele nam taki Refinement wnosi, za to kosztuje nas czas którego nie możemy przeznaczyć na rozwój (jakże życiowa obserwacja), póki nie udało się nam trafić niesamowitych odkryć, radykalnie zmieniających nam zawartość Backlogu Produktu (i tu niestety nie mogę więcej powiedzieć poza radą o istotnej wartości doskonalenia Backlogu).
  • Z racji tego, że wybraliśmy dosyć rozbudowaną strategię rozwoju produktu, dosyć szybko wyszło nam, jak ważny jest przejrzysty i dobrze zorganizowany Backlog Produktu. Gubiliśmy się trochę w naszym, zapominaliśmy co chcemy jeszcze rozwinąć, co mamy do doskonalenia a co jest już gotowe, ale jeszcze nie wdrożone. W ferworze gry i kolejnych sprintów nie zatrzymaliśmy się wystarczająco mocno przy tym punkcie, ale im więcej czasu upłynęło od tej rozgrywki, tym bardziej myślę, że plany bardzo uporządkowałby nam fakt posiadania dobrego Backlogu.

Dla kogo jest ta gra?

Widzę kilka dosyć konkretnych zastosowań gry. Przede wszystkim wydaje mi się bardzo dobrą osią warsztatu albo szkolenia dla Właścicieli Produktu (i to zarówno dla początkujących jak i zaawansowanych, którzy mogą grę odbierać na głębszym poziomie zrozumienia i nadal z tego czerpać). Z tego powodu może być ciekawą opcją dla trenerów metod zwinnych, Agile Coachów albo członków społeczności Product Ownerów w danej firmie czy danym mieście. Dla walorów edukacyjno-rozrywkowych gra może też być bardzo ciekawą opcją rozwoju swoich kompetencji i dokonania refleksji nad zwinnością dla każdego Scrum Mastera albo pomóc zrozumieć zwinne podejście do rozwoju produktów członkom całych zespołów. Gra jest bardzo mocno osadzona w realiach rozwoju oprogramowania, więc może być mniej zrozumiała jako narzędzie poznawania zwinności dla osób spoza IT. Aspekt rozwoju produktu jest chyba zbyt uproszczony, by symulacja mogła wprowadzać w świat zwinności wyższe kierownictwo albo zespoły odpowiedzialne za rozwój biznesu.

Kibicuję inicjatywie wytworzenia produktu związanego ze zwinnością pochodzącego z Polski i liczę, że gra nabierze popularności nie tylko u nas, ale również poza granicami kraju. Sam również chętnie jeszcze wezmę udział w kolejnych grach i dam się ponownie zaskoczyć złożoności i niepewności symulowanej w trakcie rozgrywki.

Jeden komentarz do wpisu: “„Iterate” – recenzja gry planszowej o rozwoju produktu


Dodaj komentarz

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

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x
X