Nieważność: gdy ceremonia niczego nie zmienia

Najpoważniejszym rodzajem niepowodzenia nie jest źle przeprowadzona ceremonia. Jest nim dobrze przeprowadzona ceremonia, która niczego nie zmienia.

Można nagrać spotkanie standupowe, można przeładować sesję planowania, a zespół i tak odczuje napięcie i opór. Brak konsekwencji jest jeszcze gorszy, ponieważ wydaje się, że wszystko jest w porządku. Retrospektywa się odbywa, ludzie są szczerzy, zapisuje się karteczki samoprzylepne, wszyscy kiwają głowami. Potem zaczyna się kolejny sprint i nic się nie zmienia. Powtórzcie to kilka razy, a nie spotkacie się z gniewem; pojawi się coś cichszego i bardziej niszczącego. Jak ujął to jeden z inżynierów na Hacker News: „Retrospektywy pozwalają na wyrażenie obaw, ale z mojego doświadczenia wynika, że w rzeczywistości nigdy nic się z tymi obawami nie dzieje”. Inny, mówiąc bardziej dosadnie: „Nigdy nie widziałem, by działo się cokolwiek poza słowami”. Jest to najczęściej powtarzana skarga dotycząca retrospektyw w każdym miejscu i nie jest to ta skarga, za jaką uznają ją porady w naszej branży.

Słowa i tylko słowa

Standardowo uważa się, że zespoły „zapominają o zapisywaniu zadań do realizacji”, więc typowym rozwiązaniem jest tworzenie lepszych zadań: formułowanie ich zgodnie z zasadą SMART, wyznaczanie osoby odpowiedzialnej oraz dodawanie ich do tablicy. Pomija to jednak rzeczywistą przyczynę problemu. Problem rzadko polega na tym, że nie zapisano żadnego zadania; chodzi o to, że zadanie zostało zapisane, dodane do listy zadań do wykonania, a następnie pozostawało tam na zawsze, podczas gdy podczas kolejnej retrospektywy sprintu powstały trzy kolejne. „Powtarzam te same punkty retrospektywy sprintu za sprintem, a one nie są realizowane” – brzmi jedna z pełnych rezygnacji relacji. „To zadanie nie zostanie zrealizowane. To trochę smutne”. Według jednego z często cytowanych badań tylko około jedna trzecia zespołów konsekwentnie realizuje zadania wynikające z retrospekcji, a pozostałe dwie trzecie uczą się, sprint po sprincie, że ceremonia ta generuje jedynie słowa i nic więcej. Należy jednak podchodzić do tych powszechnych przekonań z ostrożnością: nasze własne dane dotyczące odsetka zadań z retrospektyw, które faktycznie zostają zrealizowane, wskazują, że wskaźnik ten wynosi raczej trzy czwarte, a także pokazują, że o tej różnicy decyduje poczucie odpowiedzialności i regularność, a nie wkład pracy.

Rozwiązaniem, które faktycznie się sprawdza, nie jest podejmowanie większej liczby działań. Chodzi o mniejszą liczbę. Ograniczcie się do jednego. Pojedyncze usprawnienie, za które zespół naprawdę się angażuje i które jest omawiane na samym początku kolejnego spotkania retrospektywnego, zanim zajmie się czymkolwiek innym, przewyższa listę dziesięciu punktów, z których wszystkie po cichu odchodzą w zapomnienie. Nie jest to nowa rada: Johanna Rothman w książce „Create Your Successful Agile Project” zalecała wybór jednego punktu, traktowanego jako eksperyment i włączonego do kolejnego bloku prac zespołu. Jeśli ustali się zbyt wiele punktów działania, połowa z nich nie zostanie zrealizowana, a ta połowa, która nie zostanie zrealizowana, uczy zespół, że nic z tego nie ma znaczenia. Jedno zadanie, przypisane konkretnej osobie i z ustalonym terminem przeglądu, zamyka pętlę, którą długa lista pozostawia otwartą. Rozdział naszego przewodnika po retrospektywach zatytułowany „Dlaczego retrospektywy kończą się niepowodzeniem” omawia realizację tej pętli w ramach samej ceremonii, a retrospektywa polegająca na odhaczaniu pozycji z listy, opisana w rozdziale „Wydajność”, pokazuje, jak wygląda ta pustka, zanim zespół całkowicie się podda.

