Wielu twierdzi, że retrospektywa jest najważniejszą ceremonią w zwinnym zestawie narzędzi. Woody Zuill ujął to w ten sposób: 

Jeśli wprowadzasz tylko jedną praktykę #agile, powinna to być retrospektywa. Wszystko inne nastąpi później.

Woody Zuill

Dlaczego więc zespół programistów może uznać retrospektywę sprintu za zbędną? Z mojego doświadczenia jako Scrum Mastera i psychologa wynika, że zazwyczaj ma to związek z poziomem dojrzałości zespołu.

Co więc możesz zrobić, aby poprawić dojrzałość swojego zespołu – w tym kontekście i ogólnie? Oto 7 przemyśleń, 7 wskazówek, które pomogą Ci sprostać temu wyzwaniu.

Zespół uważa, że retrospektywa jest zbędna: co robić?

Nawiasem mówiąc, oficjalna odpowiedź na egzaminie certyfikacyjnym Scrum brzmi następująco: Scrum Master powinien pracować w zespole, aby uczynić go bardziej wydajnym. Mh, to naprawdę nie pomaga. Co możesz przez to rozumieć?

Scrum Master powinien pracować nad zespołem, aby uczynić go bardziej wydajnym

Oficjalna rola Scrum Mastera jest następująca, jeśli spojrzysz na Przewodnik po Scrumie "Scrum Master zachęca Zespół Scrumowy do ulepszania procesu rozwoju i praktyk w ramach procesu Scrum, aby uczynić go bardziej efektywnym i przyjemnym w kolejnym Sprincie".

W teorii oznacza to, że retrospektywa powinna być centralnym wydarzeniem dla Scrum Mastera, ponieważ głównym celem retrospektywy jest pomoc zespołowi w ciągłym doskonaleniu. Jednakże, w praktyce zespół może nie mieć odpowiedniego poziomu dojrzałości, aby naprawdę korzystać z retrospektywy i dlatego nie dostrzega jej wartości. Z tego powodu osobiście interpretuję stwierdzenie "uczynić zespół bardziej wydajnym" na poziomie abstrakcyjnym jako "zwiększyć poziom dojrzałości zespołu". Jak możesz to zrobić w tym kontekście? Zanim zaczniemy od wskazówek na ten temat, jeszcze jedno wyjaśnienie

Retro jest uważane za wartościowe, gdy ktoś faktycznie stale się doskonali. Wtedy poczucie autonomii, samoorganizacji i własnej skuteczności jest wysokie. Co prowadzi do hipotezy: Postrzegana jakość retrospektyw jest jednym z najlepszych wskaźników poziomu (zwinnej) dojrzałości zespołu. 

Jeśli chcesz zmierzyć poziom dojrzałości zwinnej –, powinieneś użyć jakości retrospektyw jako wskaźnika. Jest to typowa korelacja w czasie pomiędzy "postrzeganą jakością retrospektywy" a "dojrzałością zwinną" zespołu.

Postęp ten jest osiągany w następujący sposób: 

1. Przeprowadzane są pierwsze retrosy, zapisywane są działania. Pojawia się uczucie: wreszcie coś się dzieje! 
2. Środki nie są tak naprawdę wdrażane. Dużo się mówi, ale niewiele się robi. 
3. Po pewnym czasie pojawia się frustracja lub po prostu tak zwane "zmęczenie retro". Teraz pojawia się fenomen tego artykułu: Retrospektywa jest postrzegana jako zbędna. Sam zespół postrzega siebie jako względnie dojrzały i nie widzi żadnych problemów.
4. Ten punkt jest osiągany tylko przez kilka zespołów. Mianowicie, gdy jakość retrosów ponownie wzrasta i ostatecznie prowadzi do zauważalnej poprawy, a tym samym poczucie własnej skuteczności powoli dojrzewa. 

Mam nadzieję, że wskazówki zawarte w tym tekście pomogą Ci zrobić kilka kroków w tym kierunku. Jednakże, mogę również gorąco polecić nasz tekst na temat "7 wskazówek dotyczących dobrych działań", które odgrywają inną rolę w tej kwestii.

