Pułapki Retrospektywy Sprintu

Jakie są pułapki 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ć. 

Porządny Agile · #006 – Pułapki Retrospektywy Sprintu

O tym, czym jest Retrospektywa możesz przeczytać w poprzednim artykule. Poruszaliśmy tam też problemy, jakie mogą się pojawić w związku z jej strukturą. 

W tym artykule kontynuujemy temat przeprowadzania porządnej Retrospektywy Sprintu. Skupiamy się na wątkach, które wcześniej pominęliśmy lub tylko delikatnie zasygnalizowaliśmy. Opiszemy potencjalne pułapki Retrospektyw, które spotykamy w codziennej pracy z Zespołami Scrumowymi.

Skupianie się na rzeczach, które się nie udały lub są niesatysfakcjonujące

Określamy to roboczo jako “Retro żale”. Taka pułapka jest szczególnie niebezpieczna, gdy zespół całkowicie zapomina o tym, co poszło dobrze, działa i mogą być z tego dumni. Utrzymywanie się tej pułapki Retrospektywy może wykształcić w zespole trwałe poczucie, że Retrospektywa jest jednoznaczna z wytykaniem błędów. Retro kojarzy się wtedy z poruszaniem mało optymistycznych wątków i omawianiem wyłącznie niedociągnięć.

Takie ryzyko często jest związane ze sposobem przeprowadzania Retrospektywy i doborem wykorzystywanych technik. Jeśli Scrum Master wartościuje obserwacje i do dyskusji wybiera tylko rzeczy do poprawy, automatycznie odcina możliwość rozmawiania o pozytywach. Przyczyną takiego podejścia może być chęć optymalizacji czasu przeznaczanego na Retro. Łatwo też o błędne założenie „skoro te rzeczy wyszły dobrze, to nie musimy o nich rozmawiać”. Z niego może wynikać skupienie się tylko na tym, co jest do usprawnienia.

Duża odpowiedzialność z uniknięciem tej pułapki Retrospektywy leży w rękach moderatora, czyli osoby, która prowadzi Retrospektywę. Nawet jeśli ze strony zespołu wychodzi propozycja pominięcia rzeczy, które wyszły, to właśnie moderator powinien im uświadomić, że rozmowa o pozytywach też ma znaczenie.

Za uzasadnienie takiego podejścia niech posłuży sytuacja, gdy Jacek współpracował z zespołem, który dopiero zaczynał przygodę ze Scrumem. Po dwóch tygodniach robienia regularnie Daily wszyscy zgodzili się, że to fajnie wyszło i chcieli pominąć omawianie tego. Członkowie zespołu zostali zapytani, dlaczego i z czego wynika fakt, że te spotkania miały dla nich wartość. Zaskakująco dla wszystkich zebrała się spora liczba ciekawych wniosków z różnej perspektywy. Te wnioski były istotnym czynnikiem umożliwiającym rozwój zespołu. Były zwerbalizowanymi wskazówkami, co działa, co można wykorzystać w innych aspektach pracy zespołowej w tej firmie.

W ramach Retrospektywy można przecież nie tylko poprawiać rzeczy, które w zespole nie wyszły, ale także usprawniać to, co zespołowi wychodzi dobrze. Celem usprawnienia może być to, aby robić to jeszcze lepiej.

To też dobry moment, aby wzmacniać poczucie, że warto eksperymentować. Nawet jeśli trzy razy z rzędu eksperymenty nie wyszły, gdy za czwartym razem coś się uda, znajdź w swoim zespole chwilę na celebrację tego i omówienie, dlaczego tym razem się udało. To jest naprawdę dobre paliwo dodające odwagi do próbowania nowych podejść w kolejnych Sprintach.

Dyskusja o tym, co wyszło dobrze, to też szansa dla introwertyków. Zazwyczaj są oni mniej otwarci na rozmowy i trudniej im przychodzi zabieranie głosu. O wiele prościej mówić o pozytywach, niż o tym co jest mniej przyjemne. Odpowiednie pokierowanie tematami sprawie, że również oni będą bardziej chętni do aktywnego udziału w spotkaniach.

Omawianie tylko miękkich tematów

Mówiąc o tematach miękkich mamy na myśli tematy związane z komunikacją, współpracą i z tym, jak się członkom zespołu pracuje. Istotą pułapki jest to, że kompletnie pominięte są aspekty techniczne i procesowe.

Spotkaliśmy się z kilkoma tezami dotyczącymi przyczyn występowania takiej pułapki Retrospektywy. Pierwszą z nich jest to, że Retrospektywa kojarzy się ze spotkaniami coachingowymi, podczas których zadawane są pytania o charakterze psychologicznym. Rozmowy kierują się w stronę naszych motywacji, relacji międzyludzkich i uczuć. Są to ważne kwestie, które również powinny pojawiać się na Retrospektywie, jednak nie powinny one zdominować całego spotkania. Powinno się też znaleźć miejsce na rozmowy o jakości kodu, środowiskach testowych czy wykorzystywanych narzędziach. 

