Ostra Piła nr 23

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.)