1. zrozumieć, dlaczego zespół uważa retrospektywę za niepotrzebną

Jako Scrum Master możesz mieć hipotezę, dlaczego zespół uważa retrospektywę sprintu za niepotrzebną. Sprawdź jednak tę hipotezę. Zapytaj zespół wprost o kontekst.

Często w zespole znajduje się "lider opinii", który ma duży wpływ na zespół. Postaraj się wyodrębnić tę osobę, zrozumieć jej punkt widzenia i, w najlepszym przypadku, wspólnie z nią opracować środki zaradcze (patrz poniżej).

Im lepiej rozumiesz zespół, tym lepiej możesz opracować plan zwiększenia dojrzałości zespołu i wybrać najbardziej odpowiedni z poniższych wskazówek.

2. przeprowadzić retrospektywę

Zasadniczo powinieneś zrobić retrospektywę. Powiedzmy, że zespół potrzebuje więcej czasu, aby osiągnąć cel sprintu –, a godzina kodowania zamiast retrospektywy może być kluczowa. W takim przypadku możesz odłożyć retrospektywę na kilka dni.

Możesz także zmienić charakter retrospektywy, uczynić ją krótszą itd. Ale najlepszym sposobem na pokazanie zespołowi wartości retrospektywy jest przeprowadzenie naprawdę dobrej retrospektywy. Dlatego apeluję: zarezerwuj miejsce w kalendarzu zespołu na retrospektywę.

3. zmierz wartość ROTI

Nie możesz zmienić tego, czego nie mierzysz. Prostym i szybkim nawykiem, który pomoże Ci stale oceniać, jak zespół postrzega retrospektywy, jest mierzenie wyniku ROTI: wartości "zwrotu z zainwestowanego czasu". Po prostu zadaj następujące pytanie po każdej retrospektywie, być może jako check-out: "W skali od 0 do 10, jak dobrze zainwestowano czas w tę retrospektywę?". Zmierz średnią w czasie –, miejmy nadzieję, że wkrótce zobaczysz pozytywny trend!

Średni wynik "zwrotu z inwestycji w czasie" w skali od 0 do 10 na miesiąc w narzędziu Echometer – Czy retrosy są tego warte? Wygląda na to, że tak!

4. Utrzymuj retrospektywę sprintu bardzo krótko.

Więc zespół programistów uważa, że retrospektywa sprintu jest zbędna – co powinieneś teraz zrobić jako Scrum Master?

Jak wspomniałem na początku, zespół prawdopodobnie uważa, że retrospektywa sprintu nie jest konieczna, ponieważ sądzi, że to strata czasu.

Innymi słowy: W ostatnich retrospektywach najwyraźniej "nauczyli się", że ROTI retrospektywy – tj. jakość zainwestowanego czasu, patrz wyżej – jest raczej słaba. Istnieje dość proste podejście, aby to zmienić: po prostu zainwestuj mniej czasu w te same wyniki.

Jest to prawdopodobnie najlepsza wskazówka, jeśli zespół uważa, że retrospektywa sprintu jest niepotrzebna. Powiedz swojemu zespołowi: OK, będziemy trzymać się tego tak krótko, jak to możliwe (przeczytaj więcej w naszym wpisie na blogu "Krótka retrospektywa – Lepiej szybko niż wcale"). 

Ważne: Nie chcesz sygnalizować, że tak pozostanie na zawsze. Twoja wiadomość pozostaje taka sama: Retrospektywy są naprawdę ważne. Prędzej czy później retrospektywy nie będą już tak krótkie.

Ale skracasz retrospektywę (np. z 60 minut do 30 minut), ponieważ w ten sposób zespół uczy się, jak ważne może być zainwestowanie czasu. I pozwalasz, aby długość retrospektywy rosła "organicznie", że tak powiem, poprzez "pociągnięcie" lub "życzenie" zespołu, ponieważ w pewnym momencie będą chcieli więcej czasu na retrospektywę. Jak to robisz? 

Po prostu zadajesz najważniejsze pytanie:

"Dlaczego nie udało nam się ukończyć wszystkich historyjek użytkownika ustalonych dla ostatniej iteracji?".