Zawór ciśnieniowy

Istnieje jednak głębszy wymiar tej pustki i właśnie w tej kwestii porady naszej branży są błędne. Czasami działania nie zostają zrealizowane, ponieważ zespół nigdy nie byłby w stanie ich zrealizować: prawdziwe problemy rzeczywiście wykraczają poza zakres kompetencji zespołu. Budżet, liczba pracowników, zależności między zespołami, decyzja dotycząca architektury podjęta dwa szczeble wyżej, termin wyznaczony przez dział sprzedaży. Zespół może wymieniać te przyczyny bez końca. Nie jest jednak w stanie żadnej z nich rozwiązać. W ten sposób retrospektywa staje się zaworem bezpieczeństwa: miejscem, w którym można dać upust emocjom, aby kierownictwo miało poczucie, że głos zespołu został wysłuchany, przy braku mechanizmu pozwalającego na zmianę sytuacji, która jest przedmiotem tych wyrazów niezadowolenia.

Najbardziej dosadne sformułowanie tej kwestii pochodzi od programisty piszącego na platformie dev.to i warto je zacytować w całości: „Retrospektywa stała się zaworem bezpieczeństwa. Pozory głosu bez rzeczywistej siły oddziaływania”. W tym samym eseju zawarta jest uwaga, która powinna wywołać niepokój u każdego coacha: „obwinianie facylitacji jest jak obwinianie skrzynki sugestii za to, że kierownictwo nie zapoznaje się z sugestiami”. Nie da się rozwiązać problemu braku władzy za pomocą facylitacji. A na Hacker News stwierdzono wprost: retrospektywa to „ceremonia bez rzeczywistego celu, ponieważ zazwyczaj głębsze kwestie poruszane przez uczestników nie leżą w zakresie kompetencji danego zespołu”. Co gorsza: „daje to kierownictwu pretekst do niepodjmowania działań naprawczych”.

Właśnie w tym miejscu większość porad dostawców wyrządza rzeczywistą szkodę. Standardowa lista antywzorców nakazuje zespołom, by „trzymały się w granicach swojego kręgu wpływów” (przestały poruszać kwestie, których nie są w stanie zmienić). Ujęta jako problem dyscyplinarny zespołu, rada ta jest całkowicie błędna. Nakazuje ona zespołowi pomijać prawdziwą przeszkodę i skupiać się wyłącznie na drobnych, bezpiecznych sprawach, nad którymi zespół ma kontrolę – a właśnie w ten sposób retrospektywa zamienia się w wygodną inscenizację. Pozostawanie w kręgu wpływów jest złą radą, gdy najważniejsza kwestia w pomieszczeniu znajduje się poza nim.

Proszę kierować energię na zewnątrz, a nie tłumić ją w sobie

Dobrą wiadomością jest to, że w tekście kanonicznym wprowadzono już poprawkę, a dokonano tego właśnie w obecnym wydaniu. W drugim wydaniu książki Agile Retrospectives (2024 r.), w którym David Horowitz dołączył do Esther Derby i Diany Larsen, dodano cały rozdział poświęcony kwestiom pozostającym poza kontrolą zespołu. Problem stał się na tyle dotkliwy, że autorzy podręcznika musieli nadążyć za zmianami. Trzy z przedstawionych w nim narzędzi stanowią antidotum na ten problem:

