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 stand-upowe, można przeładować sesję planowania, a zespół i tak odczuje napięcie i opór. Brak konsekwencji w działaniu jest jeszcze gorszy, ponieważ wydaje się, że wszystko jest w porządku. Retrospektywa przebiega, ludzie są szczerzy, zapisuje się karteczki samoprzylepne, wszyscy kiwają głowami. Potem rozpoczyna 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 nie następują żadne działania w związku z tymi obawami”. 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ą poradnicy z 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 sporządzanie lepszych zadań: należy sformułować je zgodnie z zasadami SMART, wyznaczyć osobę odpowiedzialną i umieścić je na 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 pojawiły się trzy kolejne. „Powtarzam te same punkty retrospektywy sprintu za sprintem, a one nadal pozostają nierozwiązane” – brzmi jedna z pełnych rezygnacji relacji. „To zadanie nie zostanie zrealizowane. To trochę smutne”. Według jednej z często cytowanych ankiet tylko około jedna trzecia zespołów konsekwentnie realizuje swoje 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 opinii z rezerwą: nasze własne dane dotyczące odsetka zadań wynikających z retrospektywy, które faktycznie zostają zrealizowane wskazują, że wskaźnik realizacji jest bliższy trzem czwartym, 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 ulepszenie, w które zespół naprawdę się angażuje, omawiane na samym początku kolejnego retrospektywnego spotkania, zanim cokolwiek innego zostanie podjęte, 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 do realizacji, połowa z nich nie zostanie wykonana, a ta połowa, która nie zostanie zrealizowana, uczy zespół, że nic z tego nie ma znaczenia. Jedno zadanie, za które ktoś jest odpowiedzialny i które ma wyznaczony termin przeglądu, zamyka pętlę, którą długa lista pozostawia otwartą. Rozdział dlaczego retrospektywy kończą się niepowodzeniem w naszym przewodniku po retrospektywach omawia przeprowadzanie 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 przez cały dzień. Nie jest jednak w stanie żadnej z nich naprawić. 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órej dotyczą te narzekania.

Najbardziej dosadne stwierdzenie na ten temat pochodzi od programisty piszącego na stronie dev.to i warto je zacytować w całości: „Retrospektywa stała się zaworem bezpieczeństwa. Pozory głosu bez rzeczywistej mocy”. W tym samym eseju zawarta jest uwaga, która powinna wywołać dyskomfort u każdego coacha: „obwinianie facylitacji jest jak obwinianie skrzynki na sugestie za to, że kierownictwo nie zapoznaje się z zawartymi w niej propozycjami”. 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 „pozostawały w obrębie swojego kręgu wpływów” (przestały poruszać kwestie, których nie mogą 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ą farsę. 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 uczyniła to właśnie obecna edycja. W drugim wydaniu książki Agile Retrospectives (2024 r.), w którym do Esther Derby i Diany Larsen dołączył David Horowitz, 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 sytuacją. 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 znajdujące 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, nad którym zespół może rozpocząć pracę 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ż całkowity paraliż.
• Grzejniki retrospektywne: spraw, by eskalowane problemy stały się widoczne na zewnątrz, na tablicy widocznej dla kierownictwa, z możliwością śledzenia zmian w czasie. Radiator jest przeciwieństwem zaworu: zawór uwalnia ciśnienie i je ukrywa; radiator natomiast sygnalizuje nierozwiązany problem, dopóki nie zajmie się nim osoba uprawniona do jego rozwiązania. Proszę eskalować sprawy oznaczone na czerwono, podając konkretne nazwy.

Właśnie na to wskazują wyniki badań, a potwierdza to również kanon: selekcja według własnoś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 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ą, o ile zespół coś się nauczył. Jednostką zmiany staje się eksperyment: hipoteza, którą weryfikuje się w ustalonym terminie, a nie zadanie, które zalega w zaległościach. „Uważamy, że praca w parach podczas wdrażania obniży nasz wskaźnik wycofywania zmian; wypróbujemy to przez dwa sprinty i sprawdzimy” – to jest eksperyment. „Ulepszyć wdrożenia” 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 wysiłek związany z samą sesją wyładowywania 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 pozycji w eksperymenty z przypisanym odpowiedzialnym, terminem realizacji i wynikami, dzięki czemu ta godzina przestaje być przestrzenią, w której krąży jedynie frustracja.

To jest droga wyjścia z pustki i z ramy przewodniej. 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 oraz 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 te same problemy pojawiają się podczas każdego przeglądu retrospektywnego?

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ę zadań do jednego z wyznaczonym terminem przeglądu i rozpocznijcie kolejne spotkanie retrospektywne od jego sprawdzenia. Jeśli problem 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 kwestii pod kątem tego, kto faktycznie jest za nie odpowiedzialny, a następnie eskalować te oznaczone kolorem czerwonym 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ąć. Pozostawanie w obrębie własnego kręgu wpływów jest złą radą, jeśli 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. Jedno usprawnień, za które zespół naprawdę się angażuje i które zostanie omówione na samym początku następnego 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 określenia działań do podjęcia?

Nie, a uparte twierdzenie, ż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 doprowadziła do powstania listy zadań. Przeprowadzajcie eksperymenty, z których można wyciągnąć wnioski, a nie zadania, z powodu których będą Państwo odczuwać poczucie winy.

Warto przeczytać

• Władza: kiedy autorytet przejmuje kontrolę nad ceremonią. Dlaczego kwestie, o których warto wspomnieć, 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 na liście”, zanim zespół zrezygnuje z tego pomysłu.
• Jak stworzyć przestrzeń zapewniającą bezpieczeństwo psychologiczne. Szczerość, która ma gdzie się wyrazić.
• Retrospektywna Pierwsza Dyrektywa. Norma zapewniająca uczciwość w tym pomieszczeniu.
• Retrospektywa sprintu (ceremonia). Miejsce, jakie zajmuje retrospektywa w cyklu, oraz pętla, której zamknięcie ma ona zapewnić.
• Słownik terminów agile Theatre. Definicje czterech określonych rodzajów niepowodzeń.