Doprowadzi to do intensywnych dyskusji i prawdopodobnie pomysłów na działania w krótkim czasie. Może to nawet doprowadzić do dłuższych dyskusji. Zespół już zasygnalizował, że potrzebuje więcej czasu na retrospektywę (oczywiście Twoim zadaniem jest utrzymanie konstruktywnej dyskusji).

Zawsze powinieneś zadawać pytanie, które Twoim zdaniem wywoła dobre przemyślenia lub dyskusje w zespole. I zawsze powinieneś mieć na celu nagranie eksperymentu, który wypróbujesz w następnym sprincie (znanego również jako element działania).

5. zasugeruj również pominięcie innych procedur

Zespół uważa więc, że retrospektywa to strata czasu. Dobrze. Jako Scrum Master, twoim głównym celem nigdy nie powinno być bycie osobą, która wdraża Scrum. Nie, nie chodzi o "Scrum". 

Chodzi o to, aby zespół odnosił sukcesy i dostarczał wartość klientowi i interesariuszom. Scrum ma w tym pomóc. Ale to tylko ramy, zestaw narzędzi (całkiem niezły) wielu możliwych podejść do dostarczania wartości szybko, trwale i z wysoką jakością.

Jeśli więc zespół jest niezadowolony z retrospektyw, możesz podkreślić, że patrzysz na Scruma z opisanej właśnie perspektywy. A następnie dodajesz, że uważasz, że niektóre z innych rutyn, które masz, są w rzeczywistości mniej ważne niż retrospektywa. 

Retrospektywa jest motorem ciągłego doskonalenia. Ma na celu pomóc członkom zespołu dowiedzieć się, co zadziałało dobrze, a co nie. Jeśli pominiesz tę część ciągłej pętli, ryzykujesz zablokowanie pętli ciągłego doskonalenia.

 

Co by się stało, gdybyś na przykład pominął kilka dzienników? Czy wiesz, co by się stało? Może nie będzie to miało żadnego wpływu – idealny, wtedy możesz zachować to samo i zaoszczędzić czas. 

Z drugiej strony może to również prowadzić do gorszej komunikacji w zespole. W związku z tym zespół popełnia błędy. W końcu pojawi się organiczna potrzeba większej komunikacji, którą zauważysz vs. w retrospektywie. Tym razem jednak zwinna ceremonia nie jest wprowadzana pod twoim naciskiem, ale z powodu "bólu" zespołu. W rezultacie w zespole będzie znacznie więcej akceptacji dla tej ceremonii.

6. przyjrzyj się wcześniejszym retrospektywom i pokaż ich wartość.

Jednym z podejść, które może uzupełniać inne podejścia, jest przyjrzenie się "historii retrospektyw" zespołu w dłuższym okresie czasu. Warunkiem wstępnym jest to, że niektóre z ostatnich retrospektyw zakończyły się sukcesem.

Na przykład, patrzysz na retrospektywę sprzed roku i zdajesz sobie sprawę, jak trudne były te wyzwania w zeszłym roku. A potem zdajesz sobie sprawę, że o wiele łatwiej byłoby rozwiązać te same wyzwania dzisiaj, gdybyś miał całą wiedzę i doświadczenie, które zdobyłeś.

Innymi słowy: Zdajesz sobie sprawę, jak bardzo poprawiłeś się w międzyczasie. Może to podejście "ciągłego doskonalenia" w końcu zadziała?! A retrospektywy rzeczywiście mogły odegrać w tym dużą rolę. Używane prawidłowo, z pewnością mogą doprowadzić do momentu "aha" w zespole.

Ponadto możesz również spojrzeć na wartość ROTI (zwrot z inwestycji czasu) ostatniej retrospektywy (patrz wyżej): Jeśli możesz udowodnić, że retrospektywa ma ROTI od 8 do 10, czas jest oczywiście dobrze zainwestowany. Nasze narzędzie do retrospektyw Echometer, na przykład, sprawdza ROTI po każdej retrospektywie, a tym samym daje Ci regularny wskaźnik odpowiedniej wydajności. Wydajność ciebie jako Scrum Mastera.