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

Pański zespół organizuje retrospektywę po każdym sprincie. Uczestnicy pojawiają się, przyklejają karteczki, zgadzają się na dwa lub trzy zadania do wykonania i wychodzą. Potem nic się nie zmienia w sposobie faktycznego wykonywania pracy. Jeśli powtarza się to czterdzieści razy w roku, nie wykształci się nawyku doskonalenia. Wykształcili Państwo nawyk rozmawiania o doskonaleniu. 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 zasadą 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 retrospektyw i warto je wyeliminować. W niniejszym rozdziale skupiamy 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 kontynuacji działań. Żadna aktywność lodołamacza nie ma na nie wpływu. Jeśli faktycznie problemem jest dla Państwa prowadzenie spotkania, rozwiązaniem jest organizowanie skutecznych retrospektyw, a nie to, co opisano w niniejszym rozdziale.

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

Oto najgłębsza krytyka retrospektyw – i ta, którą w naszym własnym wpisie poświęconym antywzorcom przedstawiliśmy w sposób błędny. 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 nieprzeprowadzania zmian lub nie wsłuchiwania się w opinie, ponieważ retrospektywa ma rzekomo służyć jako miejsce na wyładowanie niezadowolenia”.

Na tym polega pułapka. Sesja retrospektywna zamienia się w zawór bezpieczeństwa: zespół może zabrać głos 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 czyta zawartych w niej propozycji”. Ż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 („proszę przestać 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 proszę przyjąć bardziej zdecydowane stanowisko. Proszę posortować wszystkie kwestie według tego, kto faktycznie jest za nie odpowiedzialny: co zespół kontroluje, na co może wpływać, a co może jedynie znosić. Jest to ćwiczenie „Circles and Soup” z książki Esther Derby i Diany Larsen Agile Retrospectives (wydanie drugie). Celem zewnętrznego pierścienia nie jest „ignorowanie tych kwestii”. Stanowi on punkt wyjścia do eskalacji.

Nie wszystko prowadzi do eskalacji i nie wszystko jest beznadziejne. „Rozwiązania 15%” – technika z zakresu Liberating Structures polegająca na znalezieniu najmniejszej zmiany, jaką zespół może wprowadzić bez zgody kogokolwiek – pozwala utrzymać tempo działań w kręgu wpływu, podczas gdy poważniejsze przeszkody stopniowo się rozwiązują. Jednak rzetelna retrospekcja nie pozwala udawać, że za sytuację w kręgu zewnętrznym 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 są gromadzone, by później zostać wykorzystane przeciwko Państwu, i jest to najszybszy sposób na zniweczenie retrospektywy sprintu. Przewodnik po Scrumie opisuje retrospektywę sprintu jako proces, w którym zespół Scrum sam siebie analizuje. Proszę potraktować to dosłownie: zespół analizuje sam siebie. Dlaczego więc osoba, która podpisuje 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. Projekt „Aristotle” firmy Google wykazał, że bezpieczeństwo psychologiczne jest najważniejszym czynnikiem prognostycznym skuteczności zespołu; sama obecność menedżera często wystarcza, by je zniweczyć. (Mechanizmy tego zjawiska omówiono w rozdziale poświęconym budowaniu przestrzeni zapewniającej bezpieczeństwo psychologiczne.)

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

• Proszę nie dopuścić do udziału osób decyzyjnych w spotkaniu. Proszę przekazywać przełożonym uzgodnione działania, a nie przydzielać im miejsca. Zespół, którego praca jest utrudniona przez obecność kierownika, 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, ale w momencie, gdy prędkość staje się celem, w stosunku do którego ocenia się zespół, tworzy się mechanizm „ratchet prędkości”, a pracownicy zaczynają optymalizować tę wartość zamiast mówić prawdę. Jest to tryb awarii, który zamienia szczerość w wynik.

Brak wykończenia ruchu oraz zmiana perspektywy, która to naprawia

Załóżmy, że kwestie związane z uprawnieniami i bezpieczeństwem zostały rozwiązane. Retrospektywy nadal nie radzą sobie z najczęściej powtarzanym 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 atmosferę retrospektyw przypominających film „Dzień świstaka”, jak odczuwają je uczestnicy od środka. Nie jest to wytworem wyobraźni: powszechnie powtarzana i często przytaczana liczba, zgodnie z którą jedynie około jedna trzecia zespołów konsekwentnie realizuje zadania wynikające z retrospektyw, okazuje się być zbyt pesymistyczną prognozą. Przeanalizowaliśmy, ile zadań wynikających z retrospektyw faktycznie zostaje zrealizowanych na podstawie setek tysięcy rzeczywistych działań: wskaźnik realizacji jest bliższy trzem na cztery, a częstotliwość spotkań i poczucie odpowiedzialności decydują o tym, po której stronie tej luki znajdzie się dany zespół. To, co w powszechnym przekonaniu jest słuszne, to charakter porażki. Zadanie, za które nikt nie bierze odpowiedzialności, bez wyznaczonego terminu, w zespole pozbawionym rytmu pracy, jest tym, które zostaje zapisane na tablicy, a następnie wymazane.

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

Po pierwsze, proszę przestać próbować naprawiać wszystko. Im dłuższa lista, tym gorsze wyniki przynosi każda pozycja na niej: według naszych danych w przypadku retrospektyw, z których wychodzi się z dziesięcioma lub więcej działaniami, realizuje się około 56% z nich, w porównaniu z około 79% w przypadku retrospektyw, z których wychodzi się z jednym do trzech. Ograniczcie się do jednego ulepszenia, do którego zespół naprawdę się zobowiązuje, uwzględnijcie je w planie prac na następny sprint, zamiast pozostawiać je na tablicy, i rozpoczynajcie każdą retrospektywę od przeglądu tej jednej rzeczy z poprzedniego spotkania, zanim ustalicie cokolwiek nowego. Jeśli nie zostało to zrealizowane, jest to najbardziej konstruktywna rozmowa w sali. 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 żaglówkę to tylko kosmetyczna zmiana, jeśli brakuje konsekwencji w realizacji.

Po drugie, proszę przestać traktować zadanie do wykonania jako cel sam w sobie. Jest to zmiana perspektywy przedstawiona w książce „Agile Retrospectives” (wydanie drugie), w kierunku której zmierza cała ta dziedzina. Kluczową zmianą zaproponowaną przez Derby’ego, Larsena i Davida Horowitza jest to, że kryterium sukcesu stanowi nauka, a nie zrealizowane zadanie. Zastąpcie zadanie do wykonania eksperymentem: hipotezą, którą sprawdzacie („jeśli będziemy pracować w parach nad ryzykownym zadaniem, ograniczymy konieczność ponownej pracy”), terminem jej weryfikacji oraz szczerą analizą tego, co faktycznie się wydarzyło. Retrospektywa, która nie przyniosła żadnych działań do odhaczenia, 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 Państwo wdrażają. Johanna Rothman stosowała tę samą zamianę na długo przed tym, zanim stała się ona standardem w retrospektywach, w książce Create Your Successful Agile Project: jeden punkt, przeprowadzony jako eksperyment, z kolejnym blokiem pracy zespołu zaplanowanym tak, aby go uwzględnić.

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 cisza, i żadna z wypróbowanych formuł ani gotowych schematów dyskusji niczego nie zmienia. Łatwo jest to odczytać 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 podpowiedziami. 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 retrospekcji” zbyt pochopnie lekceważą: retrospekcje 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. Dochodzi to do spotkań standupowych, planowania, przeglądów i udoskonalania. Przy krótkich cyklach praca staje się wyczerpująca: zespoły realizujące tygodniowe sprinty opisują cotygodniowe planowanie i retrospektywy jako „obciążenie” – i mają rację. Pięćdziesiąt retrospekcji rocznie w dojrzałym zespole nie jest zaletą. Ta sama skarga pojawia się w skali organizacyjnej w badaniach dotyczących obciążenia spotkaniami, gdzie odsetek spotkań, które według uczestników można było pominąć, jest mierzony, a nie szacowany.

Rozwiązaniem nie jest pomijanie spotkań retrospektywnych, lecz dostosowanie ich częstotliwości. Nowo utworzony zespół, znajdujący się pod presją, odniesie korzyści z organizowania retrospektywy po każdym sprincie. Stabilny zespół, który wciąż powtarza 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), gdy rzeczywiście istnieje coś, co należy przeanalizować. Częstotliwość spotkań jest jak pokrętło, a nie przykazanie. (Ta sama logika dotycząca przeciążenia dotyczy każdej ceremonii: zapoznaj się z antywzorcami Standupów oraz brakiem konsekwencji 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 – 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, co zawsze było jej celem. Internetowe narzędzie do przeprowadzania retrospektyw 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), a 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 zespołu do wyższych szczebli, podając konkretną osobę odpowiedzialną oraz termin, zamiast po cichu je pomijać.

Co należy zrobić, 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ę przedstawieniem teatralnym. Zamiast tego proszę przekształcić kwestie z zewnętrznego pierścienia w widoczną prośbę (tzw. „Retrospective Radiator”), która określa przeszkodę, jej skutki oraz osobę, która powinna podjąć działanie, a następnie przedstawić ją osobom, które mogą tę sprawę rozwiązać. Retrospektywa, która ujawnia jedynie 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 informacje zwrotne z poprzednich sesji 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 wykorzystane w przyszłości, uczestnicy milkną i twierdzą, że wszystko jest w porządku. Celowo należy 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?

Są one skuteczne wtedy, 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ęć, utrzymywanie spójności zespołu), która nigdy nie pojawia się jako zadanie do wykonania, ale jest realna. Postrzegane jako rytuał uczenia się, a nie fabryka zadań, zasługują na swoje miejsce.