• Kręgi i „zupa”: proszę posortować wszystkie sprawy według tego, kto jest za nie odpowiedzialny, dzieląc je na te, nad którymi zespół ma kontrolę, te, na które może wpływać, oraz te, które znajdują się w „zupie” – na które może jedynie reagować. Jest to klasyfikacja według odpowiedzialności, która zastępuje zasadę „trzymaj się swojego kręgu” zasadą „kieruj każdą sprawę do osoby, która faktycznie może podjąć w niej działania”.
• Rozwiązania 15-procentowe: w przypadku poważnych, trudnych do rozwiązania problemów należy znaleźć ten fragment, od którego zespół może zacząć już teraz, bez konieczności uzyskiwania czyjejkolwiek zgody. Nie chodzi o całe rozwiązanie, lecz o te 15% problemu, które jest w zasięgu ręki. Postęp w niewielkiej części jest lepszy niż bezczynność w całości.
• Retrospektywne „grzejniki”: sprawcie, by eskalowane problemy stały się widoczne na zewnątrz, na tablicy widocznej dla kierownictwa, z możliwością śledzenia ich w czasie. Radiator jest przeciwieństwem zaworu: zawór uwalnia ciśnienie i je ukrywa; radiator natomiast sygnalizuje nierozwiązaną sprawę, dopóki nie zajmie się nią osoba uprawniona do jej rozwiązania. Proszę eskalować sprawy oznaczone na czerwono, podając konkretne nazwiska.

Takie są jasne wytyczne wynikające z badań, poparte kanonem: selekcja według przynależności, eskalowanie spraw oznaczonych na czerwono z podaniem nazwiska i daty, rozprzestrzenianie informacji zamiast ich wyładowywania. Retro, które postępuje w ten sposób, szczerze podchodzi do kwestii władzy. Retro, które pomija te zasady, jest jedynie zaworem bezpieczeństwa z moderatorem.

Chodzi o samą naukę, a nie o listę zadań do wykonania

Ostatnie przeformułowanie zamyka cykl całego trybu. W drugim wydaniu zmieniono również samo kryterium sukcesu – z działań do uczenia się. Stanowisko to (i z ulgą słyszy się to z oficjalnego źródła) głosi, że retrospektywa bez konkretnego działania nie jest porażką, jeśli zespół czegoś się nauczył. Jednostką zmiany staje się eksperyment: hipoteza, którą testuje się z ustalonym terminem przeglądu, a nie zadanie do wykonania, które zalega w backlogu. „Uważamy, że praca w parach podczas wdrażania zmniejszy nasz wskaźnik wycofywania zmian; wypróbujemy to przez dwa sprinty i sprawdzimy” – to jest eksperyment. „Ulepszenie wdrożeń” to karteczka samoprzylepna, która trafia do kosza.

Uwzględnia to również koszt, który nigdy nie pojawia się na listach antywzorców: emocjonalny ciężar związany z sesją polegającą wyłącznie na wyładowywaniu emocji. Jak ujął to jeden z uczestników, retrospektywa może być „ponad godziną spędzoną głównie na słuchaniu, jak inni narzekają na różne sprawy, co mnie przygnębia”. Retrospektywa polegająca wyłącznie na wyładowywaniu emocji nie tylko nie rozwiązuje problemów. Stanowi ona obciążenie dla osób, które muszą znosić te narzekania. Rozwiązaniem nie jest zakazywanie okazywania uczuć, lecz zapewnienie im ujścia: przekształcenie czerwonych elementów w eksperymenty przypisane konkretnym osobom, z określonym terminem realizacji i z jasno zdefiniowanym zakresem oddziaływania, dzięki czemu ta godzina przestaje być przestrzenią, w której krąży jedynie frustracja.

To jest droga wyjścia z pustki i z przewodnika. Należy sprawić, by pętla była na tyle mała, by można ją było zamknąć, przeprowadzać selekcję zadań na tyle uczciwie, by eskalować to, czego zespół nie jest w stanie naprawić, oraz mierzyć postępy w nauce zamiast liczyć działania, ponieważ szczerość, która niczego nie zmienia, w końcu przestaje być szczerością. Cztery tryby (Wydajność, Władza, Przeciążenie i Pustka) są w gruncie rzeczy tym samym pytaniem zadanym na cztery sposoby: czy ta ceremonia spełnia swoją rolę, czy tylko ją odgrywa?

