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 pojawiają się, przyklejają karteczki, zgadzają się na dwa lub trzy zadania do wykonania i wychodzą. Następnie nic się nie zmienia w sposobie faktycznego wykonywania pracy. Jeśli robią Państwo to czterdzieści razy w roku, nie wypracowali Państwo 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 wyłącznie słowa.

Standardowe porady traktują nieudaną retrospektywę jako problem związany z prowadzeniem spotkania: zmiana formatu, sformułowanie działań zgodnych z zasadami SMART, dodanie lodołamacza. 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 konsekwencji. Żadny lodołamacz nie rozwiązuje żadnego z nich. Jeśli faktycznie problemem jest dla Państwa prowadzenie sesji, rozwiązanie leży w prowadzeniu skutecznych retrospektyw, a nie w niniejszym rozdziale.

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

Oto najgłębsza krytyka retrospektyw, a także kwestia, którą w naszym własnym wpisie poświęconym antywzorcom przedstawiliśmy w sposób błędny. Kiedy programista stwierdza, że „nigdy nic się nie dzieje”, zazwyczaj nie ma na myśli tego, że zespół zapomniał sporządzić listę działań do wykonania. 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 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 się zmienić. Ludzie dają upust emocjom, kierownictwo ma poczucie, ż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 problemy 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” autorstwa Esther Derby i Diany Larsen z książki Agile Retrospectives (wydanie drugie). 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 czyjejkolwiek zgody, pozwala utrzymać dynamikę działania w obrębie pierścienia wpływu, podczas gdy duże przeszkody stopniowo się rozwiązują. 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 ujawnia 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, by 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 najszybszy sposób na całkowite 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ńską ocenę wyników, siedzi w pomieszczeniu 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 zniwelować. (Zasady działania tego mechanizmu omówiliśmy w rozdziale poświęconym budowaniu przestrzeni zapewniającej bezpieczeństwo psychologiczne.)

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

• Proszę nie dopuścić do udziału osób decyzyjnych w spotkaniu. Proszę przekazywać uzgodnione działania przełożonym, a nie zajmować stanowiska kierownicze. Zespół, którego praca jest utrudniona przez obecność kierownika, nie jest w stanie przeprowadzić przejrzystej retrospektywy i ż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 mają odwagę zabierać głos.
• 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łe wsparcie podważa zaufanie, które starają się Państwo budować. Proszę pozwolić użytkownikom decydować o jej zastosowaniu 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 eskalacji prędkości, a ludzie zaczynają optymalizować wyniki liczbowe zamiast mówić prawdę. Jest to tryb awarii wydajności, 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 zawodzą w odniesieniu do najczęściej powtarzanej krytyki w całej dyskusji: „Retrospektywy pozwalają na wyrażenie obaw, ale w rzeczywistości nigdy nie następują żadne działania 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”, widzianą 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ą. Przeprowadziliśmy pomiary ile zadań wynikających z retrospektywy 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 zapisuje się na tablicy, a potem się wymazuje.

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 osiąga każda pozycja na niej: według naszych danych w przypadku retrospekcji, z których wychodzi się z dziesięcioma lub więcej działaniami, realizuje się około 56% z nich, podczas gdy w przypadku retrospekcji, z których wychodzi się z jednym do trzech działań, odsetek ten wynosi około 79%. Ograniczcie się do jednego ulepszenia, do którego zespół naprawdę się zobowiązuje, uwzględnijcie je w planie pracy na następny sprint, zamiast pozostawiać je na tablicy, i rozpoczynajcie każdą retrospekcję 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 zaproponowana w publikacji Agile Retrospectives, wydanie drugie, w kierunku której zmierza cała ta dziedzina. Kluczową zmianą wprowadzoną 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 przeglądu 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 ruch rozwiewa zarzut, że „nic się nie zmienia”, ponieważ celem przestaje być wykonanie rutynowego zadania, a staje się zmianą, którą faktycznie wprowadzacie. Johanna Rothman stosowała tę samą zamianę na długo przed tym, zanim stała się ona standardem w retrospektywach, w publikacji Create Your Successful Agile Project: jeden punkt, przeprowadzony jako eksperyment, z kolejnym blokiem prac 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 martwa cisza, i żadna z wypróbowanych formuł ani gotowych tablic nie zmienia sytuacji. Łatwo jest to odebrać 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ść zabierających głos. Przed każdą dyskusją przeprowadź cichą, indywidualną burzę mózgów, tak aby uczestnicy najpierw zapisali swoje pomysły, a dopiero potem zabrali 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ć głęboką koncentrację, w której właśnie się znajdowałem” – napisał jeden z programistów. Do tego dochodzą spotkania stand-upowe, planowanie, przeglądy i dopracowywanie 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 retrospektyw, lecz dostosowanie ich częstotliwości. Nowo utworzony zespół, znajdujący się pod presją, odniesie korzyści z przeprowadzania 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 spoty co dwa tygodnie lub organizujcie retrospektywy w oparciu o zdarzenia (po wydaniu, po awarii, po trudnym sprincie), gdy rzeczywiście istnieje coś, co warto przeanalizować. Częstotliwość spotkań jest kwestią dostosowania, a nie sztywnym nakazem. (Ta sama logika dotycząca przeciążenia dotyczy każdej ceremonii: proszę zapoznać się z antywzorcami spotkań standup oraz brakiem 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 – 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. Narzędzie do retrospektyw online pomaga w 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 spotkanie retrospektywne nie zapewnia mechanizmu 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 uczestnicy opuszczają spotkanie, opisując jedynie obecną sytuację, zamiast ją zmienić. Rozwiązaniem jest klasyfikowanie każdego zgłoszenia pod kątem tego, kto faktycznie jest za nie 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ę teatrem. Zamiast tego proszę przekształcić elementy 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łania, a następnie przedstawić ją osobom, które mogą tę sprawę załatwić. Retrospektywa, która ujawnia jedynie problemy, które zespół już potrafi rozwiązać, jest wygodna, ale nieuczciwa.

Czy w retrospektywie można bezpiecznie być szczerym?

Jedynie wtedy, gdy szczerość nie wiąże się z żadnymi konsekwencjami zawodowymi. Programiści często zgłaszają, że uwagi 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 milczą 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?

Są one skuteczne wtedy, gdy jedyną miarą sukcesu jest zrealizowane zadanie, ponieważ większość sprintów nie dostarcza Państwu gotowego, uporządkowanego 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ż cichszą 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ł służący nauce, a nie jako fabryka zadań, zasługują na swoje miejsce.