Czy retrospektywy są tego warte? Nasza ocena

Tak — ale nie z tego powodu, dla którego większość zespołów je broni. Retro przynosi korzyści dzięki nauce i budowaniu spójności, a nie dzięki zgrabnej liście zadań do wykonania. Jeśli Państwa sesja przynosi jedynie słowa, to problemem nie jest sam rytuał. Musimy wzmocnić argumenty sceptyków i wygrać.

Tak — ale nie z powodu, dla którego większość zespołów je stosuje. Sesja retrospektywna przynosi korzyści dzięki nauce i spójności zespołu, a nie dzięki zgrabnej liście zadań do wykonania. Jeśli Państwa sesja przynosi jedynie słowa, to problemem nie jest sam rytuał. Problemem jest realizacja ustaleń, a także zdolność zespołu do działania.

Stwierdzenie „Retrospektywy to strata czasu” nie jest tylko leniwą narzekaniem. Jest to najpoważniejsza krytyka, jaką można wysunąć pod adresem ceremonii agile, a uczciwa obrona musi się z nią zmierzyć, a nie ją omijać.

Argument, że styl retro jest bezsensowny

Dowody przedstawiane przez sceptyków są konkretne i można je znaleźć wszędzie. Wyrażane są obawy, ale nic się nie dzieje; ta sama karteczka powraca sprint po sprincie, a towarzyszy jej cicha rezygnacja, że i tym razem problem nie zostanie rozwiązany. Według jednego z często cytowanych badań jedynie około jedna trzecia zespołów konsekwentnie realizuje zadania wynikające z retrospekcji — a nawet to sformułowanie nie oddaje głębszego wymiaru porażki. (Jeśli to ma jakieś znaczenie, powszechne przekonanie jest zbyt pesymistyczne: nasze własne dane dotyczące tego, czy zespoły faktycznie realizują postanowienia podjęte podczas retrospektyw, wskazują, że wskaźnik realizacji zadań wynosi raczej trzy na cztery.)

Najgłębszym wymiarem tej krytyki jest bezsilność. Istotne problemy — budżet, stan zatrudnienia, zależności między zespołami, infrastruktura, decyzje podejmowane dwa szczeble wyżej — faktycznie wykraczają poza zakres kompetencji zespołu. W związku z tym spotkanie podsumowujące staje się jedynie miejscem, w którym problemy te są nazywane, i niczym więcej: zespół otrzymuje możliwość wypowiedzenia się, ale nie ma żadnych środków, by coś zmienić. Co gorsza, daje to kierownictwu pretekst. Istnieje teraz kanał, przez który można zgłaszać skargi, więc jeśli nic się nie poprawia, oznacza to, że mechanizm komunikacyjny zespołu nie działa, a nie że organizacja ma problem, który należy rozwiązać.

Do tego dochodzi ryzyko zawodowe, o którym prawie żadna strona dostawcy nie wspomina. Kiedy szczere uwagi są gromadzone, a następnie przytaczane podczas oceny wyników pracy — jako przejaw nadmiernego narzekania — ludzie szybko wyciągają wniosek: szczerość jest obciążeniem. Nawet samo wyładowanie emocji wiąże się z realnymi kosztami. Wysłuchiwanie przez godzinę frustracji innych osób, sprint za sprintem, samo w sobie stanowi ciche obciążenie.

To naprawdę poważna sprawa. Taka retro, która tak się zachowuje, jest gorsza niż brak retro, ponieważ w cyklu dwutygodniowym uczy bezradności nabytej.

Dlaczego nadal warto je kupować

Najsilniejszym argumentem zwolenników nie jest to, że „zadania są realizowane”. Jest nim spójność. Nawet niedoskonałe spotkanie podsumowujące, organizowane jako regularna, obowiązkowa ceremonia, w większym stopniu przyczynia się do poprawy zdolności zespołu do współpracy niż jego brak — zespoły, które nigdy nie zatrzymują się, by porozmawiać, znacznie częściej borykają się z wewnętrznymi konfliktami niż te, które to robią. Najbardziej wymowną historią przemiany w tej dyskusji jest przypadek inżyniera, który przeszedł od obaw przed retrospekcjami do oczekiwania na nie z niecierpliwością i zdał sobie sprawę, że różnica polegała po prostu na tym, że nigdy wcześniej nie widział, jak przebiega ona prawidłowo.

Potwierdza to obecny kanon. Drugie wydanie Agile Retrospektywy (2024 r., z Davidem Horowitzem jako trzecim autorem) wyraźnie podkreśla tę zmianę: kryterium sukcesu stanowi nauka, a nie lista czynności do odhaczenia. Retrospektywa, podczas której zespół rzeczywiście coś zrozumiał, nie jest porażką tylko dlatego, że nie powstał w jej wyniku żaden zgłoszenie. To jedno przeformułowanie stanowi odpowiedź na najczęstszą skargę — ponieważ stwierdzenie „nic się nie zmieniło” przestaje być jedyną miarą wartości retrospektywy.

W jakich okolicznościach zmienilibyśmy zdanie

