#006 – Pułapki Retrospektywy Sprintu

Rozmawiamy o pułapkach Retrospektywy Sprintu – wskazujemy  te najczęściej występujące, omawiamy w jaki sposób je identyfikować oraz podpowiadamy, jak można sobie z nimi radzić. 



Zobacz wersję wideo

Materiały i techniki, o których m.in. wspominamy w nagraniu:

Jeśli odcinek Ci się podobał, koniecznie podziel się nim z innymi osobami, które Twoim zdaniem mogą go potrzebować. Jeśli są jakieś problemy, jakie napotykasz w trakcie retro, masz jakąś fajną obserwację albo dobrą praktykę, którą sugerujesz innym Scrum Masterom i Agile Coachom, daj koniecznie znać w komentarzu.

Daj nam znać co sądzisz o samym odcinku:

Chcemy usprawniać podcast z każdym kolejnym odcinkiem, więc podpowiedz nam, jakie niedoskonałości Twoim zdaniem powinniśmy poprawić.

Mamy sporo pomysłów na to, co jeszcze moglibyśmy nagrać, ale jesteśmy bardzo otwarci na Twoją sugestię – przekaż nam hasło albo temat, o którym moglibyśmy opowiadać w kolejnych odcinkach.

Transkrypcja odcinka

Kuba: W piątym odcinku podcastu poruszyliśmy temat porządnej Retrospektywy Sprintu. Już przy nagrywaniu mieliśmy z Jackiem poczucie, że na pewno nie uda nam się wyczerpać wszystkich wątków Retrospektywy, więc skupiliśmy się na temacie struktury i typowych problemów z tą strukturą. W tym odcinku chcielibyśmy uzupełnić wątki, które świadomie pominęliśmy w poprzednim odcinku lub raptem tylko delikatnie zasygnalizowaliśmy. Chcemy poruszyć wątki możliwych pułapek Retrospektyw, które spotykamy w praktyce. Możliwych przyczyn, z których te pułapki wynikają, ale też chcemy podpowiedzieć kilka praktyk, kilka gotowych rozwiązań, które mogą być inspiracją jak zrobić jeszcze lepszą Retrospektywę Sprintu. Przygotowując ten odcinek, zakładamy, że słuchałeś lub słuchałaś odcinek 5. Porządna Retrospektywa Sprintu. Nie będziemy w tym odcinku jeszcze raz definiować Retrospektywy, ani definiować jej poprawnej struktury.

Jacek: Pierwsza pułapka, z którą się spotykamy, nazwaliśmy ją sobie bardzo roboczo „Retro żale”. Jest to pułapka, którą można zidentyfikować po tym, że w trakcie Retrospektywy zespół skupia się wyłącznie na tematach, które bądź nie wyszły, bądź działają w niesatysfakcjonujący sposób. Natomiast pomijana jest część, w której zespół wskazuje rzeczy, które się udały. Rzeczy, które były fajne i rzeczy, które po prostu warto wspomnieć, chociażby z tego względu, żeby mieć ten drobny punkt w czasie w Sprincie, kiedy też dajemy sobie wzajemnie informację zwrotną na zasadzie, to nam wyszło, to się nam podobało. Ten pomysł, który zrealizowaliśmy, udał się i chcielibyśmy go kontynuować.

Kuba: I takie „Retro żale” są szczególnie niebezpieczne też z tego powodu, że może się w całym zespole wykształcić takie poczucie, że Retrospektywa jest jednoznaczna z takim mówieniem sobie złych rzeczy, wypominaniem sobie różnych rzeczy, przypominaniem sobie jakichś niedociągnięć. Przez całe dwa tygodnie Sprintu było wszystko super, ale pamiętasz w środę w zeszłym tygodniu, to się tam niefajnie do mnie odezwałeś, to teraz musimy o tym koniecznie rozmawiać. Czyli takie bardzo negatywne skojarzenie, że spotkanie jest wyłącznie jakąś spowiedzią. Spotkanie jest tylko i wyłącznie wytykaniem sobie różnych rzeczy. To oczywiście jest pewnie pochodna pewnego sposobu przeprowadzenia tego, ale no można sobie nieświadomie sobie to zrobić, albo można się nieświadomie jako Scrum Master przyczynić prowadząc spotkanie w pewien sposób, do tego, że to spotkanie się w „Retro żale” zamienia. Może pogłębimy, z czego to skojarzenie z „Retro żalami” może wynikać?

Jacek: Co masz na myśli?

Kuba: Przychodzi mi do głowy tutaj, chociażby doboru konkretnych technik. Jeśli mocno wartościujemy pewne obserwacje i w dodatku później wybieramy tylko te, które można nazwać negatywami, minusami, rzeczami do poprawy. Czyli, jeśli w ramach techniki usprawniania skupiamy się na tym, że są pewne rzeczy, które były dobre i są rzeczy, które były złe, a potem do dyskusji wybieramy rzeczy złe, to siłą rzeczy jesteśmy już po tej ciemnej stronie rozmowy. W ogóle z automatu odcinamy możliwość rozmawiania o rzeczach dobrych. Przede wszystkim wprowadzamy wartościowanie na rzeczy dobre i złe. Taki trochę bajkowy świat, w którym jest dobry bohater i zły bohater. I ten zły bohater to pewnie na końcu musi dostać karę i w ogóle się zmienić.

Jacek: No to mi z kolei przychodzi do głowy, jakby tutaj duży wpływ tutaj moderatora. Czyli osoba, która prowadzi Retrospektywę, może mieć pokusę taką, żeby powiedzieć – No to te rzeczy, które tutaj wymieniliśmy, to one wyszły, nie musimy o nich rozmawiać, no bo one są fajne i skupmy się na tym, co jest do usprawnienia. Miałem taki bardzo fajny przykład bardzo niedawno. Całkiem młody zespół, który zaczyna swoją przygodę ze Scrumem. W trakcie jednej z Retrospektyw zgodził się, że wprowadzą sobie codziennego Scruma. Po dwóch tygodniach faktycznie codziennego spotykania się w ramach codziennego Scruma na tablicy w części, co nam wyszło, właściwie każdy członek zespołu przykleił kartkę Daily Scrum. Bardzo łatwo można było powiedzieć – OK, działa i jakby już nie komentujmy. Natomiast okazało się, że gdy zapytać zespół – Dlaczego i z czego to wnika? W bardzo fajny sposób, z różnej perspektywy członkowie zespołu powiedzieli, dlaczego te spotkania miały dla nich wartość. Czego ich zdaniem pozwoliły uniknąć? Na co miało wpływ. No a warto dodać, że był to udany Sprint ze zrealizowanym celem Sprintu. Tak więc takie głośne nazwanie, powiedzenie, zastanowienie się, dlaczego to było dobre, no uważam, że też jest czynnikiem uczącym się. Czynnikiem, który wpływa, że zespół się uczy i też jakby to nie tylko o to chodzi, że wprowadziliśmy codziennego Scruma, ale zastanówmy się, zejdźmy trochę głębiej, jakby co to konkretnie nam dało?

