Dobra, dość już o wirusach i pandemiach. Od artykułu Na Miotle, w którym pisałem, jak strząsnąć syf z przeglądu sprintu, minęły już ponad dwa miesiące. Gwoli przypomnienia: tamten tekst był konsekwencją innego wpisu – Syf, który słyszysz podczas zdarzeń scrumowych. I mówisz. Lub milczysz w osłupieniu – w którym była mowa o patologiach zaklętych w wypowiedziach członków zespołów. Uznaliśmy, że łkać to każdy potrafi, ale prawdziwa sztuka to zawalczyć z ostrym cieniem mgły spróbować znaleźć rozwiązanie. Tym razem dzielę się sposobami, którymi usiłowałem i wciąż usiłuję podnieść jakość retrospektyw sprintów.
Dla przypomnienia, poniżej fragment Syfu, który słyszysz podczas zdarzeń scrumowych. I mówisz. Lub milczysz w osłupieniu:
#1
SM: Już pora na retro.
D: Spokojnie. Zrobisz nam, jak wrócimy z obiadu.
#2
PO: Wydygany już jestem. Trzecią godzinę tu siedzimy. Jakie akcje po dzisiejszej retrospektywie?
D: Musimy poprawić komunikację w zespole.
PO: Kto będzie to egzekwował?
D: Cały zespół musi.
PO: Dobra. Kto zamawia pizzę na planowanie?
Osoby dramatu: SM = scrum master, D = developer, PO = product owner.
Nie jesteś pępkiem.
Pępkiem świata – to pewne. Ale nie jesteś też pępkiem zespołu scrumowego, scrum masterze. Nie jesteś również Atlasem, który dźwiga na swoich barkach ciężar świata. Kiedy sobie to w końcu uświadomiłem, uznałem to spostrzeżenie za jedno z najprzyjemniejszych w moim życiu, zwłaszcza że nie zainwestowałem ani w masę, ani w rzeźbę, i na barkach nie uniósłbym nawet skrzynki piwa. Scrum Guide mówi o retrospektywie: Scrum Master zapewnia, by spotkanie to przebiegało w pozytywnej atmosferze i było produktywne. Uczy uczestników w jaki sposób można je utrzymać w ustalonych ramach czasowych. Scrum Master uczestniczy w Retrospektywie jako zwykły członek zespołu, reprezentując perspektywę odpowiedzialności za Scruma. Wydaje mi się, że wielu czytelników wyciąga z tego fragmentu zbyt daleko idące wnioski – utarł się mianowicie taki stereotyp, że to scrum master jest członkiem zespołu, który przygotowuje scenariusz retrospektywy, facylituje spotkanie, etc. Tylko że ma uczyć, nie wyręczać. Jak to mówią: jeśli traktujesz ludzi dookoła jak dzieci, w końcu zaczną zachowywać się jak dzieci.
JAK TO ZROBIĆ? Cóż, jeżeli wpadasz już w sidła opisane powyżej, podnieś temat na… najbliższej retrospektywie sprintu. Skuteczne bywa na przykład podzielenie się wśród członków zespołu obowiązkiem moderacji retrospektyw w kilku kolejnych sprintach. Szczególnie tym, którzy nigdy wcześniej nie mieli okazji się z tym zmierzyć, wyprzedzenie może się przydać.
Nie klękaj przed formą.
Jako młody scrum master – a właściwie niedoświadczony, młody to wciąż jestem – otarłem się o obsesję wokół formy retrospektyw. Tak, ubzdurałem sobie również, że to ja mam obowiązek je przeprowadzać. A następnie większość czasu w ramach przygotowań zaczęło pochłaniać mi wymyślanie cudacznych sposobów interakcji, wizualizacji, dróg do przeformułowania problemu, itd. Żebyśmy mieli jasność: niektóre z tych sposobów do dziś uważam za całkiem klawe, a nawet będę dzielił się nimi w moich wpisach. Kluczowymi słowami są tu jednak: umiar i wyczucie. Retrospektywa nie jest spektaklem jednego aktora. Nie służy łechtaniu ego scrum mastera. To zespołowi – całemu! – ma się zrobić lepiej. Po owocach ich poznacie, dlatego miarą jakości retrospektywy będą wypływające z niej wnioski, a nie sposób formułowania wniosków.
JAK TO ZROBIĆ? Weź się wyluzuj i odpuść trochę, co (nie mylić z olewactwem i ignorancją)? Przecież nie jesteś pępkiem świata.
Czasami jednak pomyśl o formie.
Wbrew temu, o czym powyżej, wcale nie należy, jak mi się zdaje, ostentacyjnie uprawiać na retrospektywach metodyki YOLO. Po pierwsze dlatego, że to wydarzenie ma wbrew pozorom ściśle sprecyzowany cel, a po drugie: od dwudziestego z rzędu podejścia do swobodnej, kompletnie nieustrukturyzowanej wymiany wrażeń i wolnych wniosków może się człowiekowi niedobrze zrobić. Wspominałem już o umiarze i wyczuciu?
JAK TO ZROBIĆ? Może by tak pokusić się o wysłuchanie głosu zespołu? Jego potrzeb co do formy retrospektyw? Może by tak ostatnie trzy minuty retrospektywy przeznaczyć na informację zwrotną na temat kończącego się właśnie wydarzenia?
Nie nazywasz się Kaszpirowski, bro!
Adin, dwa, tri. Jeśli wydaje ci się, że retrospektywa sprintu ma być sesją terapeutyczną dla zespołu, to rzeczywiście ci się wydaje. Owszem, to spotkanie dotyczy również ludzi i relacji, ale to nie znaczy, że musisz odstawiać sesje gestaltyzmu. Więcej nawet, to nie znaczy, że musisz i powinieneś podczas retrospektyw rezerwować czas wyłącznie dla miękkich aspektów pracy. Jasne, i dla nich powinno znaleźć się miejsce, jeśli tylko zachodzi taka potrzeba, ale naprawdę nie powinieneś czuć się źle, jeśli odpuścisz sobie gadkę o informacji zwrotnej na rzecz weryfikacji zapisów Definicji Ukończenia. Co więcej, może się okazać, że bardziej rygorystyczna Definicja Ukończenia podniesie wydatnie jakość produktu twojego zespołu, a w efekcie testerzy przestaną pałać nienawiścią do programistów, i sztuka przekazywania negatywnej informacji zwrotnej nie będzie już w zespole tak potrzebna, jak się tobie wydawało. Widzisz? Dwie pieczenie na jednym ogniu.
JAK TO ZROBIĆ? Jeżeli masz wrażenie, że retrospektywy twoich zespołów robią się cokolwiek jednowymiarowe, postaw piwo scrum masterowi, z którym się kumplujesz, podziel się spostrzeżeniami i spróbuj dowiedzieć się, czy można inaczej. Może nawet, za zgodą zespołu, uda się zobaczyć w trakcie retrospektywy innej ekipy, że da się inaczej?
ROI to nie jest rojenie.
Zadbaj, by retrospektywa nie była godziną biadolenia, tylko poszukiwania rozwiązań. Oczywiście prędzej czy później napotkacie z zespołem problemy, które znajdują się poza waszą strefą wpływu, ale nawet o takich warto szepnąć osobom, które na nie wpływ mieć mogą. Formułujcie zadania, które z retrospektyw wypływają, w perspektywie korzyści, które powinny wam przynieść, a najpóźniej na kolejnej retrospektywie weryfikujcie, na ile ich realizacja się powiodła, i w jakim stopniu prognozowane korzyści się pojawiły.
JAK TO ZROBIĆ? Zespołom, z którymi pracowałem, zdarzało mi się proponować formułowanie akcji wynikających z retrospektyw w formie historyjek użytkownika. Na przykład: Jako developer chciałbym mieć dostęp do stabilnego środowiska testowego, by nie siwieć z frustracji i w sprincie spełniać jakościowe kryteria zapisane w DoD. Pod taką historyjką da się wygenerować konkretne kroki, które prowadzą do oczekiwanego celu, a całą historyjkę uwzględnić w planie kolejnego sprintu. A nawet przedstawić owoce na przeglądzie sprintu.
Przestań się mazać.
Nie zapominaj, że na retrospektywach warto rozmawiać nie tylko o tym, co nie wyszło, ale i o tym, co doskonale się sprawdziło. Argumentem, który niektórzy członkowie zespołów podnoszą przeciwko retrospektywie, jest sformułowanie: przecież było w porządku. Jeśli rzeczywiście było, to tym bardziej nie ma co sobie odpuszczać. Trudno przecież o lepszą okazję, by wyłuskać z procesu dobre praktyki, a następnie uczynić je standardem, jak radzi myślenie w duchu Kaizen.
JAK TO ZROBIĆ? A może by tak uzmysłowić członkom zespołów, które funkcjonują bez dramatów, że są szczęściarzami i powinni odbyć retrospektywę choćby po to, by podzielić się z innymi, mniej fartownymi, ekipami swoimi odkryciami?
Retrospektywa, retrospektywa… Niepokoi mnie trochę to zaklęte w samej nazwie „retro”. Przecież to wydarzenie to żaden przeżytek, nie? Jak ty, czytelniku najdroższy, radzisz sobie, by inspekcja i adaptacja procesu, narzędzi i relacji międzyludzkich nie stała się w twoim zespole vintage?
Zdjęcia: Free-Photos z Pixabay