Istota retrospektywy

Na jednej z ostatnich konferencji agile’owych natrafiłem na grupkę (jak się okazało – w większości Scrum Masterów) żywo dyskutującą o retrospektywach. Jako, że konwersacja była prowadzona publicznie, w trybie otwartym, przyłączyłem się w roli słuchacza. Rzecz była o pomysłach na ciekawe retrospektywy w formie, jak to określono, “psychozabawy” (a słysząc to słowo moje myśli skierowały się ku “Uśmiechowi Numeru” czy innym kultowym nastoletnim gazetkom z lat 90.). Oczywiście od razu padły gorące nazwy: Retromat, Retrospective Wiki czy TastyCupCakes. Uczestnicy przekrzykiwali się w profitach jakie uzyskują dzięki różnym zabawom: padały mądre akronimy, jak EMIC czy CCP, jedni mówili o kongitywistyce, eneagramach i rozgwiazdach, z kolei inni wymieniali nazwiska takie jak Belbin, Downey, Avery, Tuckman, Oldham, Michno czy Wilmiński. No dobra, te dwa ostatnie chyba brzmiało nieco inaczej. Opuściłem rozgrzane do czerwoności grono w czasie dyskusji nad różnym podziałem ludzkich osobowości, a konkretnie nad tym, który z licznych modeli tego typu najlepiej oddaje charaktery deweloperów w zespole Scrumowym pracującym nad wytwarzaniem oprogramowania.

Opuściłem, choć kusiło mnie strasznie włożenie kija w mrowisko i spytanie: a co te retrospektywy dają zespołom? Jak ulepsza to ich prace?

Zajrzyjmy do manifestu Agile:

W regularnych odstępach czasu zespół analizuje możliwości poprawy swojej wydajności, a następnie dostraja i dostosowuje swoje działania do wyciągniętych wniosków.

oraz do niezastąpionego Scrum Guide’a:

Retrospektywa Sprintu jest okazją dla Zespołu Scrumowego do przeprowadzenia inspekcji swoich działań i opracowania planu usprawnień, który zostanie wcielony w życie w najbliższym Sprincie.

I jeszcze:

Retrospektywa Sprintu ma na celu:

sprawdzenie, co działo się w ostatnim Sprincie, biorąc pod uwagę ludzi, relacje, procesy i narzędzia,
zidentyfikowanie i uporządkowanie istotnych elementów, które sprawdziły się w działaniu oraz tych, które kwalifikują się do usprawnienia,
stworzenie planu wprowadzania w życie usprawnień sposobu wykonywania pracy przez Zespół Scrumowy

Właśnie. Mam wrażenie, że coraz częściej się o tym wszystkim zapomina. Raz za razem słyszę, czytam i obserwuje retrospektywy w formie różnych zespołowych zabaw i prześciganie się Scrum Masterów w wymyślaniu coraz to wymyślniejszych i ciekawszych gier. Do tego najczęściej dzieje się to w oderwaniu od minionego sprintu, bo zespół musi odetchnąć, oderwać się od codzienności, od ciężkiej pracy. Bo przecież ile może się dziać w czasie sprintu, zwłaszcza tygodniowego? Bo retrospektywy są nudne, w kółko to samo, deweloperzy są znużeni. Bo ile można się pytać: co zostawiamy, co zmieniamy, a co poprawiamy (kto do diaska, powiedział, że retrospektywy mają mieć taką formę?). Bo w ten sposób scalamy zespół i doskonale poznajemy jego członków. Obserwacje zachowań ludzkich, a następnie odpowiednie szufladkowanie dają Scrum Masterowi z wiedzą psychologiczną prawdziwy materiał do popisu. No tak, na co dzień pracując z zespołem ciężko to zaobserwować?

Nie, nie jestem wrogiem takich zabaw i absolutnie nie mówię nie. Mnóstwo z tego typu aktywności niesie fantastyczne profity, cichaczem przemyca różnego rodzaju wartości i sprzyja integracji zespołu. I warto je stosować. Z umiarem i rozwagą. A tego właśnie, mam wrażenie, brakuje.

Obserwuję bowiem za duży nacisk na wymyślne zabawy realizowane w całkowitym oderwaniu od sprintu lub zabawy z tezą, mające dać Scrum Masterowi odpowiedzi na nurtujące go pytania odnośnie zespołu, pozwalające zaplanować dalsze kroki w budowaniu odpowiedniej “chemii”. Co gorsza, nieraz staje się to wręcz normą i każda retrospektywa przeprowadzana jest w takiej postaci. W efekcie deweloperzy przywykają do zabawowej formy i oczekują na koniec sprintu dobrej zabawy, a nie rozmawiania o tym, co można poprawić.

Osobiście preferuję retrospektywy oparte na konwersacji. Żadnych karteczek dla introwertyków, którzy “nie są w stanie się odezwać” (praca nad takimi osobami i ich aktywizacja to odrębne, spore zadanie, wykraczające daleko poza retrospektywy) , żadnych wykresów oscylujących pomiędzy buzią smutną, a zadowoloną, żadnego formalizmu w postaci gotowych pytań, żadnych sztuczek i podchodów. Szczera, otwarta rozmowa. Z wypowiedzią każdego z uczestników. I z bardzo dobrze przygotowanym do spotkania Scrum Masterem, który sporo czasu spędza z zespołem i obserwuje członków zespołu i ich codzienną pracę. Który zna ludzi, z którymi pracuje na co dzień. I który z takich obserwacji jest w stanie wyciągnąć masę wniosków i pomysłów. Ale który czeka z tym na sam koniec, dając najpierw okazję do poruszenia poszczególnych tematów przez deweloperów czy Product Ownera. I który – w końcu – jest przygotowany na różne scenariusze. Chociażby na takie, że nikt nie ma nic do powiedzenia na temat danego sprintu. W tym momencie dobry Scrum Master powinien na konkretnych przykładach pokazać, że jednak trochę się w tym sprint’cie wydarzyło. Że jest wiele miejsc do usprawnień albo zdarzeń do uwypuklenia. Zawsze. Nawet jeśli to 12-ty sprint, pracujemy w tym składzie od roku i znamy się na wylot, a do tego zrealizowaliśmy wszystko zgodnie z założeniami.

No i to, co najważniejsze dbam o to, aby przynajmniej te uznane za najistotniejsze, pomysły, usprawnienia wprowadzić w życie. Bo bez tego retrospektywa nie ma najmniejszego sensu.

Dlaczego czasem nie zrobić tego spotkania w innej formie? Zaskoczyć zespół, zorganizować warsztaty czy ciekawą grę. I zakończyć ją dyskusją. A i owszem, to właściwa droga, a wskazówek i inspiracji mamy mnóstwo (vide: strony wymienione na początku, jest też masa znakomitych książek). Grunt jednak zachować w tym wszystkim zdrowy rozsądek, nie przesadzać i pamiętać o celu, istocie spotkania!

#retrospektywa #Scrum