Czy zespół Scrum potrzebuje retrospektywy w każdym Sprincie?
Na koniec każdego cyklu Sprintu powinna odbyć się retrospektywa. Mimo to prawie na każdym moim Certified Scrum Master Training pada pytanie, czy zespół naprawdę musi przeprowadzać retrospektywę w każdym Sprincie.
Tok myślenia jest zazwyczaj mniej więcej taki:
Nasz zespół jest tak dobry, że rzadko znajdujemy możliwości poprawy, dlatego chcemy z tym skończyć.
Retrospektywy są dla nas nudne, dlatego chcemy z tym skończyć.
Jesteśmy zbyt zajęci (albo retrospektywy trwają za długo), dlatego chcemy z tym skończyć.
Po prostu nie lubimy retrospektyw, dlatego chcemy z tym skończyć.
W tym wpisie na blogu odniosę się do każdego z tych argumentów i wyjaśnię, dlaczego i tak należy przeprowadzać retrospektywę w każdym Sprincie. Na końcu wyjaśnię, że być może – naprawdę tylko być może – nie jest konieczne przeprowadzanie retrospektywy w każdym Sprincie. (Tego się nie spodziewałeś, prawda? Czytaj dalej…)
Zespół jest zbyt dobry na retrospektywy
Twój zespół nie jest tak dobry, żeby nie mógł się jeszcze poprawić. Znam zespoły, które od dziesięciu lat pracują ze Scrumem i co dwa tygodnie przeprowadzają retrospektywę. Nawet te zespoły ciągle znajdują nowe możliwości poprawy. Jest naprawdę skrajnie mało prawdopodobne, żeby Twój zespół był tak dobry, że nie ma niczego, co można by jeszcze ulepszyć lub co warto by zmienić.
Retrospektywy są zbyt nudne
Nikt nie twierdził, że retrospektywy mają być tak ekscytujące jak najnowszy hollywoodzki blockbuster. Jest jednak kilka rzeczy, które możesz zrobić, żeby je nieco ożywić.
Możesz na przykład tchnąć w nie świeżego ducha, prosząc Scrum Mastera z innego zespołu o poprowadzenie Twojej retrospektywy. Inny styl może być bardzo pomocny. (Pamiętaj, żeby się odwzajemnić.) Możesz też zmienić miejsce. Możesz na przykład przeprowadzić retrospektywę na zewnątrz, być może nawet podczas spaceru.
Wypróbuj inne formy spotkania. Wiele zespołów wyrobiło sobie nawyk regularnego próbowania nowych metod na retrospektywy. (I nie, „zniesienie retrospektyw" nie jest jedną z nich.)
Zespół jest zbyt zajęty na retrospektywy
Zespół, który twierdzi, że ma za dużo do zrobienia i dlatego nie może poświęcić czasu na usprawnienia, myśli bardzo krótkoterminowo.
Stephen Covey w swojej książce 7 nawyków skutecznego działania (w oryginale: Seven Habits of Highly Effective People) porównuje to do drwala, który przez wiele dni próbuje ściąć drzewo piłą. W pewnym momencie piła staje się tępa. Z taką krótkowzroczną perspektywą drwal nigdy nie zrobi przerwy, żeby naostrzyć piłę.
Zespół Scrum, który myśli równie krótkoterminowo, nigdy nie poświęci nawet pół godziny swojego czasu pracy na szukanie możliwości usprawnienia. Zamiast tego przecenia tę odrobinę kodu, który mógłby wyprodukować w ciągu tych 30 minut.
Zespół nie lubi retrospektyw
To jest w pewnym sensie inny sposób powiedzenia, że retrospektywy są nudne. Odniosę się do tego jednak osobno, bo może chodzić o coś więcej niż tylko nudę czy rutynę. Niektórzy członkowie zespołu po prostu ich nie lubią.
Szkoda dla tych członków zespołu, bo każdy w zespole powinien pracować profesjonalnie. A profesjonalista wykonuje wszystkie części swojej pracy, nie tylko te, które lubi.
Kiedy piszę ten wpis na blogu, będę go później redagować, żeby go ulepszyć. To nie jest szczególnie przyjemne. Potem będę musiał go jeszcze raz przejrzeć. To naprawdę nie jest przyjemne. Potem daję komuś innemu tekst do przeczytania i zastanawiam się, czy akceptuję zmiany, czy nie. To nie jest przyjemne.
Nie każda część naszej pracy sprawia nam zawsze radość. Jeśli niektórzy członkowie zespołu nie lubią retrospektyw, ale pomagają one zespołowi stawać się lepszym, to zespół powinien je przeprowadzać.
Kiedy dopuszczalne jest, żeby nie przeprowadzać retrospektywy w każdym Sprincie
Wspomniałem na początku, że wyjaśnię też, kiedy dopuszczalne jest nieprzeprowadzanie retrospektywy w każdym Sprincie. Kiedy więc tak jest?
Kiedy Twój zespół:
- jest naprawdę dobry.
- stara się, żeby retrospektywy nie były nudne.
- nie jest zbyt zajęty, żeby dbać o długoterminowe usprawnienia.
rozumie też wartość prac, które nie sprawiają mu aż takiej radości.
… i gdy pracuje się z krótkimi Sprintami. Wtedy powiedziałbym, że dopuszczalne jest nieprzeprowadzanie retrospektywy tak często.
A oto powód: Zasadniczo zasady Scrum mówią, że Sprint nie powinien trwać dłużej niż cztery tygodnie. Zespół, który naprawdę nie chce przeprowadzać retrospektyw, mógłby po prostu pracować z czterotygodniowymi Sprintami.
Załóżmy, że zespół z dobrych powodów zdecydował się na jednotygodniowe Sprinty. Ale ten zespół uważa retrospektywy za coś tak okropnego, że przechodzi na czterotygodniowe Sprinty tylko po to, żeby nie musieć przeprowadzać retrospektywy tak często.
Byłoby to złą decyzją, chyba że zmiana miałaby inne sensowne zalety niż po prostu rzadsze odbywanie retrospektyw.
Dlatego dobry Scrum Master powinien naprawdę zachęcać zespół do przeprowadzania retrospektywy w każdym Sprincie i obalać cztery wspomniane wyżej argumenty. Jednak w kilku wyjątkowych przypadkach Scrum Master powinien być też otwarty na to, że zespół przeprowadza retrospektywę tylko co drugi Sprint, jeśli pracuje z jedno- lub dwutygodniowymi Sprintami.
Chcę podkreślić, że zawsze staram się to odradzać zespołom. Zawsze próbuję przekonać zespoły do przeprowadzania retrospektywy w każdym pojedynczym Sprincie. Jeśli jednak zespół naprawdę osiągnął bardzo wysoki poziom wydajności i pracuje z krótkimi Sprintami (np. jednego tygodnia), jestem gotowy zaakceptować ich argumenty.
W takim przypadku pozwalam im przeprowadzać retrospektywę co dwa Sprinty. I zazwyczaj to wciąż jest częściej niż w przypadku zespołów pracujących z czterotygodniowymi retrospektywami.