Kuba: Takie zanurkowanie w te takie udane rzeczy, może być świetną okazją do tego, żeby zwerbalizować sobie, żeby zespół głośno sobie nazwał te przyczyny, dla których coś się udało i to może pomóc zespołowi się uczyć, czy wyciągać wnioski na temat tego, co się zaczyna sprawdzać. Tu też mi przychodzą do głowy takie Retrospektywy, w których w tej czy innej roli miałem okazję wziąć udział i na przykład skorygowałem jakiegoś Scrum Mastera jako jego mentor, czy Agile Coach, gdzie właśnie tam nie wiem zespół, taki przykład mi przychodzi do głowy, mówi, że bardzo fajnie uporządkowaliśmy temat wrzutek i spływających znienacka błędów i awarii po stronie plusów. Jakby Scrum Master Chciał z pośpiechu stwierdzić – OK. Super. Ekstra to lecimy dalej. A to był świetny temat do pogadania, jak to zrobili, że się zadaniami podzielili, że sobie wzajemnie pomagali, że uporządkowali trochę temat zarządzania wiedzą między poszczególnymi programistami, którzy mieli jakieś tam unikalne kawałki wiedzy. Dopiero jak zaczęli sobie pomagać, to zaczęło wychodzić. Czyli po pierwsze był temat, żeby sobie wzajemnie podziękować i powiedzieć, że to zadziałało. Po drugie być może powiedzieć głośno i róbmy tak w kolejnych przypadkach w przyszłości. Róbmy tak częściej. Możliwe, że tak jak są różne teorie, możliwe, że właśnie popracowanie również na tej stronie pozytywów – na tych mocnych stronach, da całkiem fajne rezultaty w zespole. Może niestety już nie poprawimy jakiegoś aspektu, który jest tam dla nas tam bolesny, ale za to jakby przerzućmy tę uwagę na to, że mamy też całkiem niezłą kwestię współpracy. Jak możemy ją sobie pogłębić, to się okaże, że ona jest fajna, działa i może działać jeszcze lepiej. Ale jeśli zaszufladkujemy zespół, że możemy rozmawiać tylko o rzeczach złych, to póki dobra współpraca nie będzie fatalna, to o niej nie pogadamy. Czyli trochę tak generujemy taką sytuację, że póki nie ma kryzysu, to nie ma opcji, że o tym pogadamy. A może pogadajmy o rzeczach, które są całkiem niezłe i może w toku rozmowy o nich wyjdzie nam o nich, że są w stanie być jeszcze lepsi.

Jacek: Jak mówisz o tym, że mogą być jeszcze lepsze, jeżeli przychodzi mi wejść w rolę osoby, która moderuje Retrospektywę, to zwykle mówię coś takiego, że możemy się zastanowić nad rzeczami, które nie działają tak, jakbyśmy chcieli i możemy je usprawnić, ale jednocześnie mówię, że możemy też pogłębić rzeczy, w których czujemy, że mamy sukcesy, czy rzeczy, z których jesteśmy zadowoleni, po to właśnie, żebyśmy mogli je robić jeszcze lepiej. Natomiast jeszcze jeden aspekt jest taki, że jeżeli pominiemy ten aspekt komentowania rzeczy, które nam wyszły, no myślę, że tracimy szansę na to, żeby wzmocnić wartość z tego, że warto eksperymentować. Nieudane rzeczy to będziemy wałkować cały czas, ale dlaczego nie spojrzeć na to co wyszło i dlaczego nie porozmawiać o tym dlaczego wyszło. Tak naprawdę uważam, że jest to fajne paliwo, że warto próbować, bo nawet jeśli trzy razy pod rząd eksperymenty się nam nie powiodą, albo inaczej, nie przyniosą spodziewanych rezultatów, no to jak za czwartym razem nam wyjdzie, no to miejmy tę chwilę na celebrację. Miejmy ten moment na to, żeby porozmawiać o tym, jak wyszło, dlaczego wyszło. Wierzę, że i widzę, że jest to fajne paliwo, które dodaje odwagi do tego, żeby próbować różnych podejść w kolejnych Sprintach.

Kuba: Dodaje odwagi, ośmiela. Jest też tak, że w różnych zespołach to jest różnie i u różnych osób to jest różnie. Ale jest czasem tak, że trochę prościej nam powiedzieć – Podobało mi się to, co robiłeś i chcę tego więcej, niż – Słuchaj stary, bardzo nie lubię, jak to robisz. O wiele trudniej jest nam, niektórym, może mówię w imieniu introwertyków, o wiele trudniej powiedzieć wprost, że coś tam nam nie pasuje. O wiele prościej opowiedzieć, że sytuacja była fajna i chcę tego więcej. To może być tak, że jeśli publicznie to sobie w zespole powiemy, to może być mi prościej powiedzieć koledze, z którym współpracuję i wszystkim, że chcę współpracy takiej jak z tym kolegą, niż koledze, z którym mi się najgorzej współpracuje, że coś tam mi nie pasuje. Zwłaszcza jeśli nie jestem wystarczająco jakby świadomy tego, co tam się dzieje. Żeby umieć to nazwać, że przeszkadza mi, że mi tam przerywa, czy przeszkadza mi, że krytykuje moją pracę na przykład.

