Crazy Blocks

Oznajmienie, że wdrażamy Scruma, to jeden z pierwszych kroków transformacji w wielu organizacjach. Dopiero później w głowie pojawia się myśl, że w Scrumie nie ma roli Project Managera, który planował wszystkie prace zespołów deweloperskich. Kto więc określa, jak dużo pracy damy radę wykonać w trakcie Sprintu? I kto w trakcie Sprintu rozdziela pracę pomiędzy Deweloperów? Dla znających Scruma odpowiedź jest oczywista – Zespół Deweloperski robi to samodzielnie. Ma on za zadanie zorganizować się tak, by być w stanie przejąć tę część działań, za które dotychczas odpowiedzialny był PM (lub Kierownik).

Droga do zwinności bywa wyboista

Niestety, często okazuje się, że Zespół Deweloperski niemal z dnia na dzień musi zacząć wykorzystywać umiejętności, których nie ma, a które przeciętny Project Manager zdobywa przez lata praktyki. OK, wymagania względem Zespołu Deweloperskiego nie są aż tak wyżyłowane – istnieje jednak wiele umiejętności, które Zespół powinien zdobyć, by dobrze planować swoje prace. Doświadczony Scrum Master jest w stanie zidentyfikować wielu zagrożeń ani wesprzeć Zespołu Deweloperskiego w tym obszarze na ich drodze do zwinności.

Przyjrzyjmy się typowym wyzwaniom w Zespołach, które dopiero zaczynają przygodę z samoorganizacją i planowaniem swojej pracy:

rozpoczynanie wielu zadań jednocześnie (często więcej niż liczba członków zespołu), zamiast domykania już rozpoczętych;
na końcu Sprintu wiele wymagań jest rozpoczętych, a niewiele zamkniętych (a czasem nawet żadne);
Product Owner (PO) otrzymuje do odbioru wymagania dużymi partiami (często w ostatnim dniu Sprintu) i nie jest w stanie odebrać wszystkich przed zakończeniem Sprintu;
Deweloper o kompetencjach testerskich przez pierwszą połowę Sprintu nie ma co robić;
planowanie ogranicza się tylko do wyboru wymagań do Sprintu – bez zaplanowania przebiegu i podziału prac;
niezwracanie uwagi na Cel Sprintu;
niewłaściwie przeprowadzane Daily, skutkujące niepotrzebnymi rozmowami “synchronizacyjnymi” podczas pracy (i odrywaniem od pracy);
nierozpoznane zależności – techniczne, od innych wymagań, od innych zespołów;
brak reakcji lub niewłaściwe reakcje na zdarzenia losowe;
Deweloperzy o danych kompetencjach wiodących są dociążeni w Sprincie bardziej niż inni;
każdy Deweloper skupia się na swojej części pracy, nie patrząc na zadania z punktu widzenia zespołowego, a nawet ogólnofirmowego.

Chcąc uniknąć takich problemów w naszych zespołach, jako Scrum Masterzy postanowiliśmy przeprowadzić warsztaty wpierające organizację pracy w Sprincie. Zaprzęgliśmy do tego stworzoną przez nas specjalnie na te potrzeby grę – Crazy Blocks. Mechanika gry utrudnia nawet proste zadania, a różne zdarzenia losowe pojawiają się bez ostrzeżenia, w najgorszym możliwym momencie. Deweloperzy stykają się z typowymi problemami, reagują na nie i obserwują efekty tych działań – w kontrolowanym środowisku.

Od razu założyliśmy, że uczestnictwo w warsztacie nie będzie obowiązkowe, mogli zapisywać się wszyscy Deweloperzy. Tym większe było nasze zadowolenie z tego, że warsztaty cieszyły się tak dużym zainteresowaniem. Do teraz przeprowadziliśmy już sześć edycji tego warsztatu. Po każdej wprowadzaliśmy ulepszenia, dzięki którym otrzymaliśmy optymalną mechanikę gry. Warto podkreślić, że jedna z edycji była dedykowana Product Ownerom, aby lepiej pokazać im, z jakimi problemami spotykają się Deweloperzy w trakcie Sprintu i jak ich praca wpływa na te zespoły.

Rozpoczynając warsztat, nie robiliśmy wprowadzenia teoretycznego i od razu przedstawiliśmy wyłącznie zasady gry. Najpierw praktyka, a na koniec wnioski i odniesienie do teorii. Uczestnicy wcielili się w rolę Deweloperów. Dwa zespoły po 4-5 osób. Każdy z zespołów współpracował z dedykowanym Product Ownerem. W tę rolę wcielili się prowadzący szkolenie.

Zasady gry

Do gry wykorzystaliśmy:

plansze z różnymi statusami zadań,
karty zadań, które zespół będzie realizował,
zestaw kości do określania zdarzeń losowych,
zestaw pionków do realizacji zadań,
klepsydry (15- i 30-sekundowe) do pokazania, że biznesowy odbiór zadań też wymaga czasu,
pieniądze do płacenia za zrealizowane zadania.

Na początku gry, każdy zespół otrzymuje do realizacji zestaw zadań. Z matematycznego punktu widzenia da się je zrealizować, pod warunkiem idealnego planowania i tego, że zdarzenia losowe będą dla nas korzystne (lub przynajmniej neutralne).

Gra trwa ok. 1h. W jej trakcie przechodzimy 3 Sprinty. Sprint to 5 wirtualnych dni, z których każdy trwa od 2 do 4 minut i składa się z Daily (można planować, ale nie można realizować) i realizacji zadań. Pierwsze Daily w Sprincie jest dłuższe, żeby zespół miał okazję wstępnie zaplanować cały Sprint. Z każdym Sprintem wzrasta poziom skomplikowania i gdy w pierwszym jedynie realizujemy niezależne zadania, to w ostatnim występują już zależności nawet z drugim Zespołem, a wybrane zadania mogą być realizowane tylko przez jedną osobę. Wraz ze wzrostem poziomu trudności, wzrasta też niepewność w realizowanych zadaniach i jest znacznie więcej zdarzeń losowych.

Przykładowe zdarzenia losowe w grze:

PO dorzuca zadanie (od Prezesa),
PO decyduje o wstrzymaniu realizacji już rozpoczętego zadania,
PO na urlopie (drugi PO zastępuje, ale nadal ma do dyspozycji tyle samo czasu – na 2 Zespoły),
obaj PO niedostępni dla Zespołów (na spotkaniu),
choroba kolegi z Zespołu Deweloperskiego,
jeden członek Zespołu Deweloperskiego został oddelegowany do innych prac i może poświęcić mniej czasu na zadania zespołowe.

I jak nam wyszło?

Wnioski uczestników po zakończeniu gry:

w dobrze zaplanowanym Sprincie łatwiej jest radzić sobie z sytuacjami nieprzewidzianymi;
zadania z większą niepewnością lepiej realizować na początku Sprintu;
im lepsza współpraca, tym lepsze efekty;
im lepsze Daily, tym mniej odrywania od pracy na etapie realizacji;
planowanie odbiorów PO zwiększa szansę “dowiezienia” Sprintu;
wspólne realizowanie wymagań i – w miarę możliwości – zamykanie jednego po drugim, zwiększa wartość biznesową (szybciej możemy korzystać ze zrealizowanych zadań i już przynoszą nam wartość).

Ku naszemu zadowoleniu, wnioski uczestników pokrywały się z tym, co chcieliśmy uwidocznić i rzadko musieliśmy odnosić się do teorii, która nie wynikała z praktyki. Oprócz nauki warsztat zapewnia świetną integrację, a efektem “ubocznym” jest późniejsza lepsza współpraca międzyzespołowa.