Najczęściej zadawane pytania

Co Państwo robią, gdy podczas każdego przeglądu pojawiają się te same problemy?

Proszę ustalić, dlaczego się powtarzają, ponieważ dwa różne problemy mogą wyglądać identycznie z perspektywy zespołu. Jeśli zadanie zostało zapisane, ale nikt nie przejął za nie odpowiedzialności, pozostaje ono w zaległościach, podczas gdy podczas kolejnego spotkania retrospektywnego dodaje się trzy kolejne. Ograniczcie liczbę elementów, za które ktoś jest odpowiedzialny, do jednego, wyznaczając termin przeglądu, a następne retrospektywę rozpocznijcie od sprawdzenia tego zadania. Jeśli problem wciąż powraca, ponieważ faktycznie leży poza kontrolą zespołu, ponowne umieszczenie go na liście nigdy nie przyniesie efektu: dokonajcie selekcji pod kątem osoby odpowiedzialnej i eskalujcie sprawę, podając imię i nazwisko oraz datę, zamiast ponownie dawać upust frustracji.

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

Nie należy nakłaniać zespołu do zgłaszania mniej istotnych problemów. W ten sposób retrospektywa zamienia się w przedstawienie teatralne. Należy dokonać selekcji wszystkich problemów według tego, kto faktycznie jest za nie odpowiedzialny, a następnie eskalować te o najwyższym priorytecie do wyższych szczebli, podając imię i nazwisko oraz datę, i umieścić je w widocznym miejscu na tablicy retrospektywnej, aby nie można było ich po cichu pominąć. Trzymanie się własnego kręgu wpływów jest złą radą, gdy oznacza to ukrywanie prawdziwej przeszkody.

W jaki sposób możemy doprowadzić do tego, by zadania wynikające z retrospektywy zostały faktycznie zrealizowane?

Ograniczcie się do jednego. Pojedyncze usprawnienie, za które zespół naprawdę się angażuje i które jest omawiane na samym początku kolejnego spotkania retrospektywnego, jeszcze przed innymi sprawami, jest lepsze niż lista dziesięciu usprawnień, z których wszystkie po cichu odchodzą w zapomnienie. Wyznaczcie osobę odpowiedzialną i termin przeglądu, a następnie potraktujcie to jako eksperyment oparty na hipotezie, a nie jako obowiązek z listy zadań.

Czy retrospektywa wymaga ustalenia działań do wykonania?

Nie, a upieranie się, że tak jest, stanowi część problemu. W drugim wydaniu książki „Agile Retrospectives” kryterium sukcesu definiuje się na nowo jako naukę, a nie listę zadań do wykonania: retrospektywa, podczas której zespół rzeczywiście zrozumiał coś nowego, nie jest porażką tylko dlatego, że nie zaowocowała listą zadań do wykonania. Przeprowadzajcie eksperymenty, z których można wyciągnąć wnioski, a nie zadania, z powodu których będą Państwo odczuwać poczucie winy.

Materiały powiązane

• Władza: kiedy autorytet przejmuje kontrolę nad procedurą. Dlaczego kwestie, o których warto poruszyć, tak często wykraczają poza zakres kompetencji zespołu?
• Spektakl: ceremonia, którą organizują Państwo dla publiczności. Retro w stylu „odhaczania punktów z listy”, zanim zespół zrezygnuje z tego pomysłu.
• Jak stworzyć przestrzeń zapewniającą bezpieczeństwo psychologiczne. Szczerość, która ma gdzie się wyrazić.
• Retrospektywna Główna Dyrektywa. Norma zapewniająca uczciwość w tym pomieszczeniu.
• Retrospektywa sprintu (ceremonia). Miejsce retrospektywy w cyklu oraz pętla, którą ma ona zamknąć.
• Słownik terminów związanych z agile theatre. Definicje czterech określonych rodzajów niepowodzeń.