Jacek: Myślę, że taką kolejną pułapką, z którą można się zmierzyć, chcąc nie chcąc, jest podchodzenie do Retrospektywy jako do spotkania, podczas którego omawiamy tylko tematy miękkie. Czyli tematy związane z komunikacją, z tym jak się nam pracuje, jak wygląda współpraca, pomijając w tej dyskusji, aspekty techniczne, aspekty procesowe. Aspekty, które są bardziej związane jakby z tym, co robimy, aniżeli po prostu funkcjonujemy jako zespół, jako ludzie. Zwykle po ludzku chcemy dążyć do tego, żeby jak najlepiej się dogadywać.

Kuba: To może mieć swoje proste korzenie, albo przynajmniej z takimi tezami kilkukrotnie miałem okazję się zetknąć. Po pierwsze te Retrospektywy tak się mocno kojarzą z takim stylem coachingowym. Czyli siłą rzeczy bardziej psychologia niż inżynieria oprogramowania. Bardziej jakieś fajnie pytania, mocne pytania. To jakby nas siłą rzeczy ściąga w stronę naszych motywacji, naszych tematów międzyludzkich, naszych uczuć. I to jest wszystko super. O tym można poczytać dużo w książkach, o tym można przeczytać dużo na blogach. O tym często na konferencjach są nawet całe tracki, a nie tylko pojedyncze wystąpienia, że Ok, ale nie zapomnijmy, że jesteśmy ludźmi, że zespół i w ogóle. I to jest wszystko super i to też jest prawda dla ścisłości, bo sami przed chwilą, zanim ten wątek wprowadziliśmy, też już kilku takich przykładów używaliśmy, że te rzeczy miękkie mogą i często powinny być tematem na Retrospektywie, ale coś, co tu chcemy zasygnalizować i przed czym przestrzec, żeby się w tym nie zatracić. Żeby się nagle nie okazało, że Retrospektywa jest tylko o tym, że w zasadzie o rzeczach twardych, że o rzeczach konkretnych, inżynierskich to nie wiadomo kiedy rozmawiać, ale na pewno nie na Retrospektywie, bo tutaj to jest ten moment, że sobie dziękujemy, chwalimy się. Dajemy sobie wzajemnie strukturyzowany feedback i wszystko super, tylko na końcu nie ma kiedy pogadać o jakości kodu, albo o naszej narzędziówce.

Jacek: Tu przychodzi mi do głowy taka obietnica płynąca trochę ze Scruma, że dobrze realizowane spotkania scrumowe minimalizują konieczność organizowania dodatkowych spotkań. I tak to faktycznie myślę, może wyglądać. Jeśli znajdziemy czas, chociażby na Retrospektywie, żeby porozmawiać o standardzie kodowania, o tym jak działa nam ciągła integracja, o tym jak stoimy ze środowiskami testowymi i tak dalej. No to faktycznie, a jest to miejsce ku temu, ewidentnie poddajemy inspekcji temu jak pracujemy i dokonujemy adaptacji, czyli szukamy usprawnień. Wtedy faktycznie może się okazać, że będziemy potrzebowali dodatkowych spotkań. Natomiast szukając przyczyny też jakby, co może być powodem tego, że Retrospektywa jest traktowana w taki miękki sposób, to myślę, że jakby na kształt Retrospektywy może mieć wpływ osoba, która jest moderatorem. Nie chcę generalizować, natomiast w dużym uproszczeniu i tym trochę rozmawialiśmy w pierwszym odcinku podcastu. Często w rolę Scrum Mastera wchodzą osoby o backgroundzie technicznym, bądź o backgroundzie nazwijmy to miękkim czy biznesowym. No i faktycznie obserwuję coś takiego, że osoby, które nie mają doświadczenia technicznego i powiedzmy, większość życia spędziły, obracając się w takich obszarach miękkich, często świadomie bądź mniej świadomie dobierają takie techniki, które powiedzmy, adresują takie tematy, które wspomniałeś przed chwilą – uczucia, jakieś takie przemyślenia. Jak się czujemy jako ludzie w stosunku do siebie. I wydaje mi się, że trochę tam jest pomijany ten wątek inżynierski. Natomiast spotykałem się też z Retrospektywami, które prowadzili Scrum Masterzy techniczni, którzy wcześniej byli najczęściej bądź developerami, bądź testerami. I o ni sami troszeczkę też prowadzili zespół w tę stronę, albo chociażby pokazywali, że jest taki obszar pod tytułem, nie wiem jakieś miary, jakieś metryki, że w ogóle jest jakiś proces, że możemy porozmawiać o tym, jakie mamy flow. O to, że ktoś robi pracę, ktoś inny na to czeka. Więc wydaje mi się, że tutaj taka świadomość po stronie osoby prowadzącej może mieć też wpływ na to, że powiedzmy dotychczas zaniedbywany obszar tematów twardszych, przemyślaną strukturą Retrospektywy zaanimować.

