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 się odbywa, ludzie są szczerzy, zapisuje się karteczki samoprzylepne, wszyscy kiwają głowami — a 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 nimi 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ą uważają ją doradcy 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ń — formułowanie ich zgodnie z zasadą SMART, wyznaczanie osoby odpowiedzialnej oraz umieszczanie ich 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 powstały trzy kolejne. „Powtarzam te same punkty z 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 jednego z często cytowanych badań 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 słowa i tylko słowa. Należy jednak podchodzić do tych powszechnych opinii z rezerwą: nasze własne dane dotyczące odsetka zadań wynikających z retrospektyw, które faktycznie zostają zrealizowane wskazują, że wskaźnik realizacji jest bliższy trzem na cztery — i pokazują, że o tej różnicy decyduje poczucie odpowiedzialności oraz regularność działań, a nie sam wysiłek.

Rozwiązaniem, które faktycznie się sprawdza, nie jest podejmowanie większej liczby działań — lecz mniejszej. Ograniczcie się do jednego. Pojedyncze usprawnienie, za które zespół naprawdę bierze na siebie odpowiedzialność 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. Jeśli ustalicie 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. Jedna pozycja, za którą ktoś jest odpowiedzialny i która ma wyznaczoną datę 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 sposób zamknięcia tego cyklu w ramach samej ceremonii, a retrospektywa polegająca na odhaczaniu punktów 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 są realizowane, ponieważ zespół nigdy nie byłby w stanie ich zrealizować — ponieważ rzeczywiste problemy faktycznie 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 zmienić sytuację, na którą narzeka zespół.

Najostrzejsze 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ć niepokój 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” — a 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 „pozostać w kręgu własnego wpływu” — przestać poruszać kwestie, których nie można zmienić. Przedstawiona jako problem dyscyplinarny zespołu, ta rada 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ę, co właśnie sprawia, że 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ć emocje na zewnątrz, a nie tłumić ich w sobie

Dobrą wiadomością jest to, że w tekście kanonicznym poprawka została już wprowadzona — i to właśnie w bieżącym wydaniu. 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 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 za nie odpowiada: co zespół kontroluje, na co może wpływać oraz co znajduje się w „zupie”, na co 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 w 15% — w przypadku poważnych, trudnych do rozwiązania problemów należy znaleźć ten fragment, nad którym zespół może zacząć pracować 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.
• Grzejniki retrospektywne — sprawiają, że eskalowane problemy stają się widoczne na zewnątrz, na tablicy dostępnej 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 eksponuje 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 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 konkretnych działań na naukę. Stanowisko przedstawione w drugim wydaniu — i z ulgą przyjmujemy to stwierdzenie z autorytatywnego źródła — głosi, że retrospektywa bez konkretnego działania nie jest porażką, o ile zespół coś się z niej nauczył. Jednostką zmiany staje się eksperyment — hipoteza, którą weryfikuje się w ustalonym terminie przeglądu — a nie zadanie, 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 właśnie eksperyment. „Ulepszenie wdrożeń” to karteczka samoprzylepna, która trafia do kosza.

Uwzględnia to również koszt, który nigdy nie trafia na listy 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 również 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 widocznym postępem, 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 podczas każdego przeglądu pojawiają się te same problemy?

Należy 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 retrospektywnego spotkania dodaje się trzy kolejne — należy ograniczyć liczbę zadań, za które ktoś jest odpowiedzialny, do jednego, wyznaczając termin przeglądu, a kolejne spotkanie retrospektywne rozpocząć 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: proszę dokonać selekcji pod kątem osoby odpowiedzialnej i eskalować sprawę, podając imię i nazwisko oraz datę, zamiast ponownie dawać upust emocjom.

Co Państwo robią, gdy prawdziwy problem leży 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ą, jeśli oznacza to ukrywanie prawdziwej przeszkody.

W jaki sposób możemy sprawić, 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 zostanie omówione na samym początku następnego spotkania retrospektywnego, przed podjęciem jakichkolwiek innych działań, 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 realizacji?

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ędziecie odczuwać poczucie winy.

Warto przeczytać

• 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ę wyładować.
• Retrospektywna Pierwsza Dyrektywa — zasada zapewniająca uczciwość w tym pomieszczeniu.
• Retrospektywa sprintu (ceremonia) — miejsce, jakie zajmuje retrospektywa w cyklu, oraz pętla, którą ma ona zamknąć.
• Słownik terminów agile Theatre — definicje czterech określonych rodzajów niepowodzeń.