Retrospektywa jest wydarzeniem kończącym Sprint. Umożliwia wykorzystanie empiryzmu do ulepszania procesu wytwórczego. Głównym celem retrospektywy jest inspekcja sposobu pracy, nastawiona na zidentyfikowanie usprawnień zwiększających jakość i efektywność Zespołu.
O Retrospektywie słów parę…
[1] Retrospektywa jest wydarzeniem, które kończy każdy Sprint. Głównym celem tego wydarzenia jest planowanie sposobów na podnoszenie dostarczanej jakości oraz efektywności Zespołu.
Retrospektywa jest wspierana przez filary Scruma – przejrzystość, inspekcję i adaptację. Zespół dokonuje całościowej inspekcji procesu wytwórczego, z uwzględnieniem osób, interakcji między nimi, procesów, wykorzystywanych narzędzi i Definicji Ukończenia. Punktem wyjścia do analizy jest identyfikacja tego co poszło dobrze, a gdzie Zespół natknął się na trudności w trakcie trwania Sprintu. Szczere rozmowy powinny być ukierunkowane na znalezienie wspólnego zrozumienia sytuacji oraz sposobu na usprawnienie.
W Retrospektywie bierze udział cały Zespół Scrumowy, czyli Developerzy, Product Owner i Scrum Master.
Retrospektywa trwa maksymalnie 3 godziny dla miesięcznego Sprintu. Dla krótszych Sprintów wydarzenie to będzie krótsze.
Retrospektywa, a Wartości Scruma
Aby Retrospektywa przynosiła pożądane rezultaty, każdy uczestnik spotkania powinien czuć się bezpiecznie. Spotkanie to powinno być bezpieczną przestrzenią do otwartego mówienia o swoich przemyśleniach dla każdego członka Zespołu, bez obawy przed osądami przez innych. Budowanie takiej kultury jest możliwe przy wykorzystaniu Wartości Scruma (o których pisałam tutaj).
Wartości Scruma pozytywnie wpływają na przebieg Retrospektywy [2]. Gdy wszyscy są zaangażowani w proces Retrospektywy i biorą udział w zaproponowanych aktywnościach, skupiając się na analizie współpracy kończącego się Sprintu, to jesteśmy w stanie wypracować wiele kreatywnych usprawnień. Jeżeli do tego dodamy odwagę do otwartego mówienia o rzeczach trudnych (np. o konfliktach, wyzwaniach, niepowodzeniach) oraz wzajemny szacunek, to mamy podwaliny do uzyskiwania wspaniałych rezultatów Retrospektyw.
Dlaczego Retrospektywa jest konieczna?
W niektórych Zespołach Retrospektywę traktuje się jako wydarzenie opcjonalne. Jest to duży błąd, który uniemożliwia uzyskania maksymalnych korzyści z praktykowania „Scruma” (bez Retro to co Zespół robi nie jest Scrumem…).
[3] Retrospektywa jest nastawiona na ciągłe usprawnianie Zespołu. Jeżeli jako Zespół stoimy w miejscu, to tracimy szanse na coraz efektywniejsze dostarczanie lepszej jakości Produktu. Zespoły, które omijają Retro tracą okazję na usuwanie napotykanych przeszkód. Tracą też możliwość nauki jak wyciągać wnioski i rozwiązywać problemy / konflikty w praktyce, a umiejętności te wspierają samoorganizację.
Zespoły praktykujące Retro mają lepsze morale, ponieważ mają wpływ na sposób w jaki razem pracują [2]. Szczera Retrospektywa wspierana przez Wartości Scruma buduje zaufanie, a zatem dobre relacje w Zespole.
Akcje z Retrospektywy
Najważniejsze wnioski z Retrospektywy, wraz z planem ich realizacji, powinny znaleźć się w Product Backlogu, by móc uwzględnić je w nadchodzącym Sprincie [2]. Tylko dzięki sukcesywnemu realizowaniu zidentyfikowanych usprawnień Zespół będzie podnosił swoją efektywność. Dzięki poprawie współpracy będzie w stanie dostarczać lepszej jakości i bardziej wartościowe Produkty.
Dobre akcje z Retro spełniają model CAT: Concrete – konkretne, Attainable – osiągalne, Timely – określone w czasie [6]. Są sformułowane w taki sposób, bo jasno określały jakie dokładnie działania należy podjąć i jaki rezultat chcemy osiągnąć.
Zamiast wpisać „Lepiej definiujemy Kryteria Akceptacji w PBI”, spróbujcie dokładnie określić co to znaczy. Dobra akcje może być określona tak „”.
Podczas Retrospektywy sprawdzamy również, czy udało się zrealizować akcje zaplanowane na poprzedni Sprint.
Ewolucja Definicji Ukończenia
Jednym z elementów podlegających inspekcji podczas Retrospektywy, od którego zależy jakość dostarczanych rozwiązań, jest Definicja Ukończenia (Definition of Done) [5]. DoD jest zbiorem warunków, które musi spełniać każdy Inkrement, by mógł zostać uznany jako skończony i gotowy do wdrożenia. W praktyce definicja ta ewoluuje z biegiem czasu i pracy nad Produktem. Dzięki powracającej rozmowie o DoD podczas Retrospektyw, zapewniamy, iż standardy jakościowe są stale monitorowane i usprawnianie, jeżeli okaże się to konieczne.
Product Owner na Retrospektywie
Najważniejsza dla Product Ownera w kontekście Retrospektywy powinna być jego obecność i czynny udział w spotkaniu jako równoprawnego członek Zespołu. Product Ownerowi, jako osobie odpowiedzialnej za dostarczanie wartości Produktu, powinno szczególnie zależeć by w kooperacji z całym Zespołem zwiększać jego efektywność (lepsze i szybsze dostarczanie Przyrostów) oraz jakość tworzonych rozwiązań. Będąc obecnym na Retro może on wnosić dodatkową, inną niż developerska, perspektywę w dyskusji.
Zdarza się czasami, że Product Owner jest wysoko postawioną personą w strukturze firmy. Obecność takiej osoby, może mieć niekiedy niekorzystny wpływ na przejrzystość spotkania [7]. Pozostali członkowie Zespołu obawiają się szczerze wypowiadać swoich opinii, ze strachu przed popełnieniem błędu lub urażeniem PO. Brak poczucia bezpieczeństwa poszczególnych członków Zespołu zaburza przejrzystość spotkania, co przekłada się na niemiarodajną inspekcję, a następnie podejmowane adaptacje. Takiego Product Ownera można by porównać do herbaty stojącej obok termostatu z przykładu obrazującego empiryzm.
Transparentna komunikację jest konieczne by Zespół mógł się udoskonalać. Sytuację, w której Product Owner zaburza szczerość w Zespole, należy próbować naprawić. Scrum Master powinien umieć zidentyfikować problem, a następie współpracować z Product Ownerem by wypracować plan ukierunkowany na wzrost zaufania Developerów do PO. Przejrzystość moim zdaniem przyjdzie wraz z zaufaniem. A w budowaniu relacji bazującej na zaufaniu pomocne są Wartości Scruma.
Rozmowy podczas Retrospektywy mogą dotyczyć każdego elementu procesu wytwórczego. W wyniku tych rozmów mogą powstawać akcje dotyczące każdego aspektu pracy Product Ownera.
Rzućmy okiem na hipotetyczne sytuacje:
Zarządzanie Product Backlogiem
Zespół wykonał pewien PBI. Po realizacji zadania okazało się, że nie spełniał on założeń, o których wiedział Product Owner. Wynikało to z braku jasnych wytycznych w Kryteriach Akceptacji (ang. Acceptance Criteria, AC) danego PBI. Wnioskiem z dyskusji była zmiana procesu omawiania PBI w trakcie Refinementów [2], tak by Developerzy razem z PO czynnie brali udział w tworzeniu AC.
Współpraca z Interesariuszami
W trakcie Sprintu zostało wykonane wdrożenie, które zaskoczyło pewnego Interesariusza, generując tym dużo stresu dla Zespołu i Działu Wsparcia Technicznego. Interesariusz ten nie brał zazwyczaj udziału w Sprint Review, i dlatego zaskoczyła go informacja o wdrożeniu. Na Retro Product Owner wraz ze Scrum Masterem zobowiązali się do wykonania mapy Stakeholderów, by uniknąć w przyszłości sytuacji, w których kluczowy Interesariusz zostaje pominięty w komunikacji. PO zadba o to by zapraszać odpowiednich Interesariuszy na Sprint Review.
Współpraca na poziomie PO – Developerzy
Developerzy przez długi czas Sprintu mieli do podjęcia decyzję produktową, w którą zaangażowany powinien być Product Owner. Niestety PO był niedostępny z powodu wielu spotkań w swoim kalendarzu. W duchu najlepszych intencji Developerzy sami podjęli decyzję, z którą finalnie nie zgadzał się Product Owner. Przez tę sytuację Cel Sprintu nie został osiągnięty. Product Owner i Developerzy ustalili, że PO będzie dostępny dla Zespołu w określonych godzinach dnia, na które definiuje w kalendarzu stałe, cykliczne spotkanie.
Zarządzania nieprzewidzianymi zadaniami
W trakcie Sprintu niespodziewanie pojawił się błąd na środowisku produkcyjnym. Mimo, że błąd nie był krytyczny to Product Owner poprosił Zespół o zajęcie się problemem. Developerzy poświęcili dużo czasu na jego rozwiązanie, przez co nie udało się osiągnąć Celu Sprintu. Zespół zobowiązał się do ustalenia wspólnej „skali krytyczności” problemów i odpowiednich działań w zależności od poziomu danego zdarzenia. Dzięki temu łatwiej będzie można podejmować decyzje o tym, jak szybko należy zająć się danym problemem.
Wymienione przykłady to jedynie kilka z wielu, jakie można przedstawić. Mam nadzieję, że przekonają one Product Ownerów, którzy omijają Retro szerokim łukiem, jak duże jest znaczenie tego wydarzenia.
Podsumowanie
Proces Retrospektywy jest istotnym i nieodłącznym elementem Scruma. Dzięki niemu po zakończeniu każdego Sprintu możemy analizować, jak wygląda współpraca w Zespole pod kątem efektywności i jakości dostarczanego Produktu, oraz planować konkretne czynności usprawniające. Dzięki Retrospektywie lepiej się pracuje, uczymy się na błędach, a Zespół wzrasta. Budujemy wartościowe relacje międzyludzkie, które sprzyjają tworzeniu bezpiecznej przestrzeni bazującej na zaufaniu.
bibliografia
[1] Przewodnik po Scrumie; https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf
[2] How to get the most from your Sprint Retrospective Event; https://www.scrum.org/resources/blog/how-get-most-your-sprint-retrospective-event
[3] Five Common Scrum Mistakes That Will Ruin Your Team’s Progress; https://www.scrum.org/resources/blog/five-common-scrum-mistakes-will-ruin-your-teams-progress
[4] The Importance of Transparency during the Sprint Retrospective (04); https://www.scrum.org/resources/blog/importance-transparency-during-sprint-retrospective-04
[5] What does Done really mean for your Sprint Retrospective? (70); https://www.scrum.org/resources/blog/what-does-done-really-mean-your-sprint-retrospective-70
[6] Retrospectives: Making Action Items that are cats; https://www.scrum.org/resources/blog/retrospectives-making-action-items-are-cats
[7] Do your Retrospectives Suck due to a Powerful Product Owner?; https://www.scrum.org/resources/blog/do-your-retrospectives-suck-due-powerful-product-owner