Kuba: I to ta świadomość lub nieświadomość czasem może być większą pułapką, niż by się wszystkim wydawało. Bo tak jak Jacek wspominałeś, wspominaliśmy o tym przy definiowaniu Scrum Mastera i wtedy wspominałem, że jestem przykładem Scrum Mastera, czy byłego Scrum Mastera, czy byłego Scrum Mastera, który nigdy nie był techniczny. W sensie nie mam backgroundu technicznego. No i mogę powiedzieć za siebie, a widzę to u innych nietechnicznych Scrum Masterów, że to jest swojego rodzaju poczucie bezpieczeństwa, czy pewności siebie, że gdy rozmawiamy o pracy jako zespół, to to jest mój obszar kompetencji. Gdy rozmawiamy o tym, jak zespół pracuje jako faktycznie profesjonaliści w swoich obszarach specjalizacji, to ja się w najlepszym razie mogę z grubsza orientować. No tylko warto sobie przypomnieć, że jednak to nie jest tak, że ja muszę znać na wylot, o czym cały zespół mówi. Ważne, żebym czasem z powodu braku poczucia pewności, czy może jakichś lekkich kompleksów – bo czasami to może być to, żebym czasem całej grupy nie zmoderowywał z tej strony, żebym ich nie spychał z tych tematów, żebym nie dobierał tematów, że nagle się okazuje, że nie ma miejsca, żeby o tym pogadać. Tak naprawdę no fajnie, żeby było i trochę tych tematów i trochę tych tematów. Spróbujmy jako Scrum Master być tutaj, jak najmniej tutaj z własną tezą, jeśli chodzi o to, o czym zespół powinien rozmawiać. Tak naprawdę niech zespół nurkuje we wszystkie potrzebne tematy i też miejmy umiejętność pobudzania zespołu do rozmawiania o tych tematach, które są problemem, a nie tylko tych, które są problemy i my się jednocześnie dobrze czujemy, żeby o nich rozmawiać. Bo może się okazać, że wyczerpiemy tematy miękkie dosyć szybko, a rzeczy twarde stojące odłogiem zawsze będą taką kulą u nogi, która będzie frustrowała, generowała jakieś kłopoty. To jest taki świat, w którym rzeczy muszą być wybalansowane. I nawet teraz jakby wprowadziliśmy ten temat, to mówimy twarde, miękkie, a to są rzeczy międzyludzkie – komunikacja, dyskusja o code review będzie zawsze stykiem między twardym a miękkim tematem. Więc tutaj ta granica wcale nie jest wyraziście zarysowana i ona wcale nie będzie tylko rzeczy inżynierskie – rzeczy międzyludzkie. Bo to będą i rzeczy procesowe i biznesowe i współpracy między zespołami i może jakieś relacje między osobami w zespole, a kimś w hierarchii. Więc tych tematów będzie cała masa i to jest ogólnie temat – nie preferujmy tylko jednego z wątków.

Jacek: Przychodzi mi do głowy prosta technika, którą bardzo często stosowałem będąc w roli Scrum Mastera i pracując z zespołami, po prostu na początku Retrospektywy nazywałem przykładowe obszary, które warto poruszyć. Czyli mówiłem – Słuchajcie, to jest dobry moment, żeby porozmawiać o komunikacji. To jest dobry moment, żeby porozmawiać o procesie. To jest dobry moment, żeby porozmawiać o tym, jak pracujemy. Zarówno na poziomie ludzkim, jak i na poziomie takim czysto technologicznym. Bardzo często widziałem, jak ta myśl zapalała lampki w oczach niektórych osób. I na skutek takiej dyskusji zwykle ku mojemu nie zaskoczeniu, bo to jakby trochę było tak podsterowane w pozytywnym tego słowa znaczeniu, pojawiały się tematy, które zwykle się nie pojawiały, czyli na przykład jakieś takie aspekty inżynierskie, które jak się okazywało później w rozmowie, w rozwinięciu, no czuć było, że były one dawno nieporuszane. Czuć było taki duży entuzjazm grupy, że jakby w końcu mogą o tym porozmawiać. Przy czym wcześniej nikt im tego nie zabraniał. Myślę, że to jakieś wcześniejsze przyzwyczajenia, wcześniejsze retrospektywy, albo jakieś wyobrażenie w ogóle, czym jest Scrum, czym jest Retrospektywa. Tych tematów po prostu nie uwalniało.

Kuba: Ja na przykład uważam, że trochę nadziewamy się na ewentualne kontry i dyskusje, bo uważam, że w tym takim gronie scrumowym, czy w społeczności zwinnej jest sporo takich proponentów, czy takich ambasadorów tematyki miękkiej, że faktycznie jak załatwimy tematy miękkie, to wszystko jest tip-top. Broń Boże nie mówię, żeby nie rozmawiać o rzeczach miękkich, ale za dużo razy już, jako osoba pracująca z zespołami musiałem tłumaczyć powolutku, na spokojnie i bez emocjonowania się, całym zespołom, że nie – Retrospektywa to nie jest tylko wyłącznie temat miękki. Tak, to jest dokładnie to miejsce, w którym możecie porozmawiać o tym, o czym tak bardzo chcecie rozmawiać, tylko nie ma miejsca. Dlaczego jeszcze raz to wyciągam, chociaż to już raz padło? To jest jeszcze jedno miejsce, gdzie cała koncepcja Scruma może być wrogo potraktowana przez cały zespół, jeśli zespół zaczyna czuć, że narzędzie nie jest dla nich, które im nie pomaga, które generuje im tematy zastępcze. Bardzo prosto o takie zniechęcenie. A to zniechęcenie może mieć swoje źródło w tym, że tak jak Retrospektywa jest pomyślana jako taka regularna okazja do wyczyszczenia pewnych sytuacji, przegadania, ciągłego poprawienia się we wszystkich ważnych dla zespołu obszarach, czy członków zespołu obszarach. Tak jeśli to Retro bardzo katalizujemy, czy tylko ogniskujemy na wycinek rzeczywistości, to może się okazać, że Retrospektywa staje się bez sensu. Scrum zaczyna nam nie działać, bo na przykład nie mamy wystarczająco dobrej jakości, albo dobrej współpracy, albo jeszcze czegoś. I nagle nam się sypie cała konstrukcja, bo Sprintów nie dowozimy, ale nie ma kiedy o tym pogadać, bo w sumie komunikujemy się dobrze, tylko coś tam nie działa. Więc tu jest jakby bardzo misterna układanka. Od dobrego Retro dużo zależy i ważne, żeby ono było dokładnie, o czym trzeba rozmawiać, a nie o tych tematach, które są albo modne, albo bezpieczne, albo fajne.

Jacek: No i tutaj myślę, płynnie możemy przejść do kolejnej pułapki, dosyć podobnej, tylko odwrotnej. Retrospektywa jako spotkanie, podczas którego dyskutujemy tylko na tematy twarde. Czyli właściwie przeciwieństwo tego, co powiedzieliśmy. Absolutne skupienie na technikaliach, na szczegółach inżynieryjnych, miary procesu.

Kuba: Sposoby dzielenia zadań między sobą. Sposoby dzielenia zadań na mniejsze, ale takie same. Mocne, ziemne, takie inżynierskie rzeczy.

Jacek: Reguły brunchowania, gift flow, code review. Jak robimy? Z jakiego środowiska? Jakie narzędzia? Doke?

Kuba: Pokażę Ci, jak mój czysty kod wygląda czyściej od Twojego czystego kodu.

