Ciągle ulepszanie jest obowiązkowe dla zespołów zwinnych, a Retro jest formalną i regularną, chociaż nie jedyną, okazją do wcielenia tej praktyki w życie. Nie brakuje jednak zespołów, którzy nie chcą tego wydarzenia przeprowadzać. Niestety, samo to, że zespół przeprowadza Retrospektywę, jeszcze nie gwarantuje, że czerpie z niej wszystkie możliwe korzyści. Dlatego dziś przedstawimy wam metryki, które pomagają usprawnić Retro.
Proste sposoby na Retrospektywę
W Internecie można znaleźć mnóstwo proponowanych formatów Retrospektywy. Bardzo znane są takie techniki jak Starfish, Mad/Glad/Sad, 4 Ls, Sailboat, Lean Coffee, 5 Whys oraz wiele podobnych. Wszystkie te sposoby w gruncie rzeczy są takie same: każdy uczestnik zespołu wypowiada się o czymś dobrym i o czymś złym, co zdarzyło się w poprzednim Sprincie. Czy jest ten format skuteczny?
Z mojego doświadczenia, regularne przeprowadzanie takich Retro jest o wiele lepsze niż brak tego wydarzenia. Wspomniane sposoby pomagają identyfikować niektóre problemy – i w miarę możliwości je rozwiązywać. Sprzyjają też budowaniu środowiska otwartości oraz zaufania, bo członkowie wiedzą, że mogą powiedzieć o tym, co ich boli w pracy – i widzą, że na te wypowiedzi zwraca się uwagę. Taki format Retrospektywy nie jest zły, lecz niewystarczający. Dlaczego?
Takie Retro niekoniecznie będzie oparte o fakty. To, co członkowie zespołu wypowiadają, będzie subiektywne. Mogą mówić o niektórych problemach, nie wspominając o tych bardziej niewygodnych. I mogą to robić całkowicie nieświadomie. Również my nie będziemy mieli obiektywnych wskaźników na temat tego, jak bardzo te Retro sprzyjają ulepszeniu jakości Produktu oraz efektywności pracy zespołu – i czy sprzyjają w ogóle.
Stosowanie Empiryzmu podczas Retro
Pamiętajmy, że kluczowym aspektem Zwinności jest Empiryzm – podejmowanie decyzji w oparciu na dane z przeszłości. Musimy więc te dane zbierać – i wykorzystywać. What you can measure, you can manage. Otóż spójrzmy na wskaźniki, które warto wykorzystać podczas Retro, aby opierało się ono nie tylko na opiniach, ale również na faktach:
1) Dowieziona Wartość. Każdy element Backlogu powinien zawierać dane odnośnie jego wartości biznesowej. Podsumowując te dane dla każdego ukończonego w Sprincie elementu, dostaniemy właśnie Dowiezioną Wartość per Sprint. Jeżeli jest ona niska, powinniśmy zastanowić się czy dobrze prowadzimy priorytetyzację.
2) Lead Time oraz Cycle Time. Pierwszy wskazuje, ile czasu mija od stwarzania elementu backlogu do jego ukończenia zgodnie z Definition of Done. Drugi wskazuje, ile mija od rozpoczęcia pracy nad danym elementem backlogu, aż do jej ukończenia (czyli jak długi jest cykl naszego Workflow). Oprócz tego, że te dane same w sobie mogą nas naprowadzić na przestrzeń do ulepszenia, duża wartość będzie też w zestawieniu tych wskaźników per Sprint. Jeżeli one się zwiększają lub są niestabilne – trzeba dowiedzieć się dlaczego.
3) Zaplanowany, a wykonany nakład pracy. Ile Story Pointów zaplanowaliśmy na Sprint, a ile rzeczywiście udało się zrealizować? Jeżeli z upływem czasu różnica pomiędzy tymi dwoma wskaźnikami maleje, to mamy dowód, że estymacje oraz planowanie zespołu są coraz lepsze. Warto również porównywać ilość wziętych do Sprintu, a zrealizowanych elementów backlogu.
4) Cel Sprintu – czy został osiągnięty, a jeśli nie, to dlaczego? Posiadanie takich danych np. za 20 ostatnich Sprintów da nam obiektywny wgląd w to, jak dobrze idzie naszemu zespołowi zbliżanie się do Celu Produktu i czy nasze estymacje odnośnie tego, kiedy on zostanie osiągnięty są adekwatne.
5) Ilość Wydań – liczymy udane, nieudane oraz awaryjne Wydania.
6) Wskaźniki jakości Produktu. Tutaj ważny jest rodzaj Produktu. Jeśli na przykład jest to oprogramowanie, wskaźnikami jakości mogą być dane z narzędzia typu Sonar: pokrycie kodu przez testy, ilość bugów oraz code smells. Warto liczyć również bugi zgłaszane przez użytkowników. Poziom jakości naszego produktu powinien rosnąć ze Sprintu na Sprint. A na pewno nie powinien się pogarszać.
Najlepszy format Retrospektywy
Tym najbardziej skutecznym formatem Retro będzie połączenie tych podejść. W pierwszej części, sprawdzamy i omawiamy nasze wskaźniki. Za to w drugiej dajemy członkom zespołu możliwość wypowiedzenia się o czymś bardziej subiektywnym, korzystając ze wspomnianych na początku artykułu technik.
Obie części naszej Retrospektywy (empiryczna i subiektywna) dadzą nam jakieś Action Points, których wykonanie zespół powinien podzielić między sobą. W trzeciej części warto również zrobić przegląd listy akcji z poprzedniego Retro. Pamiętajmy, że nawet najlepsza Retrospektywa będzie bezużyteczna, jeśli na jej podstawie nie podejmiemy odpowiednich działań. Inspekcja bez Adaptacji nie ma sensu.
Mam nadzieję, że ten krótki i praktyczny post pomoże Waszym zespołom ulepszyć swoje Retrospektywy. Jeżeli znacie inne wskaźniki, które warto dodać do tej listy – zapraszamy do dzielenia się nimi w komentarzach. A my przypominamy, że jeszcze ciekawsze porady rozsyłamy do subskrybentów naszej listy mailingowej. Polecamy zarówno używanie mierników na Retro, jak i naszą listę.
