Sprint Retrospective - częste błędy w czasie Retrospekcji

Sprint Retrospective to wydarzenie kończące każdy Sprint. A zarazem jedno z najtrudniejszych spotkań Scrum Team. Najczęstsze błędy pojawiające się podczas Sprint Retrospective wiążą się z unikaniem rozmów dotyczących drażliwych kwestii, a także brakiem konkretnych zobowiązań prowadzących do rozwiązania już zdiagnozowanych problemów.

Sprint Retrospective – omówione zagadnienia:

Wprowadzenie
Niewystarczająca transparentność
Skupienie się na jednorazowych problemach lub sukcesach
Nadobecność Product Ownera
Problemy z samozarządzaniem
Zbyt wiele zobowiązań
Podsumowanie

Wprowadzenie

Błędy w Sprint Retrospective zdarzają się niestety bardzo często. To jedno bowiem z najtrudniejszych spotkań, którego skuteczne przeprowadzanie wymaga od zespołu dużej dojrzałości. Dlatego warto przyjrzeć się problemom najczęściej pojawiającym się w innych zespołach, aby łatwiej dostrzec ich symptomy podczas prowadzenia Sprint Retrospective w swoim Scrum Team.

Common mistakes during a Sprint Retrospective

Czym jest Sprint Retrospective dowiesz się z naszego poprzedniego wpisu.

Niewystarczająca transparentność

Według Przewodnika po Scrumie każdy z członków Scrum Team jest zobowiązany do szczerości i odważnego wyrażenia wątpliwości, a także do zgłaszania swoich uwag podczas Sprint Retrospective. Jednak w praktyce zobowiązanie do transparentności jest bardzo wymagające. Przez to często członkowie Scrum Team starają się je omijać.

Jednym z trudnych do dostrzeżenia i rozwiązania problemów jest unikanie dyskusji nad zaobserwowanymi niedociągnięciami w pracy Scrum Team. Może to jednak w dłuższej perspektywie doprowadzić do znacznie poważniejszych problemów.

Zadaniem Scrum Mastera jest więc uważne obserwowanie sytuacji w zespole, a także zachęcanie wszystkich jego członków do aktywności już od samego początku Sprint Retrospective.

Skupienie się na jednorazowych problemach lub sukcesach

Kolejnym problemem, który może pojawiać się podczas Sprint Retrospective jest przywiązywanie niewystarczającej wagi do cyklicznych i powtarzalnych zachowań zespołowych, oraz ich wpływu na efektywność zespołu.

Zawsze warto pogratulować członkom Scrum Team, jeśli odnieśli wyjątkowy sukces. Jednak Sprint Review nie powinien być poświęcony jego świętowaniu. Tak samo rzecz się ma z porażkami. Jeśli coś się nie udało ze względów losowych lub zdiagnozowanego już błędu, nie warto nadmiernie analizować tego zdarzenia podczas Sprint Review.

Zdarza się jednak, że zespół poświęca dużą część Sprint Retrospective takim wydarzeniom. Celem Sprint Retrospective jest jednak szukanie sposobów usprawniania codziennej pracy zespołu. Dlatego spotkanie nie powinno obracać się wokół jednorazowych sukcesów lub problemów, które z dużym prawdopodobieństwem więcej się nie powtórzą.

Nadobecność Product Ownera

W wielu organizacjach pozycja Product Owner jest utożsamiana z pozycją Product Managera. Jest on wtedy często uważany za przełożonego Scrum Team. Z tego powodu zdarza się, że Zespół Developerski nie chce rozmawiać w jego obecności na temat problemów z pracą zespołową.

Dlatego tak ważną kwestią jest budowanie wzajemnego zaufania pomiędzy Zespołem Developerskim i Product Ownerem. Jednak proces budowania zaufania jest trudny i długotrwały. Dlatego czasem warto, by Product Owner zrezygnował z udziału w całości lub części Sprint Retrospective, aby zostawić reszcie zespołu przestrzeń na swobodną dyskusję.

Problemy z samozarządzaniem

Samozarządzanie oznacza, że członkowie Scrum Team samodzielnie podejmują decyzję o tym, kto z nich będzie wykonywał określone zadania, kiedy i jak. Podczas Sprint Retrospective zespół dyskutuje na temat ludzi, ich interakcji i praktyk zespołowych. Decyduje więc, jakie problemy należy rozwiązać w najbliższym Sprincie, w jaki sposób to zrobić i kto będzie odpowiedzialny za podjęcie działania.

Jeśli w samozarządzającym się zespole pojawiają się poważniejsze problemy, w Scrum Team może pojawić się pokusa zrzeczenia się odpowiedzialności.

Członkowie zespołu nie chcą brać udziału w dyskusji i starają się zepchnąć na kogoś odpowiedzialność za zarządzanie. Aby temu zapobiec, ogromnie ważna jest regularność omawiania nawet niewielkich problemów, aby zapobiec ich nagromadzeniu.

Zbyt wiele zobowiązań

Aktywny Scrum Team działający zgodnie z trzema filarami empiryzmu, przejrzystością, inspekcją i adaptacją, może napotkać na problem podejmowania zbyt wielu zobowiązań naraz.

Jeśli zobowiązań podjętych przez Scrum Team podczas Sprint Retrospective jest zbyt wiele, istnieje spore ryzyko, że:

żadne zobowiązanie nie zostanie zrealizowane należycie
niektóre ze zobowiązań nie zostaną zrealizowane wcale
wprowadzone zmiany nie będą stałe

Dlatego dobrą praktyką jest podejmowanie nie więcej niż czterech usprawnień w każdym Sprincie. Pozwala to na stopniowe, ale skuteczne poprawianie efektywności zespołu.

Podsumowanie

Ponieważ Sprint Retrospective jest wydarzeniem wymagającym, podczas jego prowadzenia często pojawiają się problemy. Aby łatwiej sobie z nimi poradzić, warto zwrócić uwagę na te, które pojawiają się najczęściej. Są to:

niewystarczająca transparentność – gdy członkowie Scrum Team nie radzą sobie ze szczerością w trudniejszych sytuacjach zespołowych
skupienie się na jednorazowych problemach lub sukcesach– gdy członkowie Scrum Team skupiają się na omawianiu sukcesów i porażek, zamiast dyskutować nad długoterminową efektywnością pracy zespołu
nadobecność Product Ownera – gdy członkowie Scrum Team traktują Product Ownera z ograniczonym zaufaniem, jak osobę spoza zespołu lub przełożonego
problemy z samozarządzaniem – gdy członkowie Scrum Team próbują zrzec się odpowiedzialności za problemy i podejmowanie decyzji.

Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autor: Karolina Berecka
Karolina, jako project menadżerka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przepływu pracy i optymalizacji procesów. Jej umiejętności organizacyjne i zdolność do pracy pod presją czasu sprawiają, że jest najlepszą osobą do zamieniania skomplikowanych projektów w rzeczywistość.

Zobacz wszystkie posty