Jacek: Co do zasady, tak trochę z kontekstu płynie, to są super istotne aspekty. Natomiast jeżeli w tym samym czasie w zespole absolutnie leży komunikacja, ludzie się nie dogadują. Codzienny Scrum nie przynosi wartości, bo zamiast planowania nadchodzących 24. godzin, robimy sobie wesoły status meeting i tak dalej. No to też nie jest jakby droga. W sensie przeginka tutaj jest w drugą stronę. Z mojej perspektywy, przegięcie w taką stronę techniczną z pominięciem tematów nazwijmy to miękkich, szeroko, też jest, uważam ślepą uliczką.

Kuba: Bardzo popularny problem. W poprzednim odcinku wspomniany, czyli brak udziału Product Ownera w Retrospektywie. Może mieć swoje korzenie w tym, że tematyka Retrospektywy jest nieciekawa dla Product Ownera, bo na przykład zespół za nisko i za szczegółowo wchodzi w tematy inżynierskie, nie zostawiając w ogóle miejsca na takie tematy wspólne z Product Ownerem, albo chociaż, że tak powiem, uszanowując się wzajemnie. Coś w stylu – Drogi Product Ownerze, to są rzeczy dla nas ważne, rozmawiajmy o tym wspólnie, tłumaczymy Ci, ale jak masz coś dla nas, to też nam to powiedz. Czyli czasami takie trochę bym powiedział wręcz ryzykownie, takie getto inżynierskich tematów. Samo się wykształciło i wzmocniło, bo o miękkich rzeczach nie gadamy, o rzeczach biznesowych nie gadamy. Owner nie przychodzi, bo i po co? Jeszcze nie daj Boże, jeśli mamy w zespole członków zespołu, którzy tam przesiadują z boku i nie zainteresowani, bo tam nie wiem, rozmawiamy o jakości kodu, a tester jest manualny i w sumie go to nie obchodzi. No to nagle się okazuje, że Retrospektywa dotyczy dwóch, trzech członków zespołu, a cała reszta zespołu co najwyżej grzecznie im asystuje. No i tutaj o tym już trochę powiedzieliśmy przy poprzednim przypadku. Ogólnie mówiąc, chodzi o to, żeby wyłapać balans, poruszać rzeczy takie i takie, nie stosować technik, którą z rzeczy preferują i też bardzo otwarcie sobie mówić o jakichś rzeczach. Jeśli je mówimy, o którejś z tych bardziej z tych skrajnych rzeczy, dlaczego o tym mówimy i inne tematy też są możliwe. Idąc dalej jeśli chodzi o pułapki, nawiązując też do tej poprzedniej wspomnianej, to nazwałbym taką pułapkę – braku elastyczności formuły Retrospektywy. Bardzo skrótowo można by powiedzieć, że to jest taka Retrospektywa na jedno kopyto. Najbardziej skrajny przypadek jest taki, że każde jedno Retro jest identyczne. Plusy, minusy, karteczki, rozwiązania, ciach plan akcji. No niektórzy Scrum Masterzy są bardziej wyrafinowani i nie zawsze są plusy i minusy. Czasem jest Start – Stop – Continue, a czasem bardzo zaawansowani wcisną 4L, bo się u Jacka na blogu wyczytali, że można użyć też takiej techniki. O elastyczność formuły, chodzi mi o to, że cała jakby struktura Retrospektywy ma zawsze powtarzalny charakter. Coś tam zbieramy, coś tam selekcjonujemy, potem rozmawiamy o tym i wio. To jest ogólnie dobry patent i wspominaliśmy go jako przykładowy wzorzec, czy strukturę dobrej Retrospektywy, dobrego Retro, ale są takie sytuacje w życiu zespołu, że wydarza się jakiś kłopot, jakiś kryzys, może pojawia się jakiś impediment. Czy po prostu pojawia się potrzeba zespołu pogadania o czymś w jakiś inny sposób? Uważam, że taką dobrą rolą Scrum Mastera jest również wybranie takiej metody, która na takie rzeczy inne umożliwia. Taka trochę trójpolówka, że czasem na tej samej ziemi uprawiam łąkę, czasem sadzę buraki, a czasem ta ziemia leży odłogiem. Tak samo na Retrospektywie też można zrobić taką trójpolówkę. Czasem faktycznie lecę sobie w plusy i minusy. Czasem zrobię time line Sprintu, bo faktycznie działo się coś, co bardziej pasuje, żeby pokazać pewną chronologię. A czasem zrobię po prostu wyjście na piwo i sobie pogadamy. Może wtedy nie będzie takiej pięknej struktury jak właśnie w plusach – minusach, albo wyczytanej w książce, ale zespół będzie miał odświeżenie. Z powodu tego, że będzie to coś zupełnie innego, jest okazja, że może wyjdą nam nowe rzeczy, które do tej pory nie wychodziły, a w szczególności unikniemy takiej rutyny, która może być taka ogłupiająca. No dobra, znowu Retro, znowu będą karteczki, no to muszę coś tam przypomnieć, co chciałem zapisać na kartkę. A, napiszę komunikację. I jechane, nie, ciągle na to samo kopyto.

Jacek: Tak jak powiedziałeś o tym time line, czyli jakby spojrzeniu na to co się działo w perspektywie czasu, to myślę, że warto tutaj powiedzieć, że ta metoda konkretna może się fajnie sprawdzić, gdzie na przykład domykamy jakiś epizod pracy nad produktem, albo podsumowujemy jakiś konkretny okres. I to jest właśnie fajny przykład, no tak jak mówisz, zareagować nieco inaczej, skoro będziemy podsumowywać, no to może faktycznie spójrzmy z perspektywy czasu i sam myślę, kilkukrotnie stosowałem tę technikę i faktycznie pomaga ona uzyskać pewną chronologię. Pozwala też wyłapać pewne trendy, pewne miejsca, w których jakby często decyzje systemowe determinowały to, co się działo. I myślę, że to jest bardzo fajne jedno podejście.  Natomiast inny przykład, który przychodzi mi do głowy, który ostatnio obserwowałem, będąc w roli Agile Coacha, więc mogłem obserwować i pracę zespołu i Scrum Mastera. Zespół stał, nazwijmy to na rozdrożu. Planowane było wdrożenie produktu na produkcję i Scrum Master zaproponował taką technikę, w której każdy może zapisać dowolne pytanie. Te pytania przyklejał na ścianę i potem po kolei każde pytanie było zdejmowane, czytane. Osoba jedna po drugiej odpowiadała na to pytanie niezależnie, czy znały do końca odpowiedź, czy nie. Natomiast ta forma Retrospektywy uważam, bardzo fajnie zadziałała w sytuacji, w której faktycznie zespół miał dużo pytań. To były często takie pytania niezadane. Moim zdaniem gdzieś tam w powietrzu było czuć takie lekkie zniecierpliwienie, kiedy to wdrożenie, jaka jest dokładna data. Ta data w ogóle bardzo mocno upływała, zmieniała się. W moim odczuciu ta zmiana struktury, o której mówisz, to inne podejście do Retrospektywy spowodowało, że atmosfera się oczyściła. Te pytania, jak się na nie spojrzało z boku, było wyraźnie widać, o czym zespół chce porozmawiać i akurat ta formuła zadawania pytań, no uważam z perspektywy obserwatora, w tym momencie, w którym ten zespół się znajdował, była najbardziej odpowiednia.

