Ostra Piła nr 23

5
2517
Piktogram piły tarczowej

Chłopaki z podcasta Ostra Piła założyli grupę na FB.

Zapisałem się z myślą, że będę tam szalał w ogniu dyskusji i już chciałem nasmarować pierwszy komentarz odnośnie odcinka numer 23, gdy podczas pisania uświadomiłem sobie, że tekst ten będzie na komentarz odrobinę za długi, a przez to nieczytelny. Nie jest to pierwszy raz, gdy odcinek podcastu inspiruje mnie do napisania artykułu na bloga, więc co tam – napiszę i teraz 🙂

Jarek i Paweł tym razem pochylili się nad tematem retrospekcji. Przez 1:40h rozmawiali sobie a mnie skręcało, żeby coś powiedzieć 🙂 I w myślach zapisywałem sobie wątki, które chciałbym omówić, ale jadąc na rowerze raczej trudno to sobie zapisywać, więc dużą część z pewnością już zapomniałem. Z tego co zostało, postaram się coś sklecić – oby miało to jakiś sens.

Przede wszystkim nie mamy retrospektyw.

Od początku mojej kariery zawodowej miałem tego rodzaju spotkania raczej rzadko – nawet, gdy pracowaliśmy we frameworku scrumowym. W jednym z projektów, takie spotkania jednak odbywały się regularnie przez pewien czas, aż w końcu doszliśmy do wniosku, że to nie działa i zaprzestaliśmy ich. Audycja Ostrej Piły zachęciła mnie do ponownego przemyślenia dlaczego tak się stało.

Nie doszedłbym do tego, gdyby chłopaki nie przeskakiwali po różnych zagadnieniach związanych z retrospekcją, a które po kolei malowały w mojej głowie następujący obraz. Otóż retrospekcje są niepotrzebne, ponieważ albo są zbyt późno, albo poruszane są na nich nieistotne zagadnienia, które nie muszą i nie będą realizowane, co po którejś z kolei porażce spowoduje zaprzestanie całego procesu.

Może skupię się bardziej na odpowiedzi na przykłady chłopaków.

Wiem, że mówili oni raczej o wymyślonych problemach, ale mają one posmak rzeczywistości, stąd odniosę się właśnie do nich. Aby nie adresować każdego osobno, podzieliłem je sobie na grupy.

Pierwsza grupa to problemy, które powinny być rozwiązywane natychmiast

i tych jest najwięcej. Przykry zapach skarpetek kolegi z biurka obok, jakieś problemy osobiste, wszystko to, co nam bardzo przeszkadza powinniśmy zmieniać natychmiast. Nie rozumiem jak miałoby wyglądać czekanie na retrospekcję za dwa czy trzy tygodnie i co – męczenie się z przykrym zapachem, podczas gdy wystarczy odezwać się do kolesia obok i rozwiązać tę sprawę natychmiast? Wg mnie jest to zupełnie bez sensu. Ktoś może pewnie powiedzieć: „a co, jeżeli on nie będzie chciał współpracować?”. Prosta sprawa – zawsze jest ktoś wyżej. Załatwienie takiej sprawy to 20 minut rozmowy, a komfort pracy nieporównywalnie większy.

I właśnie odpadła nam pewnie ponad połowa problemów na retrospekcję.

Kolejny przykład – sprawy, które także powinno się załatwiać natychmiast, ale nie osobiście, tylko za pomocą team leadera czy kogoś w tym rodzaju. „Spacje czy taby”, „złe opisy tasków” i tego typu rzeczy – team leader powinien w mig wyłapywać takie sprawy i załatwiać je natychmiast. Na przykładzie spacji – u nas w teamie zawsze na początku projektu rozmawialiśmy o standardach kodowania i ustalaliśmy jak należy skonfigurować VS i/lub R#. Jeżeli dyskusja nie mogła być rozwiązana przez koderów, ostateczny głos miał team leader. Nie spotkałem się jeszcze z takim nieogarem, który by stawiał się w tak prozaicznych sprawach, ale być może są tacy – wtedy nawet retrospekcja nie pomoże, trzeba go wywalić.

Coraz mniej tego zostaje.

Zastanawiałem się nad takimi rzeczami jak „dzwonimy do klienta”. To rzeczywiście mogłaby być sprawa na retrospekcję gdyby nie to, że to przecież widać – szef zespołu wyłapie natychmiast, że ludzie mają problemy z taskami i nie ma sensu czekać kilka tygodni na rozwiązanie tego. A jeżeli znów możemy poczekać do retrospektywy, to znaczy że sprawa najprawdopodobniej nie jest pilna/ważna i nawet, gdy postanowimy na retrospektywie się za nią zabrać, to i tak zawsze znajdzie się coś ważniejszego i tylko ucierpi nasze morale, gdy na kolejnej retro uświadomimy sobie, że zadania z poprzedniej nie zostały ruszone.

Więc mam wrażenie, że wyjaśniłem dość jasno, dlaczego uważam, że retro nie są potrzebne – po prostu dobry team leader czy ogólnie szef potrafi zidentyfikować ważne problemy w zarodku i zareagować jak najszybciej.