W jednej konkretnej sytuacji zalecalibyśmy zespołowi zaprzestanie organizowania spotkań retrospektywnych: gdy rzeczywiste problemy w przeważającej mierze pozostają poza jego kontrolą, kierownictwo nie podejmuje działań w odpowiedzi na zgłoszenia eskalacji, a spotkanie nie ma żadnej mocy ani nie prowadzi do żadnych konkretnych działań. W takiej sytuacji retrospektywa staje się tylko pozorem, i wolelibyśmy, abyście najpierw uporządkowali ścieżkę eskalacji — lub ograniczyli częstotliwość spotkań do realistycznego poziomu — zamiast co dwa tygodnie przeprowadzać kolejne sesje refleksji. Retrospektywa pozbawiona realnego wpływu nie jest jedynie neutralną stratą godziny; aktywnie podważa zaufanie.

Zredukowalibyśmy również częstotliwość spotkań, a nie samą formę, gdy zespołowi rzeczywiście zabraknie nowych tematów do omówienia. Cotygodniowe spotkanie retrospektywne w zespole, w którym nic się nie zmieniło, przeradza się w rytuał polegający na odhaczaniu pozycji na liście. Jest to problem związany z częstotliwością, a nie dowód na to, że retrospektywy są bezużyteczne.

Praktyczne podejście

  • Proszę zdefiniować sukces na nowo jako proces uczenia się, a nie listę zadań do wykonania. Należy dążyć do jednej rzeczywistej zmiany lub jednego wspólnego spostrzeżenia na każde spotkanie podsumowujące, a na początku spotkania omówić wyniki poprzedniego spotkania. Długa lista sprawia, że spotkania podsumowujące stają się teatrem odhaczania punktów.
  • Proszę klasyfikować problemy według tego, kto jest za nie odpowiedzialny, a te, na które zespół nie ma wpływu, należy zgłaszać z podaniem nazwiska i daty. Proszę nie mówić innym, by „pozostawali w swoim kręgu wpływów”, jeśli oznacza to ukrywanie prawdziwej przeszkody — zamiast tego proszę informować o niej osoby spoza zespołu.
  • Dbajcie o bezpieczeństwo, ponieważ zjawisko „gromadzenia informacji zwrotnej” jest faktem. Należy wykluczyć osobę sprawującą autorytet, której obecność wywołuje ciszę w pomieszczeniu, zadbać o to, by to, co zostało powiedziane, pozostało w pomieszczeniu, oraz zapewnić możliwość zachowania anonimowości w odniesieniu do poszczególnych pomysłów. Bezpieczeństwo psychologiczne nie jest jedynie miłym dodatkiem: w ramach projektu „Aristotle” firmy Google, opierającego się na badaniach Amy Edmondson, stwierdzono, że jest to najważniejszy czynnik wpływający na efektywność zespołu.
  • Dostosuj częstotliwość. Jeśli nie ma nic nowego, nad czym warto by się zastanowić co tydzień, przeprowadzaj to co dwa tygodnie. Wymuszona refleksja sama w sobie stanowi antywzorzec.

W Przewodniku po Scrumie napisano, że retrospektywa polega na samokontroli zespołu w celu wprowadzenia ulepszeń. Zatem w momencie, gdy retrospektywa jest przeprowadzana wobec zespołu, a nie przez niego, traci się to, co sprawiało, że warto było poświęcić na nią godzinę. Jest to tryb awarii „Void” — refleksja, po której nie następują żadne dalsze działania — i jest to najłatwiejszy do naprawienia problem z tej listy.

Najczęściej zadawane pytania

Czy retrospektywy to strata czasu?

Tak jest wtedy, gdy ograniczają się one wyłącznie do słów — gdy w każdym sprintie poruszane są te same kwestie, a nic się nie zmienia. Jednak winę za to ponosi zazwyczaj brak konsekwencji w działaniu oraz ograniczona zdolność zespołu do podejmowania działań, a nie sama ceremonia. Retrospektywa, która prowadzi do zdobycia wiedzy i niewielkich, samodzielnie wprowadzanych zmian, jest warta poświęconego jej czasu; ta, która pełni jedynie funkcję zaworu bezpieczeństwa, już nie.

Czy retrospektywa musi zawierać konkretne działania, aby była wartościowa?

Nie. W drugim wydaniu książki „Agile Retrospectives” sukces definiuje się na nowo jako proces uczenia się, a nie jako listę zadań do wykonania — retrospektywa, podczas której zespół rzeczywiście coś zrozumiał, nie jest porażką tylko dlatego, że nie powstał w jej wyniku żaden zgłoszenie. Dążenie do ustalenia konkretnych działań tylko dla samego ich ustalenia sprawia, że retrospektywy stają się jedynie formalnością. Należy dążyć do jednej rzeczywistej zmiany lub jednego wspólnego spostrzeżenia, a nie do długiej listy, której połowa zniknie w backlogu.

Kiedy naprawdę nie warto organizować retrospektywy?

W jednej konkretnej sytuacji: gdy rzeczywiste problemy w przeważającej mierze pozostają poza kontrolą zespołu, kierownictwo nie podejmuje działań w sprawie zgłoszonych problemów, a spotkanie nie ma żadnej mocy ani nie prowadzi do żadnych konkretnych działań. Bezwładne spotkanie podsumowujące nie jest jedynie neutralną stratą godziny — aktywnie podważa zaufanie, uczyąc zespół, że zabieranie głosu niczego nie zmienia. Należy poprawić ścieżkę eskalacji lub zmniejszyć częstotliwość spotkań do realistycznego poziomu, zamiast przeprowadzać refleksję co dwa tygodnie. A jeśli zespołowi po prostu zabrakło nowych tematów do omówienia, należy ograniczyć częstotliwość spotkań, a nie samą ceremonię.

Warto przeczytać