Kuba: I jak przywołujemy ten temat elastyczności formuły, to też nie chodzi o to, żebyśmy teraz przez najbliższe 30 minut wymieniali kolejne nietypowe techniki na Retrospektywę. Natomiast w tym punkcie, to jest jednak jednoznaczny apel do każdego Scrum Mastera i każdej Scrum Masterki, żeby dobierali techniki na Retrospektywę świadomie. Żeby to nie było na zasadzie – A dzisiaj sobie zrobię to, albo dzisiaj zrobię to jak zawsze. Tylko raczej się zastanowili, czego mogą się spodziewać? Co zaobserwowali w ostatnim Sprincie, a może w dłuższym okresie czasu kilku Sprintów. Dobranie tej techniki może wymagać również porozmawiania z kolegami, koleżankami z firmy, innymi Scrum Masterami. Być może trochę podpytanie zespołu też, co czują, co widzą? O czym będą chcieli rozmawiać na Retro. Czyli jakby takie przygotowanie się do Retrospektywy, to jest nie tylko samo wybranie techniki, ale też zastanowienie się, jakie mamy opcje. Czego używałem? Czego nie używałem? Być może jest okazja, żeby użyć czegoś, czego do tej pory nie użyłem nigdy. Warto to eksplorować, bo te rutyny tutaj do niczego nas nie prowadzą. W najlepszym razie robimy po prostu nudne Retro. W najgorszym razie jak już parę razy wspomnieliśmy, narażamy się na wycinkowe myślenie o Retrospektywie, albo przegapiamy jakieś ważne szanse. A Twój przykład, który ostatnio powiedziałeś à propos pytań, bardzo ładnie nawiązuje do kolejnej pułapki, popularnej na Retrospektywach, czyli tzw. „Słoń w pokoju”. To widzę to czasami w zespołach. Ja coś widzę, ale jeszcze nie mam pewności. Nikt inny ani piśnie, że coś nie gra, że coś tu śmierdzi, coś tutaj przyszedł jakiś słoń. Nie dość, że nam zabiera całe powietrze, to nawet jeszcze nawalił nam. I tutaj co się dzieje? No i nikt nie mówi tego głośno. Nie wiem, najpopularniejszy dla mnie przypadek, taki dosyć pewniak, to jest temat, jeśli praca prowadzona jest w sposób taki projektowy, albo rozwój produktu ma takie dłuższe releasy, no to takim klasykiem zawsze jest – zdążymy, nie zdążymy? Bezpieczniej jest nawet nie pytać, czy zdążymy. Ale wszyscy czują, może będą nadgodziny, a może trzeba będzie się tłumaczyć, a może znowu będzie jakość obniżyć, żeby dopchnąć kolanem. To na wszelki wypadek o tym nie gadajmy. No i to niestety często prowadzi do tego, że te słonie w pokoju są tak długo nieporuszane, aż w końcu będzie za późno. To tak dosyć często staram się ten temat, chociażby rozbroić. Bo może lepiej sprowokować dyskusję stwierdzeniem – Dobra to nie zdążymy, kto jeszcze tak sądzi? Niż raczej udawać – Dobra zdążymy, albo nawet nic tam nie mówić, bo może zapomną, może opóźnią, może przesuną i jakoś to będzie. Za pół roku, za rok, a może nawet nie dożyjemy w tej firmie. Czyli jest ogólnie mówiąc taki patent, patern, powtarzający się wzorzec. Są trudne tematy, o których nie rozmawiamy i jakoś tak się dzieje, że nikt o tym nie rozmawia. No i co można wtedy zrobić?

Jacek: No wiesz co, może jeszcze komentarz, zanim pójdę w rozwiązanie. Często obserwuję taką sytuację, w której przykładowo kolejny Sprint z rzędu jest Sprintem nieudanym, jest Sprintem niezrealizowanym. Widać na twarzach stakeholderów, interesariuszy, no, że trochę już tracą cierpliwość, przewracają oczami. Zespół trzyma silnie w ręku pędzel. Zielona farba, wszystko jest odmalowane. Szukanie w sumie plusów tego i korzyści, ale tak naprawdę no to któraś iteracja, która nie kończy się sukcesem. No i wchodzimy na Retrospektywę, najczęściej w roli Agile Coacha, obserwatora, mentora. Patrzę sobie z boku i mówię sobie, no teraz przegadają sobie temat.

Kuba: Nie ma opcji, muszą, zanurkują.