Na to, że na Retrospektywie dominują miękkie tematy, może też mieć wpływ osoba moderatora, która nie ma doświadczenia technicznego. Wspominaliśmy o tym w naszym pierwszym materiale “Kto to jest Scrum Master i czym się zajmuje”. Osobę, która wpada w pułapkę unikania tematów technicznych warto w delikatny sposób uświadomić, że zespół nie powinien zaniedbywać tematów “twardych”.

Przypominamy jednocześnie, że Scrum Master nie musi się znać na wszystkim, o czym zespół mówi. Rolą SM jest dbanie o balans tematów usprawnieniowych i takie prowadzenie wydarzeń scrumowych, aby realizowały swoje cele. A w przypadku Retrospektywy jest to poszukanie ciągłego usprawniania, niezależnie czy to coś ze sfery kwestii miękkich, czy tych technicznych.

Kolejną przyczyną omawianej pułapki Retrospektywy Sprintu bywają niektóre osoby ze społeczności zwinnej, które przesadnie podkreślają, jak ważne są tematy miękkie. Akcentują to, jak ogromna jest moc strony miękkiej w rozwiązywaniu wszelkich problemów. Jak najbardziej kwestie międzyludzkie i komunikacyjne są ważne i często wiele problemów rozwiązują. Ponownie podkreślamy jednak, że Retrospektywa jest też miejscem, gdzie poruszamy i usprawniamy również obszary inżynieryjne.

Omawianie tylko kwestii technicznych

Odwrotną do poprzedniej pułapką podczas przeprowadzania Restrospektywy jest skupianie się tylko na technikaliach. Mamy na myśli takie kwestie jak sposoby dzielenia zadań między sobą, wykorzystywane narzędzia lub czystość kodu.

Rzecz jasna wszystkie te rzeczy są istotne, ale komunikacja międzyludzka to równie ważny element i całkowicie wykluczyć go nie można.

Konkludując, skrajności nie są dobre, trzeba znaleźć czas na tematy miękkie, jak i na te bardziej inżynieryjne.

Brak udziału Product Ownera w Retrospektywie

Przyczyną takiej sytuacji bywa wspomniane wcześniej skupianie się głównie na kwestiach technicznych. W takiej sytuacji nie ma miejsca na dyskusje o tematach wspólnych z Product Ownerem. Wiele zespołów skorzysta, jeśli poruszane będą tematy związane z rozwojem produktu, w tym też te bardziej biznesowe. Obecność PO jest istotna, gdyż może on zauważyć inne rzeczy, gdyż widzi rzeczy z odmiennej perspektywy niż pozostali członkowie zespołu.

Brak elastyczności formuły Retrospektywy

W najbardziej skrajnym przypadku każde Retro jest identyczne. Ten sam początek, te same techniki, te same punkty do odhaczenia, to samo na koniec. Oczywiście, warto mieć dobrze przygotowaną strukturę Retrospektywy, która ma powtarzalny charakter i pozwala przeprowadzić dobre Retro. Jednak należy pamiętać, że w życiu każdego zespołu są takie sytuacje, gdy wydarza się jakiś kłopot lub większy kryzys. Po prostu trzeba o tym pogadać. Dużą rolą Scrum Mastera jest znaleźć na to miejsce.

Sztuką jest zaproponować formę przegadania tematu i pozwolenie na odstąpienie od ustalonej zwyczajowo struktury. Być może dzięki temu wyjdą nam jakieś nowe obserwacje, które wcześniej nie miały możliwości się pokazać. Dodatkowo unikniemy rutyny, która często działa bardzo ogłupiająco i zniechęca do aktywnego udziału.

Będąc w roli Agile Coacha, Jacek miał okazję zaobserwować właśnie taką sytuację. Planowane było wdrożenie produktu na rynek, zespół miał wiele pytań i czuć było lekkie zdenerwowanie. Scrum Master zaproponował nową technikę, w której każdy mógł zapisać dowolne pytanie. Pytania te przyklejał na ścianę. Potem po kolei każde pytanie było zdejmowane, czytane i inna osoba odpowiadała na to pytanie. Niezależnie, czy znała do końca temat, czy nie, próbowała dać jakąkolwiek odpowiedź. Ta zmiana struktury Retrospektywy spowodowała, że atmosfera się oczyściła i pozwoliła na rozwianie wątpliwości i niedomówień.

