Celem tego wydarzenia jest znalezienie co najmniej jednej rzeczy do poprawy w kwestii przepływu informacji, komunikacji. Dzięki temu proces tworzenia produktu jest zmieniany względem aktualnych potrzeb i jest osiągana większa wydajność dzięki poprawom.  

TimeBox

Jest to spotkanie, które powinno zająć najmniej czasu (nie licząc Daily) – maksymalnie 3 godziny dla Sprintu miesięcznego. Jeżeli praktyka wskazuje, że długości przebiegów to zazwyczaj 2/3 tygodnie – całe spotkanie powinno zająć max 2 godziny. 

W przypadku gdy retrospektywa zajmuje więcej niż 2 godziny i nie ma podjętych decyzji oznacza, że zespół ma spore dysfunkcje a Scrum Master potrzebuje pomocy.

To nie jest czas do narzekania! 

Przed rozpoczęciem spotkania Scrum Master powinien przypomnieć cel spotkania – znalezienie co najmniej jednego usprawnienia, które pomoże w realizacji Przyrostu. W tej sytuacji należy położyć nacisk na to – aby uniknąć narzekania i dyskusji. W zależności od liczby członków zespołu, każdy powinien mieć możliwość wypowiedzenia się przez 5 do max 10 minut bez przerywania ze strony innych osób. 

Przebieg retrospektywy 

1. Ustalenie czasu trwania spotkania w zależności od długości sprintu 
2. Podsumowanie poprzedniej retrospektywy 
3. Czas pierwszych wypowiedzi 
4. Dyskusja nad najważniejszymi problemami zespołu 
5. Propozycja rozwiązania 

Pierwsza część spotkania 

Tutaj członkowie Scrum Team przekazują wszystkie dobre i złe kwestie jakie były w trakcie sprintu. Dobrym rozwiązaniem jest wypisywanie ich na karteczkach i przyklejanie do tablicy. Wymaga to skonkretyzowania problemu i jest bardzo zwięzły opis. Te działania powinny zająć nie więcej niż 30% spotkania. 

Następnie Scrum Master powinien zdiagnozować najczęściej poruszane problemy i je podsumować. Teraz “na tapecie” powinno być max 3 najważniejsze sprawy do poprawy. 

Druga cześć spotkania 

Zespół dyskutuje jak może poprawić problem znajdując rozwiązanie. W tej części spotkania musimy zapomnieć o pozostałych kwestiach -> w Scrum’ie skupiamy się na pracy zespołowej i największe znaczenie mają problemu zespołu.  

Nie oznacza to, że można zignorować czyjeś pojedyncze problemy. Scrum Master powinien wrócić do tematu innego dnia i rozwiązać sprawy, które mogą być ważne tylko dla pojedynczych osób. Jak np.: nieergonomiczne stanowisko pracy, stary sprzęt czy konflikty 1:1. 

Decyzja 

Spotkanie musi kończyć się decyzją, którą każdy akceptuje – o tym jak sprawnie podjąć decyzje na spotkaniu opisuje tutaj: https://www.zeromski.me/komunikacja-w-scrum-ale-jak-czesc-1-podstawy/ 

Uwaga! 

Podczas retrospektywy mogą ujawnić się konflikty w które uwikłane są poszczególne osoby z zespołu, lecz ta sytuacja wpływa na pracę wszystkich. W takiej sytuacji Scrum Master powinien podjąć się roli mediatora i rozwiązać konflikt na dwa sposoby:  

1. przy udziale zespołu 
2. na osobności 

Ja rekomenduję załatwianie spraw personalnych bez udziału zespołu, w odpowiednim momencie. Oznacza to, że spotkanie nie może być podjęte, kiedy te osoby są w stresie. Warto też zapoznać się ze sprawą wcześniej i być przygotowanym. Zespół Scrum powinien takie kwestie rozwiązywać wewnętrznie bez udziału osób z zewnątrz.

Podsumowanie 

Retrospektywa może być bardzo wydajnym narzędziem w ciągłym ulepszaniu procesu tworzenia oprogramowania – należy jedynie przeprowadzić to spotkanie sprawnie i konkretnie. Nie można też pomijać kwestii ważnych dla poszczególnych osób. Dobry zespół można poznać po tym, że sobie ufa a każda retrospektywa to element doskonalenia pracy.