Dlaczego retrospektywy kończą się niepowodzeniem (i jak sprawić, by Państwa retrospektywa miała znaczenie)

Państwa zespół organizuje retrospektywę po każdym sprincie. Uczestnicy przychodzą, przyklejają karteczki, zgadzają się na dwa lub trzy zadania do realizacji i wychodzą. Jednak nic się nie zmienia w sposobie, w jaki faktycznie przebiega praca. Jeśli powtarza się to czterdzieści razy w roku, nie wykształca się nawyku wprowadzania usprawnień — wykształca się nawyk rozmawiania o usprawnieniach. Jest to rodzaj niepowodzenia, o którym prawie nikt nie wspomina: nie chodzi o zły format, ale o rytuał, który niezawodnie generuje słowa i tylko słowa.

Standardowe porady traktują nieudaną retrospektywę jako problem związany z prowadzeniem spotkania — należy zmienić format, sformułować działania zgodnie z zasadami SMART, dodać lodołamacz. Czasami właśnie w tym tkwi problem. Zazwyczaj jednak tak nie jest. W innym miejscu skatalogowaliśmy dziesięć typowych antywzorców retrospektywnych, które warto wyeliminować. W niniejszym rozdziale skupimy się na dwóch rodzajach niepowodzeń, które w powyższym wykazie zostały grzecznie pominięte, ponieważ to właśnie one sprawiają, że doświadczeni inżynierowie uznają retrospektywy za stratę czasu: problem władzy oraz problem realizacji. Żadny lodołamacz nie rozwiązuje żadnego z nich.

Styl retro, który niczego nie zmienia, ponieważ drużyna nie jest w stanie

Oto najgłębsza krytyka retrospektyw – i właśnie w tej kwestii nasz własny wpis dotyczący antywzorców zawiera błąd. Kiedy programista mówi, że „nigdy nic się nie dzieje”, zazwyczaj nie ma na myśli tego, że zespół zapomniał sformułować zadania do realizacji. Chodzi mu o to, że problemy warte poruszenia — liczba pracowników, zależności między zespołami, proces wdrażania trwający czterdzieści minut, termin wyznaczony przez kierownictwo trzech szczebli wyżej — rzeczywiście wykraczają poza zakres kompetencji zespołu i nie leżą w jego mocy. Jak trafnie ujął to jeden z inżynierów na Hacker News, retrospektywa może stać się „ceremonią bez rzeczywistego celu, ponieważ zazwyczaj głębsze kwestie poruszane przez uczestników nie leżą w zakresie kompetencji danego zespołu”. Inny użytkownik w tym samym wątku napisał: „Daje to kierownictwu pretekst do niepodjmowania działań naprawczych lub nie wsłuchiwania się w opinie, ponieważ retrospektywa ma rzekomo służyć jako miejsce wyładowywania niezadowolenia”.

Na tym polega pułapka. Sesja retrospektywna zamienia się w zawór bezpieczeństwa — zespół ma możliwość wypowiedzenia się właśnie po to, by nic nie musiało ulec zmianie. Uczestnicy dają upust emocjom, kierownictwo uznaje, że zadanie zostało wykonane, a przyczyna leżąca u podstaw problemu pozostaje nienaruszona. Obwinianie za to moderatora jest, jak ujął to jeden z programistów w swoim eseju, „jak obwinianie skrzynki na sugestie za to, że kierownictwo nie zapoznaje się z sugestiami”. Żadna ilość metafor typu „żaglówka kontra rozgwiazda” nie da zespołowi uprawnień do rozwiązania problemu, do którego rozwiązania nigdy nie otrzymał uprawnień.