Mówiąc o elastyczności formuły, nie mamy na myśli testowania na raz kilku nowych technik na każdym Retro. Chodzi nam bardziej o to, aby Scrum Masterzy i Scrum Masterki dobierali techniki na Retrospektywę świadomie. Świadomość taką można uzyskać zastanawiając się, czego możesz się spodziewać na spotkaniu. Zastanów się nad tym, co obserwujesz w ostatnim Sprincie i co wynikło z rozmów z różnymi osobami. Warto też rozważyć podpytanie wprost zespołu, o czym chcieliby porozmawiać. 

Ignorowanie tzw. „Słonia w pokoju”

„Słoń w pokoju” to problematyczna sytuacja, która zagęszcza atmosferę, jednak nikt o nim nie wspomni. Każdy członek zespołu czeka, aż ktoś inny to zrobi.

Przykładem „słonia”, którego często widzimy, to sytuacja, w której nie ma pewności czy zespół zdąży zrealizować na czas zaplanowany kawałek produktu. Bezpieczniej jest nie poruszać tego tematu, choć wszyscy czują, że coś jest nie w porządku. Może będzie trzeba pracować po godzinach, tłumaczyć się z opóźnień czy obniżyć jakość. Jednak warto ten temat chociaż rozbroić, sprowokować dyskusję, co trochę rozrzedzi atmosferę. Nie ma sensu udawać, że może ktoś zapomni, coś innego się przesunie, albo już nie będzie zespołu, gdy przyjdzie rozstrzygnięcie.

Innym przykładem, który często obserwujemy, jest sytuacja, w której kolejny Sprint z rzędu jest Sprintem z niezrealizowanym Celem. Interesariusze powoli tracą cierpliwość, a zespół usilnie stara się pomalować wszystko na zielono, wyszukując plusów danej sytuacji. Dobrze, aby osoba z boku, np. Agile Coach, zaczął zadawać pytania, pomógł rozgrzebać problem i dotrzeć do jego źródła. To bardzo pomaga zmienić w zespole perspektywę podchodzenia do tego tematu, a także zaangażować jego członków do szukania rozwiązań.

Pamiętać jednak należy, że to zadawanie pytań i rozkładanie problemu, powinno być robione powoli. W swej istocie “słoń” ma często rozbudowaną konstrukcję i wielu może przerażać lub onieśmielać. Takim startem mogłoby być pytanie o to, jak wyglądałby idealny Sprint lub co musiałoby się wydarzyć, aby ten idealny Sprint się zespołowi udał. Moderator takiej dyskusji może też wzmacniać niektóre głosy osób bardziej sceptycznych. Może też okazać się niezbędnym, by wyjść na chwilę z roli niezależnego obserwatora i stanąć po tej konkretnej stronie, która chce zmienić status quo.

Wszystkie uzgodnione działania ma wykonać Scrum Master/ka

Istotą tej pułapki Retrospektywy jest to, że osobą odpowiedzialną w praktyce za usprawnienia jest Scrum Master/ka. Jeśli tak się zdarzy, że większość zadań do wykonania trafia do Scrum Mastera, warto zadać pytanie, czy zaplanowane zmiany obejmują wszystkie aspekty pracy zespołu. Cały zespół powinien po równo zaangażować się w usprawnienia, które ich dotyczą. Nie powinno być tak, że jednak osoba z zespołu dostaje 10 zadań, a pozostałe tylko po 1 albo wcale.

Podsumowując, w naszej opinii najpopularniejsze pułapki Retrospektywy Sprintu to:

• Skupianie się na rzeczach, które się nie udały lub są niesatysfakcjonujące;
• Omawianie tylko miękkich tematów;
• Omawianie tylko kwestii technicznych;
• Brak udziału Product Ownera w Retrospektywie;
• Brak elastyczności formuły Retrospektywy;
• Ignorowanie tzw. „Słonia w pokoju”;
• Wszystkie uzgodnione działania ma wykonać Scrum Master/ka

Dodatkowe materiały – pułapki Retrospektywy Sprintu

• Porządna Retrospektywa Sprintu – definiujemy czym jest porządna Retrospektywa
• Kto to jest Scrum Master i czym się zajmuje? – wyjaśniamy kim jest Scrum Master
• Pomysł na Retrospekcję Sprintu – technika 4L – opis techniki 4L na blogu Jacka
• Oś czasu – alternatywna metoda na Retrospektywę Sprintu – artykuł Kuby na temat techniki na retro 

Transkrypcja podcastu „Pułapki Retrospektywy Sprintu”

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 Retrospektywy 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 Retrospektywy, 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 branchowania, git flow, code review. Jak robimy? Z jakiego środowiska? Jakie narzędzia? Doker?

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 Retrospektywy, 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 Retrospektywy, 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 Retrospektywy 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 Retrospektywy. „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.