Dzień 16 – Retrospekcje: popatrz w tyl, żeby iść w przód

Ten post jest częścią cyklu Pierwsze Dni Scrum.

Umiejętność wyciągania wniosków z własnych doświadczeń jest podstawą uczenia się i rozwoju. Krótka pętla zbierania danych, planowania ulepszeń i wprowadzania ich w życie jest niezbędnym elementem empirycznego podejścia, jakim jest Scrum.

Tak samo jak co Sprint dostarczamy kolejne ulepszenia w naszym produkcie tak powinniśmy co sprint ulepszać środowisko naszej pracy, stosowane metody i narzędzia oraz wszystkie inne czynniki (na które mamy wpływ), które pozytywnie lub negatywnie wpływają na naszą efektywność.

W Scrum okazją do przejścia tego procesu są Retrospekcje, które odbywają się pod koniec każdego Sprintu.

Szkielet Retrospekcji

Jak piszą boginie retrospekcji Esther Derby i Diana Larsen w książce “Agile Retrospectives“, każde takie wydarzenie powinno w takie czy innej formie zawierać następujące kroki:

1. Ustal uwagę (Set the Stage) – przywołaj cel retrospekcji i podstawowe zasady (zakaz obwiniania jednostek, ulepszanie systemu, …). Ustal ramy czasowe i organizacyjne.
2. Zbierz dane (Gather Data) – zawsze staraj się zebrać i wspólnie przyjąć do wiadomości jak najwięcej faktów na temat przebiegu sprintu. Od liczby i rodzaju napotkanych bugów po nastrój poszczególnych członków zespołu w kolajnych dniach.
3. Zrozum sytuację (Generate Insight) – zadbaj o to, żeby cały zespół wypracował wspólne zrozumienie tego, co oznaczają zebrane fakty i jak można ich użyć by poprawić sytuację.
4. Zaplanuj działanie (Decide What to Do) – na podstawie wspólnego zrozumienia sytuacji zaplanujcie konkretne zmiany, które mogą pomóc Wam skuteczniej i przyjemniej pracować. Plany te powinny być możliwie konkretne, uwzględnione w planie kolejnego sprintu i najlepiej powiązane z pomiarem, który jednoznacznie odpowie na pytanie, czy zmiana przyniosła oczekiwane efekty.
5. Podsumuj retrospekcję (Close the Retrospective) – podziękuj wszystkim za uczestnictwo i powtórz, co zostało zaplanowane.

Powyższe kroki można zrealizować mniej lub bardziej wprost lub wpleść je w różnorodne plany retrospekcji, o jakich można przeczytać lub pomyśleć. Retrospekcje nie muszą (i nie powinny) być zawsze takie same, jednak lekkomyślne pominięcie któregoś z tych elementów może zatrzeć granicę między wartościową retrospekcją a czystą rozrywką lub wręcz destruktywną sesją narzekania.

Pomysły na retrospekcje

Skąd brać pomysły na skuteczne i angażujące retrospekcje? Jak słusznie zauważa Paweł Brodziński, czasem Scrum Master powinien powściągnąć swoje kreatywne zapędy i zaczerpnąć pomysły z samego zespołu. Nawet “obiektywnie lepsza” metoda przegra w konkurencji z podejściem wywiedzionym z naszego realnego środowiska.

Jeśli mimo to szukasz inspiracji, istną kopalnią pomysłów jest wspomniana wyżej książka. Wiele schematów retrospekcji można też znaleźć w internecie. Tutaj przytoczymy zaś trzy:

Mad, sad, glad – zadaj wszystkim razem i każdemu z osobna trzy pytania:

1. Z czego jesteś zadowolony (glad)?
2. Co Cię smuci (sad)?
3. Co Cię wkurza (mad)?

Statek: żagiel i kotwica – wyobraźcie sobie, że Wasz projekt to okręt żeglujący w kierunku nowego lądu:

1. Co jest wiatrem wypełniającym Wasze żagle i pchającym do przodu?
2. Co jest kotwicą, która Was spowalnia?
3. Czy gdzieś przed Wami czai się rafa, która może doprowadzić do katastrofy?

Luźna dyskusja – czasem retrospekcja nie wymaga wydumanego formatu. Może wystarczyć nieformalna rozmowa. Jednak nawet wtedy warto zadbać o to, żeby:

1. podczas sprintu, na bieżąco zbierać tematy do omówienia na retrospekcji (inaczej wiele ważnych zagadnień jest po prostu zapominana),
2. zadbać o to, żeby rozważać problemy w kontekście myślenia systemowego, a nie szukać winnych (w samym zespole lub poza nim),
3. sprowadzać rozmowę do faktów bardziej niż opinii,
4. wyjść z retrospekcji z konkretnymi zadaniami i uwzględnić je w planie następnego sprintu.

Analiza Problemów

Podczas retrospekcji oraz przy innych okazjach przydatne są często dwie popularne techniki analizy problemów, opisane niżej:

5xDlaczego (Five Whys) – gdy zidentyfikujemy problem, zamiast przystępować do jego rozwiązywania, pytamy dlaczego on wystepuje. Gdy znajdziemy przyczynę, pytamy dlaczego ona występuje i tak dalej pięć razy lub do momentu gdy jesteśmy w miarę pewni, że natrafiliśmy na źródłowy problem, a nie tylko na kolejne poziomy jego objawów.

Ość Ishikawy – to diagram w kształcie szkieletu ryby pozwalający rozważyć wiele przyczyn składających się na występowanie danego problemu. Jest przydatny, gdy na nasz problem wpływa wiele różnych czynników jednocześnie. Każdy z nich możemy analizować głębiej, tak jak w metodzie 5xDlaczego, aż do zbudowania wystarczająco pełnego obrazu sytuacji.

Appreciative Inquiry

Częstym błędem popełnianym przez zespoły podczas retrospekcji (a także przez wszelkiej maści coach’ów i konsultantów) jest zbytnie koncentrowanie się na problemach. Często dużo lepsze efekty można osiągnąć koncentrując się na pożądanych efektach oraz silnych stronach zespołu i procesu, które można rozszerzyć i wzmocnić.

Metoda ta jest często lekceważona, bo “przecież my tu mamy konkretne problemy, więc koncentrowanie się na pozytywach to forma mydlenia oczu…“. A jednak okazuje się, że metoda ta, poprawnie przeprowadzona, ma zaskakującą moc. Nigdy nie zamiatamy problemów pod dywan, jednak gdy stosujemy takie doceniające podejście często okazuje się, że zamiast bezpośrednio zmagać się z problemami możemy je zniwelować lub w ogóle obejść dzięki spojrzeniu na sytuację z innej perspektywy.

Duże retrospekcje

Retrospekcje są wartościowe nie tylko dla pojedyńczych zespołów. Jeśli stoisz przed problemem zorganizowania retrospekcji dla większej organizacji skontaktuj się z nami, a w międzyczasie przeczytaj jak duże retrospekcje wyglądają w szwedzkiej firmie Spotify.

Ćwiczenie dla Was:

1. Jeśli do tej pory tego nie robicie, to spróbujcie wpleść w swoje retrospekcje kroki opisane w “Agile Retrospectives”.
2. Jeśli nie zbieracie danych, na podstawie których prowadzicie retrospekcje to zacznijcie to robić.
3. Jeśli Wasze retrospekcje wyglądają zawsze tak samo to spróbujcie zmienić format i wypróbować inne metody – zaproponowane przez sam zespół lub z któregoś ze wspomnianych wyżej źródeł.