Dobrych praktyk nigdy za wiele. Jeśli są te dobre, to gdzieś w czeluściach zwinnego podejścia muszą istnieć również złe praktyki, których powinniśmy unikać jak ognia. Jeśli stosujesz któreś z czterech dziś opisanych, możesz być pewny/a, że hasło „Retrospektywa – robisz to źle!” jest skierowane waśnie do Ciebie.
Złe praktyki – Retro
Niezależnie czy jesteś Scrum Masterem, Produkt Ownerem czy Deweloperem może Ci przypaść w udziale facylitowanie Sprint Retrospective. Zdziwiony/a? Niepotrzebnie, zgodnie z literaturą (Scrum Guide) każdy jest odpowiedzialny za facylitcję tego wydarzenia. Istnieją pewne praktyki, których musisz unikać jak ognia, inaczej Retrospektywa, która jest delikatna niczym skrzydła motyla, w najlepszym wypadku będzie straconą godziną czy dwiema.
Należy podkreślić, że przedstawiony w dzisiejszym opracowaniu „Top 3” to wierzchołek góry lodowej. Co więcej, każdy z nas będzie miał swoje własne złe praktyki, które wykształciły się wraz z doświadczeniem na przestrzeni kolejnych lat scrummasterowania. Jeśli tak jest, nie czekajcie, pochwalcie się koniecznie swoimi przemyśleniami w komentarzu do dzisiejszego wpisu.
Moje prywatne „Top 3” zbierałem dość skrupulatnie z biegiem lat. Na pewno są one dobrze przemyślane. Co więcej, jestem pewien, że każdy z Was miał okazje spotkać się z nimi również w swoim zawodowym życiu. Zatem do dzieła!
Retro – wcześniej
Rozpoczynamy od samej organizacji Retrospektywy. W głowach wielu osób istnieje (błędne) przekonanie, że nie da się wygenerować dobrych obserwacji w powiedzmy max. 10 min podczas pierwszej części Retro, czyli generowania pomysłów. Co więcej, wielu powie, że takie obserwacje mają niską wartość dowodową i mogą zaburzać obraz całości. Co więc zrobić? Dajmy sobie czas „przed” retro!
Na wcześniej przygotowanej tablicy zbierzmy feedback od ludzi jeszcze przed zamknięciem Sprintu – tak ze 3-4 dni przed. Na pewno czas ten będzie wystarczający do skutecznego zebrania informacji. Nic z tego, że jak pokazuje doświadczenie największa część prac (a więc i potencjalnie największa przestrzeń do poprawy) przypada na 2-3 ostatnie dni Sprintu. Na pewno ludzie znajdą czas na zastanowienie się nad potencjalnymi tematami do usprawnień i przewidzą to, co zaraz ma się wydarzyć.
Innym ubocznym skutkiem powyższego będzie to, że nie każdy znajdzie czas na wcześniejsze uzupełnienie tablicy. Co wtedy zrobić? Dać jeszcze ludziom czas na początku wydarzenia? A co z tymi, którzy się jednak przyłożyli? Czy z ich punktu widzenia będzie to fair?
Jak widzicie pytań i kontrowersji jest multum, a najlepsze, co możemy zrobić to nie zbierać potencjalnych usprawnień wcześniej. Czas retro powinien być wystarczający!
Nie tylko Scrum Team
Gotowi na kolejny problem? Sami go powodujemy, kiedy zapraszamy na Retrospektywę osoby spoza zespołu, na przykład Interesariuszy. Po co? Najczęściej wynika to z dwóch kwestii – pierwszej i drugiej. Pierwsza z nich to zapisy jakichś umów czy kontraktów, w których Klient gwarantuje sobie prawo do współuczestniczenia w Retrospekcji zespołu, za który płaci. Źle. Drugi z najczęstszych powodów to brak świadomości, że tak retrospektywa wyglądać nie powinna. I tak, wiem, że trudno w to uwierzyć.
Jedno i drugie powoduje, że nie jesteśmy w stanie odmówić „obcym” w uczestnictwie w „święcie zespołu”. Piszę to pół żartem, pół serio, bo przecież retrospektywa to jednak ten szczególny czas w życiu Scrum Team, podczas którego możemy powiedzieć i pochwalić się wszystkim, co nam przysłowiowa ślina na język przyniesie.
Wyobrażacie sobie, aby podobnie zachowywać się w obecności Klienta / Zamawiającego? Ja też nie! Co więcej, jestem pewien, że takie Retro nie przyniesie oczekiwanych skutków.
Skład i wyszukane techniki
Przyznam się szczerze, że miałem problem z trzecią złą praktyką. Nie umiałem wybrać między przyzwoleniem na nieprzechodzenie, a wymyślaniem coraz to bardziej wymyślnych sztuczek, które spowodują, że Retrospektywa będzie ciekawa. Ale po kolei.
Napisałem kiedyś tekst o broken-window-theory. Przyzwolenie na nieprzychodzenia na Sprint Retrospective, bo błąd na produkcji, bo „muszę wyjść dziś wcześniej”, bo „nic się szczególnego nie wydarzyło”, czy tysiąc innych wymówek, to nic innego jak wcielenie powyżej teorii w życie. Pozwolenie na to, aby raz, drugi , trzeci ktoś nie był obecny na Retrospektywie, to nic innego jak samodzielne psucie metodyki, w której pracujemy. Nie będę wchodził tutaj w polemikę, dlaczego tak się dzieje. Na pewno jest to jednak znak zmuszający nas do zastanowienia się nad źródłem tego problemu.
Kolejnym aspektem, tym, spośród którego nie umiałem wybrać jest stosowanie coraz to bardziej wymyślnych technik. W swoim zawodowym życiu spotkałem Scrum Masterów, którzy przez długi czas stosowali jedną technikę jak i takich, którzy za każdym razem wymyślali coś nowego i najczęściej… niezrozumiałego. W tym i każdym innym przypadku należy dostosować techniki do możliwości i środowiska, w którym się obracamy. Na nic skomplikowane techniki, których nikt nie rozumie, czy które nie przynoszą oczekiwanych efektów. Przepraszam, przyniosą efekty, najczęściej będzie to jednak efekt zniechęcenia. Ten sam efekt osiągniemy, jeśli będziemy w kółko męczyć wszystkich jednym i tym samym ćwiczeniem. Rozwiązaniem jest, jak zwykle, złoty środek, czyli odpowiednia (dla zespołu) zmienność.
A jakie są Wasze „ulubione” złe praktyki dotyczące Retro?