Jacek: Teraz, jakby now or never. I niestety na tablicę lądują wesołe kartki z tematami kompletnie nie na temat. Absolutnie pomysły na mikrousprawnienia w obszarach, które totalnie moim zdaniem nie mają znaczenia. Skoro Sprinty dwutygodniowe od sześciu tygodni nie ma sensownego przyrostu. Cele Sprintu są nierealizowane. No tutaj, jeśli chodzi o rozwiązania, ja myślę nie jest niczym złym jeżeli jesteś osobą, która widzi z boku i widzisz też ten etap na poziomie, że w ogóle nikt w grupie tego nie dostrzega. To, co ja robię, to po prostu pytam. Tak na zasadzie – A wiecie co? Tak z mojej perspektywy istotny temat. Trzeci Sprint z rzędu, cel Sprintu nie zrealizowany, co o tym myślicie? No i czasem pierwsza reakcją jest „Wicie, rozumicie”, na zasadzie „No tak, ale”. Takie tłumaczenie, ale zwykle, jeśli przetrzymać ten okres takiego wstępnego odrzucenia jakby tej rzeczywistości. Czasem można powtórzyć pytanie, czasem można je pogłębić. No to zwykle zaczynamy odgrzebywać trochę rozdrapywać i jakby odgarniać te wszystkie tematy poboczne i dochodzić do źródła problemu. Niesamowity jest ten moment, kiedy w końcu – ja to tak obrazowo widzę, że zespół nagle zgadza się z tym, że to jest poważny temat. I dosłownie ten moment przełączenia z trybu, a przecież to nic poważnego. W tryb taki, że – nie, no dobrze, to jest w sumie ważny problem. I nagle wszyscy się zaczynają angażować i dyskutować o przyczynach źródłowych, których oczywiście jest 150. No to uważam, że warto coś tam z boku wskazać, pokazać, odzwierciedlić, co się obserwuje, co widać z perspektywy trzeciej osoby, no, żeby taki temat delikatnie wywołać.

Kuba: No i jak się wywoła, bo tu już trochę optymizmem powiało z Twojej strony, że jak już się tego słonia pokazać, to już wszyscy ruszają się do roboty, żeby go z pokoju wypędzić. Czasem chyba jest też tak, jak już go wszyscy zauważą, to też będzie odrobina nieśmiałości, żeby go jednak zaatakować, to to też myślę, że cieszmy się, że to zauważymy i spróbujemy coś drobnego zrobić, bo często słoń często ma swoją konstrukcję rozbudowaną, że wcale go nie będzie tak prosto wywalić. Ja myślę też, że jeśli moderuję takie rozmowy. À propos wywołania takich trudnych tematów, to po pierwsze są techniki mocniej wyciągające pewne rzeczy i to może być na przykład takie pytanie, jakieś na maksa otwarte pytanie, nie przywołam dokładnej konstrukcji, ale to jest coś w stylu idealny Sprint. Jakby wyglądał idealny Sprint. Albo co musiałoby się wydarzyć, żeby nam się udał idealny Sprint? Oczywiście formułą tego pytania można się jeszcze długo bawić i je ulepszać, ale jakieś takie przeniesienie całego zespołu w ten świat nie ten tu dzisiejszy, gdzie ten słoń nam tutaj ten pokój strasznie wypycha, tylko jak rozumiemy ten bardzo fajny udany Sprint. Gwarantuję, że w trzech, czterech odpowiedziach są dokładnie przeciwieństwa tego słonia, którego mamy dzisiaj. Być może jakby tak pośrednio zwrócimy uwagę ludziom na to, że – O słuchajcie, ten idealny Sprint to ten, w którym nie mamy błędów na produkcji? Hmm… A jak jest teraz? I tutaj się okazuje, że statystyki są nieubłagane i dosyć szybko przechodzimy do tego, że no to może byśmy coś z tym zrobili? Ale w każdym razie moderator tej sytuacji musi dostrzegać. Jeśli Scrum Master też tego nie widzi to już mamy kłopot. A jeśli jednak to dostrzegamy, albo sobie uzmysławiamy, a zespół to trochę odrzuca, to możemy się tak trochę dookoła pobawić w to, żeby do tematu dojść i wyciągnąć. Druga rzecz, która przychodzi mi w tym temacie już jako taka ostatnia, że jednak w grupie zazwyczaj jedna wyczulona, czy dwie osoby się znajdą. I to może być tak, że trochę podsterowujemy rozmowy poprzez wzmocnienie głosu tej osoby bardziej marudzącej, sceptycznej, to, że obecny status quo jest akceptowalny i być może jakaś parafraza, jakieś takie trochę obronienie, trochę stanięcie po stronie, wyjście z roli takiego super niezależnego sędziego i jednak wzmocnienie pewnych głosów, które są dla dobra zespołu istotne i niepozwolenie, żeby inni członkowie zespołu te głosy zakrzyczeli.

Jacek: No tym bardziej, jeśli moderatorem akurat jest Scrum Master, który po prostu jest członkiem Zespołu Scrumowego, więc jak najbardziej ma możliwość zaakcentowania jakiegoś tematu. No i z tytułu bycia w roli Scrum Mastera, może mieć jakieś obserwacje. A drugie, co mi tutaj przychodzi do głowy, no to też takim często inicjatorem niewygodnych rozmów z moich doświadczeń jest właściciel produktu, który się pojawia i dzieli się jakby swoją perspektywą biznesową. No i akurat ten przykład, o którym mówiliśmy – No fajnie, że sobie tutaj rozmawiacie o komunikacji, ale pomówmy może o tym, jak skutecznie dostarczamy produkt. No tylko ten Product Owner musi być, żeby taką dyskusję otworzyć.

Kuba: Dobra, to trochę zbliżając się już do końca odcinka, poruszmy ostatnią z pułapek. Taką bym powiedział osobistą, Scrum Masterską. Nazwaliśmy ją tutaj inspirując się programem „Jeden z dziesięciu” – „Na siebie”. Czyli zespół ustala jakieś fajne ustalenia, ustala jakieś działania, ustala jakieś akcje. I jakoś tak się magicznie dzieje, że każda jedna z karteczek podpisana jest imieniem Scrum Mastera lub Scrum Masterki, bo to ta osoba wykona konkretne działania. To ta osoba gdzieś pójdzie, to ta osoba założy jakąś stronę, to ta osoba założy jakiś plakat, to ta osoba wyśle zaproszenie. I nagle się okazuje, że 100% wynikającej z Retrospektywy, nie wiadomo do końca jak, ale ląduje w task liście, czy w zadaniach, czy na boardzie, czy w karteczkach, czy w notatniku Scrum Mastera, Scrum Masterki.