Nasza dawna rada — „przestańcie skupiać się na sprawach spoza Państwa kręgu wpływów” — w tym przypadku po cichu opowiada się po stronie systemu. Sugeruje ona zespołowi, by pominął prawdziwą przeszkodę, aby rozmowa przebiegała w komfortowej atmosferze. Zamiast tego należy przyjąć bardziej zdecydowane stanowisko. Należy posortować wszystkie problemy według tego, kto faktycznie za nie odpowiada: co zespół kontroluje, na co może wpływać, a co może jedynie znosić. Jest to ćwiczenie „Circles and Soup” autorstwa Esther Derby i Diany Larsen z książki Agile Retrospectives (wydanie drugie) — a celem zewnętrznego pierścienia nie jest „ignorowanie tych kwestii”. Stanowi on punkt wyjścia do eskalacji.

Nie wszystko eskaluje i nie wszystko jest beznadziejne. 15% Solutions — technika z zakresu „Liberating Structures”, polegająca na znalezieniu najmniejszej zmiany, jaką zespół może wprowadzić bez konieczności uzyskiwania czyjejkolwiek zgody — pozwala utrzymać tempo działań w obrębie „pierścienia wpływu”, podczas gdy większe przeszkody są stopniowo pokonywane. Jednak rzetelna retrospekcja nie pozwala udawać, że za sytuację w zewnętrznym kręgu odpowiada zespół.

Informacje zwrotne, które są gromadzone i wykorzystywane przeciwko Państwu

A teraz kwestia, o której żaden dostawca nie pisze. Ludzie milczą podczas spotkań podsumowujących z powodu bardziej konkretnego niż nieśmiałość: szczerość może negatywnie wpłynąć na karierę. Ten strach ma konkretny charakter i przejawia się w prawdziwych historiach. Jeden z programistów opisał, jak uwagi z retrospekcji powróciły „podczas mojej corocznej oceny, gdzie zwrócono mi uwagę, że »zbyt często narzekam«”. Inny, bardziej cynicznie, stwierdził: „gromadzą wszystkie te skargi, aby wykorzystać je podczas corocznej oceny premii”.

To właśnie gromadzenie informacji zwrotnych — szczere uwagi, które są gromadzone, by później zostać wykorzystane przeciwko Państwu — i jest to najszybszy sposób na całkowite zniweczenie retrospektywy sprintu. Przewodnik po Scrumie opisuje retrospektywę sprintu jako proces, w którym zespół Scrumowy dokonuje samooceny. Proszę potraktować to dosłownie: zespół dokonuje samooceny. Dlaczego więc osoba podpisująca Państwa ocenę wyników siedzi w pokoju i robi notatki? Wystarczy jej milczenie — nikt, kto decyduje o Państwa awansie, nie musi wypowiadać ani słowa, aby skłonić Państwa do złagodzenia tego, co w innym przypadku by Państwo powiedzieli. W ramach projektu „Aristotle” firmy Google stwierdzono, że poczucie bezpieczeństwa psychicznego jest najważniejszym czynnikiem pozwalającym przewidzieć skuteczność zespołu; sama obecność menedżera często wystarcza, by je zniweczyć. (Mechanizmy tego zjawiska omówiliśmy w rozdziale poświęconym budowaniu przestrzeni zapewniającej bezpieczeństwo psychiczne.)

Proszę więc zidentyfikować ten strach i opracować strategię przeciwdziałania mu:

