Znaczna część osób, które znam narzeka na to, że w SCRUMowym Sprincie za dużo czasu jest przeznaczane na spotkania. Często spotykam się ze stwierdzeniem, że Retrospektywe (lub jak kto woli Retrospekcje) należałoby usunąć z kalendarza spotkań. Czy warto?
Ostatnio miałem przyjemność uczestniczyć w szkoleniu nt. SCRUMa. Bardzo spodobała mi się zabawa z długopisami (w oryginale miała być z piłeczkami, ale akurat w firmie był deficyt piłeczek :P). Zabawa polegała na rzucaniu długopisów kolejnej osobie z teamu tak, aby w ciągu określonego czasu zdobyć jak najwięcej punktów (przy czym punkt zdobywało się wtedy, gdy długopis przeszedł przez ręce wszystkich osób z teamu). Było kilka utrudnień:
- długopis musiał być w fazie lotu (czyli nie podajemy go, tylko rzucamy)
- nie można rzucić długopisu do osoby, która stoi bezpośrednio obok ciebie
- jest 5 długopisów, na początku zabawy wszystkie długopisy trafiają do jednej osoby
W zabawie brało udział 9 osób. Na samym początku mieliśmy oszacować, ile punktów zdobędziemy w ciągu 20 minut. Oczywiście nikt z nas nigdy wcześniej nie brał udziału w podobnej zabawie, więc nasze oszacowanie znacznie odbiegło od liczby punktów, którą uzyskaliśmy w rzeczywistości.
Zabawa z długopisami odbywała się w metodyce SCRUMa. 20 minut zostało podzielone na pięć 4-minutowych Sprintów. W każdym Sprincie mieliśmy 3 minuty na rzucanie długopisów i 1 minutę na doskonalenie procesu. Przed każdym Sprintem mieliśmy oszacować, ile punktów zdobędziemy w Sprincie.
Przed pierwszym Sprintem mieliśmy także chwilę czasu na ustalenie taktyki. Naszą taktyką było ustawienie się w kółku i rzucanie długopisów do prawego sąsiada osoby, która stała obok ciebie.
Po pierwszym Sprincie okazało się, że jesteśmy w stanie zdobyć 4 razy więcej punktów, niż oszacowaliśmy na samym początku Sprintu. To nam pomogło oszacować kolejny Sprint.
Na pierwszej Retrospektywie zdecydowaliśmy się na wysunięcie się lekko do przodu co drugiej osoby w kółku. Po drugim Sprincie zdecydowaliśmy, że zwiążemy długopisy smyczą, aby rzucać 5 długopisów jednocześnie. Smycz z długopisami po kilku okrążeniach się rozpadła i w efekcie zdobyliśmy dokładnie tyle punktów, co w pierwszych dwóch Sprintach. Ale Sprint okazał się mniej męczący dla każdego członka zespołu, niż poprzednie. Dlatego kolejne Sprinty także zaczynaliśmy od związania smyczą długopisów (ale tym razem staraliśmy się, żeby wiązanie było trwalsze). W efekcie w czwartym Sprincie zdobyliśmy 1,5 razy więcej punktów niż w poprzednich Sprintach. W piątym Sprincie zdecydowaliśmy się na głośne liczenie punktów, co także zwiększyło liczbę zdobytych punktów (gdy czas się kończył, staraliśmy się nabić na finishu więcej punktów :P)
Na początku zabawy wszyscy byli niezadowoleni z tego, że 25% czasu jest nam zabierane na to, żeby doskonalić proces, a tylko przez 75% czasu zdobywaliśmy punkty. Jednak pod koniec widzieliśmy, że czas poświęcony na doskonalenie procesu nie był czasem straconym. Tak samo jest podczas powstawania programu. Często nawet nie zauważamy, ile pożytku może wnieść do projektu czas poświęcony na Retrospektywę, w której dyskutujemy o tym, co możemy ulepszyć w kolejnych Sprintach, a co poszło nie tak.
Warto też być otwartym na zmiany. Wiedzieliśmy, że dotychczasowa strategia jest owocna, a zmiany zawsze wprowadzają chaos i nie wiadomo, czy ułatwią nam pracę, czy tylko ją pogorszą. Ale tego się nie dowiemy, dopóki nie spróbujemy zmian. Ważne jest to, aby zespół nie był karany za nieudaną zmianę, gdyż może to negatywnie wpłynąć na chęci ulepszania procesu.
Pytanie tylko jak rzucanie długopisami ma się do faktycznego wytwarzania oprogramowania ;)
OdpowiedzUsuńFakt, trochę mało ma z tym wspólnego, tym bardziej, że w każdej kolejnej iteracji robiliśmy to samo, co w poprzedniej, a proces produkcji oprogramowania nie jest aż tak powtarzalny. Ale chodzi głownie o to, żeby być otwartym na zmiany, które mogą usprawnić proces i spowodują, że ludzie będą mniej się męczyli. Ja np. nie sądziłem, że zmiana sposobu podawania długopisów może przynieść aż tyle korzyści.
OdpowiedzUsuń