Jacek: To też myślę, że przyczyną tego, że tak się dzieje, może być tematyka, tematy, które poruszamy na Retrospektywie. Bo jeżeli, wracając do tej naszej pułapki, rozmawiamy tylko o rzeczach miękkich, to faktycznie wyobrażam sobie, że ten Scrum Master może tam mieć dużo tematów, z kimś porozmawiać, jakiś temat popchnąć, coś tam zmienić. Natomiast no jeżeli, zespół ustala rzeczy inżynieryjne, techniczne, a Scrum Master nie jest developerem, w sensie nie współtworzy produktu w zespole, pisząc kod na przykład, czy testując. No to w sumie, dlaczego on miałby robić jakieś rzeczy związane z code review, z repozytorium, czy z jakimiś tam środowiskami. Tak więc to może być jakaś żółta lampka na zasadzie – jeżeli zbyt dużo trafia do Scrum Mastera, to być może nie poruszamy tematów tak szeroko, jak powinniśmy. Tak wszystko z uproszczenia to jest takie, wszystkie ustalenia są takie scrumowe, no to z automatu Scrum Master. Więc to jest jakby jeden aspekt. Natomiast trochę już jakby szukając rozwiązań, ja osobiście uważam, że cały zespół odpowiada za to, żeby się usprawniać. Więc na takim super prostym podejściem, które zdarza mi się stosować, jest taka zasada, że podczas ustaleń konkretnych akcji na Retrospektywie idziemy jakby osoba po osobie. Czyli nie ma sytuacji, że ktoś wychodzi ze spotkania i ma na sobie dwa tematy. Tylko – Dobrze, to ja biorę to. Ktoś inny bierze coś innego. I nawet jeśli dla tej osoby to będzie to coś nowego, to nic nie stoi na przeszkodzie, żeby się nauczyć, albo żeby ktoś wsparł tę osobę w zrobieniu tego konkretnego zadania.

Kuba: Tak, to jest szczególną pułapką i nieszczęściem, jeśli ja to też pamiętam ze swojego scrum masterowania, jeśli zespół oczekiwałby ode mnie, albo ja sam bym sobie włożył, jako swoją własną ambicję, że to ja muszę załatwić ten temat, nie wiem z monitoringiem, albo poprawić temat nieudanych konfiguracji na serwerze, tylko byłbym głuchym telefonem. Więc to często jest tak, że z jakiegoś powodu to się dzieje, a na końcu to jest pułapką. Zespół nie uczy się odpowiedzialności za zadania. Nie uczy się pewnych rzeczy. A w ogóle trwa to wszystko dłużej i być może jest realizowane gorzej, bo bazujemy na jakimś pośrednictwie lub zadanie bierze na siebie nie koniecznie ktoś, kto je przerobi. Jeśli bierze pięć rzeczy z Retro, a nikt inny nie bierze żadnej. Więc tutaj warto sobie ten temat przegadać i go po prostu w zespole postawić jako temat, że są rzeczy, w których różne osoby się sprawdzają i nie wszystkie usprawnienia musi robić Scrum Master, to jest pierwszy krok. A fajnie, jeśli cały zespół jakoś w tym kontrybuuje, a jeszcze lepiej, jeśli się okaże, że po cząsteczce to prawie każdy członek zespołu może coś zrobić. Ten coś wyśle, ten coś zrobi, ten coś sprawdzi, ten skonsultuje, a w ogóle we trzech pójdziemy gdzieś, coś pogadać. Bo te usprawnienia często da się zdekomponować na bardzo drobne rzeczy. No i wtedy jest i zespołowość i taka współodpowiedzialność. I na końcu się okaże, że to też jest taka koleżeńska postawa, że każdy zrobił po kawałeczku. W sumie to nas nie boli, a nie, że ktoś był zarobiony cały dzień, bo musiał mieć jakieś wielkie tam usprawnienie.

Jacek: Dobrze. Podsumowując dzisiejszy odcinek, skupiliśmy się na tym, jakie pułapki możesz spotkać, jakie pojawiają się podczas Retrospektyw. Omówiliśmy pułapkę, którą nazwaliśmy „Retro żale”, czyli skupianie się tylko na rzeczach negatywnych. Porozmawialiśmy tylko o pułapce dyskutowania wyłącznie tematów miękkich, zapominając o tematach twardych. Oraz o lustrzanej pułapce mówiącej o tym, że dyskutujemy tylko na tematy twarde, inżynierskie i kompletnie pomijamy aspekty miękkie. Wspomnieliśmy także o braku elastyczności struktury, o takim ciągłym powtarzaniu tych samych struktur, metod, sposobów prowadzenia Retrospektywy. Dwie ostatnie pułapki. „Słoń w pokoju”, czyli nie poruszamy tematów, które za chwilę zaczną, bądź już nas uwierają, no bo po prostu tak jest trochę prościej, bądź faktycznie zespół nie dostrzega problemu. I ostatnia pułapka będąca pod tytułem „Scrum Master bierze wszystkie zadania na siebie”. I to będzie tyle, jeśli chodzi o dzisiejszy odcinek. Dzięki Kuba.

Kuba: Dzięki Jacek.

Jacek: Do zobaczenia wkrótce.


One Reply to “#006 – Pułapki Retrospektywy Sprintu”

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Jesteśmy też tutaj

Podcast od kuchni. Tak nagrywamy dla Ciebie!

Jacek Wieczorek i Kuba Szczepanik
scenariusz do nagrania podcastu
Jacek Wieczorek Kuba Szczepanik podcast

Opinie naszych słuchaczy.

„To jest to! Ekstremalnie dobra dawka potrzebnej wiedzy. Część podcastów otwiera oczy, część porządkuje wiedzę. Polecam!”

„Mimo iż nie jestem bardzo związany z agilem/scrumem, jakieś doświadczenia z nim miałem („retrożale” ;), to bardzo przyjemnie się Panów słucha. Duża i bardzo konkretna dawka wiedzy, bez przynudzania, widać „napracowanie” przy każdym odcinku, jakość ścieżki audio na poziomie, całość w odbiorze sprawia profesjonalne wrażenie. Życzę obu prowadzącym sił do kontunuowania tego (nie)małego dzieła. :)”.

„Takich podcastów nam potrzeba!”

Oceń Podcast. Kliknij poniżej.

Apple Podcast logo
logo stitcher
Wordpress Social Share Plugin powered by Ultimatelysocial