• Proszę nie dopuścić do udziału osób z uprawnieniami awansowymi w spotkaniu. Proszę przekazywać uzgodnione działania przełożonym, a nie przydzielać im miejsca. Zespół, którego praca jest utrudniona przez obecność przełożonego, nie jest w stanie przeprowadzić przejrzystej retrospektywy, a żadna technika facylitacyjna nie pozwoli tego naprawić.
• Zgadzam się, że to, co zostało powiedziane, pozostaje w tym pomieszczeniu. Na zewnątrz trafiają jedynie te działania, które zespół zdecyduje się upublicznić. To właśnie dzięki temu ludzie w ogóle mogą się wypowiadać.
• Niech anonimowość będzie opcją dostępną dla poszczególnych pomysłów, a nie trybem stałym. Anonimowość wyrównuje relacje władzy i pozwala ujawnić drażliwe kwestie; stosowana jako stała „podpora” podważa zaufanie, które starają się Państwo budować. Proszę pozwolić użytkownikom wybierać tę opcję w przypadku tych pomysłów, które tego wymagają.
• Należy zachować ostrożność przy wprowadzaniu wskaźników. Obiektywne dane (prędkość, czas cyklu) powinny być omawiane podczas retrospektywy — jednak w momencie, gdy prędkość staje się celem, w odniesieniu do którego ocenia się zespół, tworzy się [mechanizm „ratchet prędkości”/guides/agile-theatre/agile-theatre-glossary/#velocity-ratchet], a ludzie zaczynają optymalizować wyniki liczbowe zamiast mówić prawdę. Jest to tryb awarii systemu, który zamienia szczerość w wynik.

Luka w kontynuacji ruchu — oraz zmiana perspektywy, która ją eliminuje

Załóżmy, że kwestie związane z uprawnieniami i bezpieczeństwem zostały rozwiązane. Retrospektywy nadal nie radzą sobie z najczęściej powtarzającym się zarzutem w całej dyskusji: „Retrospektywy pozwalają na wyrażenie obaw, ale w rzeczywistości nigdy nie podejmuje się żadnych działań w związku z nimi”. Lub, mówiąc bardziej dosadnie: „Nigdy nie widziałem, by poza słowami działo się cokolwiek”. Ten pełen rezygnacji ton — „ta kwestia nie zostanie rozwiązana” — oddaje odczucia związane z retrospektywami przypominającymi „Dzień świstaka” z perspektywy osób w nich uczestniczących. Nie jest to tylko wyobraźnia: według powszechnie przytaczanych danych Scrum Alliance jedynie około jedna trzecia zespołów konsekwentnie realizuje zadania wynikające z retrospektyw. Pozostałe są zapisywane na tablicy, a następnie wymazywane. Powszechne przekonania nieco wyolbrzymiają jednak ten pesymistyczny obraz — przeanalizowaliśmy ile zadań wynikających z retrospektyw faktycznie zostaje zrealizowanych na podstawie setek tysięcy rzeczywistych działań i okazało się, że wskaźnik realizacji wynosi raczej trzy na cztery, przy czym częstotliwość spotkań i poczucie odpowiedzialności decydują o tym, po której stronie tej luki znajdzie się dany zespół.

Dwie poprawki, przy czym ta druga jest najważniejsza.

Po pierwsze, proszę przestać próbować naprawiać wszystko. Retrospektywa, w ramach której wytycza się dziesięć zadań do realizacji, nie prowadzi do wykonania żadnego z nich. Proszę ograniczyć się do jednego usprawnienia, w które zespół naprawdę się zaangażuje, i rozpoczynać każdą retrospektywę od podsumowania tej jednej rzeczy z poprzedniego spotkania, zanim ustalą Państwo nowe zadania. Jeśli nie zostało to zrealizowane, jest to najbardziej przydatna rozmowa w całym pomieszczeniu. Sięganie po nowy format jest pierwszą rzeczą, którą próbują zespoły, a jednocześnie najmniej prawdopodobną, by pomogła — zamiana metody „Mad/Sad/Glad” na model żaglówki to tylko kosmetyczna zmiana, jeśli brakuje konsekwencji w działaniu.

Po drugie — i jest to zmiana perspektywy zaczerpnięta z publikacji Agile Retrospectives, wydanie drugie, w kierunku której zmierza cała ta dziedzina — proszę przestać traktować zadanie do wykonania jako cel sam w sobie. Kluczową zmianą wprowadzoną przez Derby’ego, Larsena i Davida Horowitza jest to, że kryterium sukcesu stanowi nauka, a nie wykonanie zadania. Zastąpcie zadanie do wykonania eksperymentem: hipotezą, którą sprawdzacie („jeśli będziemy pracować w parach nad ryzykownym zadaniem, ograniczymy konieczność poprawek”), terminem jej weryfikacji oraz szczerą analizą tego, co faktycznie się wydarzyło. Retrospektywa, która nie przyniosła żadnych działań z listy kontrolnej, ale rzeczywiście czegoś nauczyła zespół, nie jest retrospektywą nieudaną. Ten jeden krok rozwiewa zarzut, że „nic się nie zmienia”, ponieważ celem przestaje być wykonanie rutynowego zadania, a staje się zmianą, którą faktycznie wprowadzają Państwo w życie.

Milczenie nie oznacza obojętności — to sygnał

Cichsza porażka: spotkanie w stylu retro, podczas którego dwie z ośmiu osób mówią przez pięć minut, a reszta to martwa cisza, i żadna z wypróbowanych formuł ani gotowych tablic nie zmienia sytuacji. Łatwo jest to zinterpretować jako brak zaangażowania zespołu. Zazwyczaj jednak tak nie jest. Cisza podczas retrospektywy jest sygnałem, a nie samym problemem — wskazuje na brak zaufania, niejasny cel lub problem z przywództwem, o którym ludzie nie chcą mówić głośno. Praca zdalna pogarsza sytuację: wyłączone kamery, wyciszone mikrofony, brak energii.

Nie wypełniaj ciszy kolejnymi pytaniami. Zmień kolejność zabierania głosu. Przed rozpoczęciem dyskusji przeprowadź cichą, indywidualną burzę mózgów, aby uczestnicy najpierw zapisali swoje pomysły, a dopiero potem zabierali głos — chroni to introwertyków oraz osoby, które nie chcą być tymi, które wypowiedzą coś na głos. Zbierz uwagi asynchronicznie z wyprzedzeniem. Pozwól uczestnikom przykleić karteczkę bez konieczności bronienia jej przed całym zgromadzeniem. Celem nie jest ożywione spotkanie, lecz rzetelne dane, a rzetelne dane często pojawiają się w ciszy.

Opłata za spotkanie stanowi rzeczywisty koszt, a nie pretekst

Wreszcie, krytyka, którą zwolennicy hasła „nigdy nie pomijajcie retrospektywy” zbyt pochopnie lekceważą: retrospektywy coś kosztują. „To kolejne spotkanie w moim kalendarzu, które potencjalnie może zakłócić stan głębokiej koncentracji, w jakim się znajdowałem” – napisał jeden z programistów – dodając to do spotkań stand-upowych, planowania, przeglądów i dopracowywania zadań. W przypadku krótkich cykli wyniki obliczeń są bezlitosne: zespoły realizujące tygodniowe sprinty opisują cotygodniowe planowanie i retrospektywy jako „obciążenie” – i mają rację. Pięćdziesiąt retrospektyw rocznie w dojrzałym zespole nie jest zaletą.

Rozwiązaniem nie jest pomijanie spotkań retrospektywnych, lecz dostosowanie ich częstotliwości do potrzeb. Nowo utworzony zespół, znajdujący się pod presją, odniesie korzyści z organizowania retrospektywy po każdym sprincie. Stabilny zespół, który wciąż prowadzi te same, powierzchowne rozmowy, sygnalizuje, że częstotliwość spotkań jest niewłaściwa, a nie że refleksja jest bezwartościowa. Przejdźcie na spotkania co dwa tygodnie lub organizujcie retrospektywy w oparciu o zdarzenia — po wydaniu, po awarii, po trudnym sprincie — kiedy rzeczywiście jest coś do przeanalizowania. Częstotliwość spotkań to regulator, a nie przykazanie. (Ta sama logika dotycząca przeciążenia dotyczy każdej ceremonii — zobacz antywzorce spotkań stand-up oraz brak kontynuacji działań w naszym przewodniku „Agile Theatre”).

Proszę rozwiązać problem z zaangażowaniem, zadbać o uczciwość, doprowadzić do końca jedną konkretną sprawę oraz odpowiednio dostosować tempo spotkań – a wtedy retrospektywa przestanie pełnić rolę „zaworu bezpieczeństwa”. Stanie się ona tą jedną godziną w trakcie sprintu, podczas której zespół faktycznie zmienia sposób swojego działania – a o to przecież zawsze chodziło. Narzędzie do retrospektywy online pomaga w jeden konkretny sposób: przenosi każdą uzgodnioną zmianę do listy działań podlegających monitorowaniu, dzięki czemu realizacja tych zmian trwa również w tygodniu następującym po spotkaniu.

Najczęściej zadawane pytania

Dlaczego po naszych retrospektywach nigdy nic się nie zmienia?

Zazwyczaj dzieje się tak, ponieważ kwestie o największym znaczeniu wykraczają poza kompetencje zespołu, a podczas retrospektywy nie ma możliwości przekazania ich dalej. Tablica zapełnia się problemami, których zespół nie jest w stanie rozwiązać samodzielnie — liczba pracowników, zależności, niesprawny proces wdrażania — i wszyscy opuszczają spotkanie, opisując jedynie obecną sytuację, zamiast ją zmienić. Rozwiązaniem jest klasyfikacja każdego punktu według tego, kto faktycznie jest za niego odpowiedzialny, skupienie się na jednym, kontrolowanym przez zespół obszarze wymagającym usprawnień oraz eskalowanie spraw wykraczających poza zakres kompetencji do wyższych szczebli, podając konkretną osobę odpowiedzialną i termin, zamiast po cichu je pomijać.

Co Państwo robią, gdy prawdziwy problem leży poza kontrolą zespołu?

Należy zgłosić tę sprawę oficjalnie. Proszę podzielić problemy na te, nad którymi zespół ma kontrolę, na te, na które może wpływać, oraz na te, na które może jedynie cierpieć (ćwiczenie „Kręgi i zupa” z książki Agile Retrospectives). Ogólna rada mówi, by zignorować zewnętrzny krąg i pozostać w kręgu wpływu. W ten sposób retrospektywa staje się teatrem. Zamiast tego proszę przekształcić kwestie z zewnętrznego pierścienia w widoczną prośbę — tzw. „Retrospektywę Radiator” — która określa przeszkodę, jej skutki oraz osobę, która powinna podjąć działania, a następnie przedstawić ją osobom, które mogą tę sprawę rozwiązać. Retrospektywa, która ujawnia wyłącznie problemy, które zespół jest już w stanie rozwiązać, jest wygodna, ale nieuczciwa.

Czy w retrospektywie można bez obaw mówić szczerze?

Tylko wtedy, gdy szczerość nie wiąże się z żadnymi konsekwencjami zawodowymi. Programiści często zgłaszają, że opinie z sesji retrospektywnych powracają podczas oceny wyników pracy jako dowód na to, że „zbyt często zgłaszają zastrzeżenia”. Jeśli w pomieszczeniu obecna jest osoba decydująca o awansach lub jeśli to, co zostało powiedziane, zostanie odłożone na później, uczestnicy milkną i twierdzą, że wszystko jest w porządku. Należy świadomie chronić szczerość. Należy wykluczyć z sesji kierowników liniowych odpowiedzialnych za awanse, uzgodnić, że to, co zostało omówione, pozostaje w pomieszczeniu, a na zewnątrz wychodzą jedynie uzgodnione działania, oraz zapewnić anonimowość w odniesieniu do poszczególnych pomysłów, a nie w trybie „wszystko albo nic”.

Czy retrospektywy to strata czasu?

Sytuacja ta ma miejsce, gdy jedyną miarą sukcesu jest zrealizowane zadanie, ponieważ większość sprintów nie dostarcza Państwu gotowego rozwiązania. Proszę spojrzeć na cel z innej perspektywy — retrospektywa kończy się sukcesem, gdy zespół wyciąga wnioski, które wykorzysta w kolejnym sprincie, nawet bez zadania, które można odhaczyć na liście, oraz gdy przeprowadza jeden rzetelny eksperyment zamiast dziesięciu porzuconych zadań. Retrospektywy pełnią również mniej widoczną rolę — wczesne ujawnianie napięć i utrzymywanie spójności zespołu — która nigdy nie pojawia się jako konkretne zadanie do wykonania, ale jest rzeczywista. Postrzegane jako rytuał służący nauce, a nie jako fabryka zadań, zasługują na swoje miejsce.