Podczas jednej z moich ostatnich wizyt w zaprzyjaźnionym Zespole Deweloperskim usłyszałem pytanie: “A tak właściwie to jakie są korzyści pracy w Sprintach?”. Odbyliśmy ciekawą rozmowę przy automacie z kawą, na koniec której Deweloper podsumował: “Ciekawe. Nie myślałem o tym w ten sposób”. W artykule przedstawiam korzyści, które płyną z pracy w regularnych Sprintach.
Zapewnienie systematycznej informacji zwrotnej na temat produktu
Cyklicznie oraz poprawnie realizowany Przegląd Sprintu zapewnia, że cykl inspekcji oraz adaptacji produktu jest regularnie realizowany. Zespół w określonych, stałych odcinkach czasu otrzymuje informację zwrotną na temat wytworzonego Przyrostu produktu i może użyć tej wiedzy w toku dalszych prac nad rozwojem produktu. Powoduje to, że ryzyko budowania niewłaściwego produktu zmniejsza się, ponieważ produkt w cykliczny sposób jest prezentowany interesariuszom. W przypadku zauważenia przez nich uchybień, odchyleń od oczekiwań lub błędów, mogą szybko reagować, natomiast ewentualne zmiany mogą być uwzględnione przez zespół już podczas kolejnego Planowania Sprintu.
Oczywiście piszę tutaj o przypadku, w którym regularne pozyskiwanie informacji zwrotnej nie jest jeszcze nawykiem funkcjonującym wewnątrz Zespołu Scrumowego. Doświadczone zespoły zwykle nie czekają do Przeglądu Sprintu, aby otrzymać feedback od interesariuszy — jak tylko zrealizują konkretny element Backlogu Produktu, pokazują efekty prac osobom zainteresowanym. Takie podejście otwiera przed zespołem możliwość poprawy funkcjonalności w przypadku wykrycia błędów. Natomiast jeśli wszystko jest zrealizowane poprawnie, otrzymują możliwość wcześniejszego wdrożenia konkretnej zmiany na środowisko produkcyjne, jeśli oczywiście proces wdrażania zmian jest odpowiednio elastyczny.
Praca nad produktem dzielona jest na małe części
“Tego nie da się zrobić w dwa tygodnie” — słyszę bardzo często w Zespołach Scrumowych. Zwykle nie przekonuje mnie takie stwierdzenie, bo na bazie swoich doświadczeń wiem, że można dokonać podziału dużych fragmentów produktu na mniejsze części. To, czego często brakuje, aby do tego doprowadzić, to wiedza, jak to poprawnie zrealizować. Praca w Sprintach powoduje, że dzielenie elementów Backlogu Produktu na mniejsze kawałki staje się z jednej strony koniecznością, z drugiej dostarcza bardzo konkretne korzyści.
Dzielenie funkcjonalności produktu na mniejsze części powoduje, że elementy te są zwykle mniej ryzykowne. Dzieje się tak, bo po pierwsze, w procesie dzielenia zostały najprawdopodobniej dogłębnie omówione i zrozumiane przez zespół na tyle, aby można było je oszacować. Po drugie, nawet jeśli Zespół Deweloperski niepoprawnie zrozumiał konkretny elementy Backlogu Produktu, to dowiedzą się o tym najpóźniej na koniec Sprintu. Po trzecie, podział na małe części eliminuje zadania, które ciągną się przez kilka Sprintów, co może mieć wpływ na demotywację w Zespole Deweloperskim oraz nadszarpnięcie zaufania po stronie biznesowej.
Przewidywalność pracy dla interesariuszy
Wielokrotnie spotykam się ze stwierdzeniem, że interesariuszom bardziej, niż na prędkości Zespołu Deweloperskiego, zależy na jego przewidywalności. Czyli jeśli zespół uzgadnia z Właścicielem Produktu, że zrealizuje konkretny Cel Sprintu, to tak się faktycznie dzieje, a ewentualne zmiany prognozy realizowanego zakresu prac są przedmiotem dyskusji pomiędzy Zespołem Deweloperskim a Właścicielem Produktu.
Stabilna, przewidywalna praca zespołu pozwala interesariuszom na planowanie dodatkowych działań związanych z produktem, takich jak komunikacja z użytkownikami, uruchamianie kampanii reklamowych, wywiązywanie się z ustaleń z partnerami czy też przygotowywanie odpowiednich danych, potrzebnych do budowania produktu.
Bezpieczna przestrzeń do eksperymentów oraz uczenia się
Kiedy decydujemy się na realizację konkretnego Celu Sprintu, elementy które będziemy realizować zwykle różnią się od siebie. Przydatnym frameworkiem, opisującym różną naturę problemów, z którymi się spotykamy, jest Cynefin autorstwa Dave’a Snowden’a. Jak to się przekłada na pracę w Scrumie?
Pewne elementy realizowane przez Zespół Deweloperski są oczywiste dla zespołu i w takim przypadku rozwiązania są znane, powtarzalne i do realizacji nie wymagają przeprowadzenia głębokiego rozpoznania.
Inne elementy potrafią być skomplikowane – żeby je zrealizować, musimy dokonać analizy możliwości i spośród dostępnych wybrać takie, które w naszej ocenie dadzą na spodziewany rezultat.
Sprinty okazują się przydatnym narzędziem, gdy natrafiamy na kolejną grupę elementów, które reprezentują złożone problemy, na które na dzień startu Sprintu nie znamy odpowiedzi. Aby je uzyskać, zespoły mogą zdecydować się na eksplorację potencjalnych rozwiązań, przeznaczając na to określoną ilość czasu, np. kilka godzin, jeden dzień lub nie więcej niż jeden Sprint.
Przykładem takiej eksploracji może być wykonanie spike’a, czyli prostego kawałka kodu, który w efekcie realizacji daje Zespołowi Deweloperskiemu nową porcję wiedzy. Na bazie zdobytych informacji, zespół może zrobić kolejne podejście do lepszego zrozumienia konkretnego elementu Backlogu Produktu, tym razem bogatszy o wiedzę, którą zdobył na skutek umówienia się, że na jej poszukiwanie spędzą skończoną, z góry określoną ilość czasu.
Stały, określony rytm pracy dla Zespołu Scrumowego
Sprint sam w sobie daje bardzo konkretne ramy — wiemy, kiedy się zaczyna oraz kiedy się kończy. Co więcej, Zespół Scrumowy przyzwyczaja się się do obranego schematu działań. Przykładowo: zawsze zaczynamy tydzień pracy w poniedziałek Planowaniem Sprintu, kończymy tydzień pracy w piątek Przeglądem Sprintu oraz Retrospektywą. Wydarzenia te są zwykle na stałe wpisane do kalendarzy członków zespołu, co zapewnia, że pytania takie jak “Kiedy mamy planowanie?”, “O której robimy Przegląd Sprintu?”, “W jakiej salce robimy retro?” pojawiają się bardzo rzadko lub wcale.
Stały, powtarzalny rytm pracy pozwala Zespołowi Scrumowemu skupić się na faktycznej pracy, uznając ramy czasowe wydarzeń w Scrumie za coś oczywistego, decydując się na pracę w tym konkretnym frameworku.
Poczucie małych zwycięstw
Kiedy pracowałem jako Scrum Master, z niecierpliwością czekałem na każdy kolejny Przegląd Sprintu. Był on bowiem zwieńczenie całego tygodnia pracy: problemów, sukcesów, wysiłków oraz intensywnej współpracy. Było to dla mnie satysfakcjonujące uczucie i okazja do namacalnego doświadczenia, że prace nad produktem posuwają się do przodu.
Z moich obserwacji wynika, że nawet pozornie małe sukcesy — takie jak zrealizowania jednego z zadań, udane wdrożenie, otrzymanie pozytywnej informacji zwrotnej od użytkownika produktu — dają energię Zespołowi Scrumowemu i dobrze wpływają na jego motywację.
Sprint naturalnie dostarcza poczucie małego zwycięstwa na koniec iteracji, jeżeli oczywiście udało nam się np. zrealizować Cel Sprintu lub nauczyć się czegoś ważnego dla zespołu.
Podsumowanie
Istnieje co najmniej kilka wartościowych argumentów przemawiających za pracą w regularnych Sprintach. Jakie widzicie innego korzyści? A może dostrzegacie zagrożenia? Zapraszam do podzielenia się przemyśleniami w komentarzach.