Kolejna ciekawostka z rozmów w audycji – jeżeli jesteśmy już na retro, to bierzemy jeden „najważniejszy” problem i postanawiamy się z nim rozprawić. Tutaj zgodzę się bardziej z Jarkiem. Powiedzmy, mamy problemy – źle opisane taski oraz śmierdzące skarpetki. Oba nie mają płaszczyzny wspólnej, oba można załatwić szybko, a do tego powiedzenie, że na jednej retro bierzemy tylko jedno zadanie jest wg mnie mylne – ponieważ oba powyższe problemy będziemy musieli naprawiać przez cały czas trwania projektu.

Powiedzmy – pierwsza retro – skarpetki. Za dwa tygodnie – telefony do klienta. Za trzy – problemy ze standardami kodowania. Za cztery nie mamy już żadnych problemów, ale czy oznacza to, że już nie staramy się, żeby one nie wróciły? No nie, cały czas zespół pracuje nad tym, żeby dzwonić do klienta a problemy z higieną nie nawracały. No i oczywiście w razie kolejnych zgrzytów ze standardami kodowania będą one na bieżąco rozwiązywane.

Co tydzień zatem na pierwszy rzut oka zajmowaliśmy się tylko jedną sprawą, ale naprawdę z każdym tygodniem tych spraw przybywało. I robiliśmy równolegle coraz więcej i więcej.

Dość na dziś.

Mam nadzieję, że dość jasno przedstawiłem, dlaczego nie mamy retrospekcji i nie tęsknimy za nimi. Po prostu ważne problemy rozwiązywane są jak najszybciej. Za nieważne nie warto się zabierać, bo w trakcie sprintu i tak nie będzie na to czasu. A tak przy okazji pokazuje to wg mnie, że coś nie tak jest z całym tym frameworkiem scruma. Wiem, że to tylko zbiór wskazówek, ale przypomina mi to świętą księgę, którą można sobie dowolnie interpretować. Gdy zrobi się sobie tym krzywdę, zawsze ktoś może powiedzieć „no widzisz, źle to zrobiłeś, a przecież wyraźnie było napisane…„. Takie wskazówki, które można sobie interpretować i robić po swojemu, najczęściej można sobie w buty wsadzić.

Bo szczerze – w ilu firmach widzieliście sprawnie działający scrum? Ja w żadnej i wątpię, żeby to był problem z firmami, bo pracowali tam naprawdę kumaci ludzie.

(Po komentarzu Andrzeja umieszczam także link do strony audycji.)

0 0 votes
Article Rating
Subscribe
Powiadom o
guest
5 komentarzy
najstarszy
najnowszy oceniany
Inline Feedbacks
View all comments
Paweł Bulwan
6 lat temu

Też słuchałem ostatnio tego odcinka, ciekawie widzieć inne doświadczenia i spojrzenia na temat takie jak Twoje 🙂

Ja akurat bardzo lubię formułę retro, gdzie każdy w zespole indywidualnie jest zachęcony żeby się wypowiedzieć. Udaje się w zalążku rozwiązywać irytujące drobnostki – komuś słabo pasuje godzina stand-upów, temperatura klimatyzacji, brak licencji na nowszą wersję narzędzia. Czasami też grubsze tematy, ale zwykle można się zamknąć w kilkunastu minutach i wyjść ze spotkania z listą konkretnych akcji.

Masz pewnie rację, że dużo z tych rzeczy można rozwiązywać na bieżąco, natomiast wydaje mi się że w praktyce czasem dobrze jest ludzi zapytać, żeby dostać odpowiedź – nie każdy wychodzi z inicjatywą żeby się dzielić swoimi problemami 😉

Paweł Szczygielski
6 lat temu
Reply to  Paweł Bulwan

Dzięki za komentarz Paweł. Zastanowiłem się jeszcze troszkę i chyba u nas największym argumentem za zaprzestaniem retrospektyw był brak satysfakcjonującego odsetka akcji. Po spotkaniu mieliśmy kilka rzeczy, które trzeba zmienić, ale były one na tyle nieistotne, że i tak nikt z nimi nic nie robił – z braku czasu, który zajmowały ważniejsze sprawy. I tak to umarło śmiercią naturalną…

Paweł Bulwan
6 lat temu

Skoro nikt nie płacze, to widocznie można żyć i bez tego 🙂 Chyba sobie w końcu poczytam coś o tym scrumie i jak to powinno być w teorii, bo póki co to znam tylko z obserwacji, a tak jak piszesz – te w praktyce bardzo się różnią między firmami i zespołami 😉

Paweł Szczygielski
6 lat temu
Reply to  Paweł Bulwan

Moim „zarzutem”, który podniosłem na koniec wpisu, jest właśnie mocna teoretyczność frameworku Scrum i to, że luźny zbiór wskazówek, który można dowolnie interpretować, najczęściej prowadzi do wypaczeń. Może to miejsce dla konsultantów, którzy jeżdżą po firmach i uzdrawiają sytuację?

trackback

[…] tym kończę. Nie jest to pierwszy podcast, do którego słuchania zachęcam. Wcześniej była Ostra Piła, a w swoim telefonie mam ich jeszcze co najmniej kilka i po którymś, równie udanym odcinku, z […]