Scrum w praktyce - czyli dlaczego proste zasady są niezwykle trudne w codziennym zastosowaniu

Piotr Romanowski

December 23, 2015 | Biznes

Speednet działa nie tylko jako software house, ale zajmuje się również outsourcingiem osób oraz całych zespołów. Dzięki temu w dość krótkim przedziale czasu miałem okazję przyjrzeć się jak działa Scrum w poszczególnych projektach prowadzonych po stronie różnych firm. Niestety większość z nich stosowała tylko wybrane elementy tej metodyki. Zdarzały się również i takie firmy, które poza zaczerpniętym słownictwem nie miały nic wspólnego ze Scrumem – chociaż deklarowały się jako jego zwolennicy, którzy stosują go na co dzień.

Pomimo, iż istnieje wiele książek omawiających problemy z jakimi borykają się zespoły wprowadzające lub stosujące Scruma, to postanowiłem podzielić się swoimi spostrzeżeniami oraz informacjami o tym jak udało się rozwiązać poszczególne przeszkody. Do napisania niniejszego wpisu skłoniła mnie głównie obserwacja, iż niejednokrotnie zespół był świadomy, że nie pracuje zgodnie ze Scrumem zaś osoby nadzorujące projekt lub pełniące rolę Product Ownera nie dostrzegały problemu. Zdarzało się również, iż zapominano o najważniejszym celu Scruma i traktowano jako metodykę wytwarzania oprogramowania – no właśnie, a jaki jest jego główny cel?

Scrum jako jedno z wielu narzędzi wspomagających wytwarzanie oprogramowania, ale nie tylko..

Często spotykam się ze stwierdzeniem, że projekt prowadzony jest zgodnie z metodyką Scrum. Moim zdaniem Scrum NIE jest metodyką prowadzenia projektu, ale narzędziem lub raczej frameworkiem – poniekąd jest też w taki sposób zdefiniowany na oficjalnej stronie www.scrum.org. Uważam, że Scruma trafnie określił Mitch Lacey pisząc w swojej książce:

Scrum is not a methodology or set of engineering practices. It is, instead, a lightweight framework that was designed to manage software and product development.

Jego składowe nie mogą pełnić funkcji do których nie zostały stworzone. Przykładowo codzienne, poranne spotkania nie są spotkaniami statusowymi, na których menedżer projektu odpytuje każdego po kolei ile godzin dana osoba spędziła nad konkretnym zadaniem oraz dlaczego nie zdążyła zrobić tego co zostało jej zlecone (tak – z takimi przypadkami też się spotykałem). W jaki sposób zatem najtrafniej zdefiniować czym jest scrum? Powiedzieliśmy sobie, że jest to narzędzie, które należy używać zgodnie z przeznaczeniem, wykorzystując jego wszystkie składowe. Posłużmy się przykładem. Wiertarka – jeśli nie zamocujemy nic w uchwycie wiertarskim (chociażby wiertła lub głowicy polerskiej) to narzędzie nie będzie użyteczne. Podobnie jest ze scrumem – istotny jest jego każdy element – dopiero wszystkie składowe czynią go użytecznym narzędziem. Główną rolą Scruma jest ułatwianie wykrywania wszelkich utrudnień, które stają na drodze osiągnięcia celu. Konsekwentne stosowanie wszystkich elementów scruma pozwala stosunkowo szybko wykryć problemy. Nie oznacza to, że oferuje ich rozwiązanie – te musi samodzielnie wypracować zespół. Scrum narzuca jedynie konieczność stałego doskonalenia procesów przybliżających do osiągania zamierzonych celów – w naszym przypadku będą to głównie poszczególne funkcje oprogramowania – wytwarzane szybciej, oferujące wyższą jakość. Skutkiem ubocznym będzie samodoskonalenie zespołu oraz ulepszanie wszystkiego dokoła co może przyczynić się do osiągania poszczególnych celów. Mechanizmy scruma, takie jak retrospekcje pozwalają na adaptację czynności koniecznych do realizacji postawionych celów. Po krótkim przypomnieniu (osoby niezaznajomione z tematyką scruma zachęcam aby przed kontynuacją zapoznały się z www.scrumguides.org) możemy przejść do przypadków niewłaściwego użycia scruma oraz rozwiązań, które okazały się pomocne.

Problem 1: „Stosujemy tylko wybrane elementy scruma”

Spotkałem się z projektem, w którym nie było sprint planningu oraz retrospekcji, zaś zadania na sprint były ustalane przez Menadżera Projektu i przypisywane do poszczególnych osób (po uprzedniej wycenie godzinowej). Jaki był efekt takiej pracy? Między innymi:

słabej jakości oraz trudny w utrzymaniu kod a co za tym idzie obniżenie jakości produktu
zadania oddawane na ostatnią chwilę bez przeprowadzenia testów
nadgodziny
poszczególne osoby skupiały się wyłącznie na realizacji zadań, które zostały im przydzielone – brak poczucia odpowiedzialności za Sprint przez cały zespół
wywierana presja – starano się nie przekraczać oszacowanego czasu

Przyjrzyjmy się co poszło nie tak. Na pewno zabrakło Scrum Mastera, którego powinna charakteryzować doskonała znajomość Scruma oraz silny charakter umożliwiający egzekwowanie reguł Scruma na wyższych szczeblach. Dodatkowo widać było brak zaufania do zespołu ze strony Menadżera Projektu lub jego nieznajomość Scruma. Jeśli trafisz do zespołu, w którym nie działa Scrum należy być tym pierwszym, który wyjdzie przed szereg i zasygnalizuje problem.

Sprint planning, szacowanie pracochłonności zadań, zaufanie do zespołu

No tak, ale dlaczego to zespół powinien dobierać zadania do realizacji w danym Sprincie oraz je wyceniać czyli realizować tzw. Sprint Planning? Wbrew pozorom proces wyceniania zadań to nie tylko samo ich szacowanie, ale również dokładne zrozumienie o co w nich chodzi i czy na pewno są zrozumiałe dla każdego członka zespołu. Dodatkowo jeśli wyceny poszczególnych osób znacząco się różnią, to może to oznaczać, że poszczególne osoby nie uwzględniły pewnych składowych (i niejasności zostaną odkryte już na początku) lub po prostu są dla nich bardziej złożone. W drugim przypadku należy uwzględnić pewną rezerwę czasową, gdyż nie wiadomo przez kogo może być realizowane dane zadanie. Definicja ukończenia, wymagania oraz zakres prac musi być wszystkim dobrze znany przed rozpoczęciem sprintu. Zespół najlepiej wie jakie zadania jest w stanie zrealizować (zachowując przy tym wysoką jakość tworzonego kodu) w trakcie określonego przedziału czasu. Jeśli wszyscy solidarnie zobowiążą się do wykonania wspólnie ustalonego zakresu Sprintu to nie tylko produkt zyska na jakości, ale i morale zespołu będą o wiele wyższe. W przypadku z góry narzucanych zadań każdy stara się realizować swoje, zapominając przy tym, że sukcesem jest “dowiezienie” całego zakresu Sprintu. Dlatego tak ważne jest, aby postrzegać zadania jako wspólne i czuć się za nie współodpowiedzialnym. Planning meetingi przyczyniają się do tego, dodatkowo pielęgnując ducha współpracy. Nadmienię tylko, że zadania do Sprintu dobierane są zgodnie z priorytetami ustalonymi przez Product Ownera a te ustala on w zgodzie z priorytetami interesariuszy. Pracochłonność zadań opłaca się również szacować poza Sprint Planningiem, co może ułatwić pracę Product Ownerowi. Wcześniejsza znajomość złożoności poszczególnych zadań pozwoli na ewentualne zmiany priorytetów, zwłaszcza kiedy produkt ma znacząco ograniczony budżet. Często zdarza się, iż estymacje traktowane są jako coś wiążącego. Niestety programowanie jest procesem twórczym, nie pozwalającym wszystkiego przewidzieć. Zespół powinien dążyć do doskonalenia umiejętności estymowania zadań, zaś osoby obserwujące projekt posiadać świadomość, iż estymacje nie są wiążącymi wartościami i mogą ulegać zmiano w trakcie trwania przebiegu. Jedynym pewnym terminem jest data release’a, ale zakres tego, co się w nim znajdzie, zależny jest od ilości zadań zrealizowanych w danym Sprincie. Należy operować zakresem Sprintu (ilością zadań jakie zrealizuje zespół) a nie jakością produktu lub nadgodzinami. W jednym ze zdań użyłem sformułowania „osoby obserwujące projekt”. W Scrumie istotne jest, iż to zespół odpowiada za Sprint i jest komórką samo organizującą się, której nie należy narzucać sposobu pracy a jedynie wskazywać co jest istotne z punktu widzenia biznesowego. Takie podejście wymaga zaufania od „wyższych szczebli” oraz sporej pracy Scrum Mastera na etapie docierania się nowo utworzonego zespołu. Tematykę szacowania zadań oraz sposobów obserwowania postępów prac postaram się przybliżyć w kolejnym artykule. Przyjrzyjmy się tymczasem innemu problemowi wymienionemu w omawianym przypadku – pomijaniu retrospekcji.

Retrospekcja a doskonalenie sztuki wytwarzania oprogramowania

Czym tak naprawdę jest retrospekcja i dlaczego jest tak ważna? Podczas trwania całego Sprintu zespół skupiony jest na realizacji celów, które przyjęto podczas Sprint Planningu. Nie zawsze działania zespołu są efektywne, za to zawsze znajdzie się obszar lub czynność, które mogą zostać udoskonalone. Po zakończeniu prac przychodzi czas na analizę działań, czyli wskazanie tego, co było dobre (działało oraz przynosiło efekty), oraz tego co utrudniało lub spowalniało prace. Dzięki retrospekcji zespół może stale zwiększać swoją efektywność na różnych obszarach. Niestety często spotyka się argument przytaczany w danym projekcie, iż zrezygnowano z retrospekcji, gdyż nic nie zmieniały. Takie podejście sprawia, iż zespół nie rozwiązuje problemów, stoi w miejscu lub co gorsze poszczególne obszary projektu stają się coraz bardziej zaniedbane. W konsekwencji nawarstwienie problemów przyczynia się do konfliktów, spadku jakości produktu, obniżenia morale zespołu a w skrajnych przypadkach nawet upadku projektu. Wprowadzenie usprawnień czy rozwiązywanie odkrytych podczas retrospekcji problemów wymaga wysiłku od całego zespołu podczas kolejnych Sprintów. Konstruktywna krytyka oraz wybór najistotniejszych obszarów nad którymi należy cały czas pracować, jest gwarancją sukcesów. Jeśli podczas kilku poprzednich retrospekcji zespół uznał i zobowiązał się do usunięcia jakiejś przeszkody lub wprowadzenia pewnego usprawnienia, to na najbliższej retrospekcji należy podsumować, co udało się zrobić i czy efekt jest wystarczający. W przypadku jeśli zamierzenie nie zostało zrealizowane, należy zastanowić się dlaczego oraz co można zrobić. Zespół musi chcieć zmian oraz konsekwentnie dążyć do ich wprowadzania w życie. Prostą metodą jest wypisywanie najważniejszych problemów czy zagadnień do udoskonalenia na tablicy lub flipboardzie. Następnie zespół wspólnie wybiera kilka spraw nad którymi zobowiązuje się pracować. Warto wypisać je w widocznym miejscu – tak aby każdego dnia przypominały, iż należy nad nimi pracować. Można też na codziennym porannym spotkaniu wspomnieć, co udało się osiągnąć w związku z zadaniami z retrospekcji. Podsumowując retrospekcja pozwala zidentyfikować problemy czy obszary do usprawnienia, jednak wdrożenie rozwiązań to dłuższy, stały proces. Zazwyczaj nie retrospekcja jest problemem, ale systematyczność, konsekwencja i wytrwałość we wdrażaniu rozwiązań. Wiele osób błędnie zakłada, że podczas jednej sesji retrospekcji rozwiąże się problemy. W przypadku, gdy to nie poskutkuje zwyczajnie pomija kolejne sesje retrospekcji. Jeśli widzimy takie zachowania w projekcie – reagujmy, nie czekajmy aż zrobi to ktoś inny.

Problem 2: podczas trwania sprintu stale zmieniany jest jego zakres

Z wspomnianym problemem zapewne spotkało się wielu z nas. W różnych projektach ma on różne podłoże. Zacznijmy więc od sytuacji, w której zespół rozwija nowe funkcje aplikacji jednocześnie zajmując się jej utrzymaniem. Dodatkowo poprawiane błędy wdrażane są na produkcję w krótkim czasie. W takim przypadku nie da się zaplanować Sprintu. Rozwiązaniem może być wydzielenie kilku osób z zespołu dedykowanych wyłącznie utrzymaniu aplikacji. Pozostała część zespołu realizowałaby w takim podejściu „normalny” zakres Sprintu, przy czym błędy o niskich priorytetach mogłyby wchodzić w skład zakresu kolejnych Sprintów. O wiele trudniejszym przypadkiem jest sytuacja, w której Product Owner decyduje i dorzuca kolejne zadania do trwającego przebiegu jednocześnie nie rezygnując z uprzednio dodanych. W uzasadnionych sytuacjach zrozumiałe jest, iż zakres sprintu ulega drobnym modyfikacjom. Jednak takie zmiany powinny mieć miejsce na początku Sprintu oraz wiązać się z rezygnacją z uprzednio dodanych zadań. Zadnia wyrzucane a raczej zastępowane powinny mieć podobny stopień złożoności, zaś prace nad nim nie powinny być rozpoczęte w momencie wyrzucania ze Sprintu. Dodawanie zadań do Sprintu powinno być zawsze konsultowane z całym zespołem. Product Owner powinien zostać poinformowany przez zespół o wszelkich konsekwencjach związanych ze zmianą zakresu Sprintu. Należy unikać przeładowania Sprintu, gdyż wiąże się to z wieloma negatywnymi konsekwencjami – od spadku morale zespołu poprzez pogorszenie jakości kodu aż po niedostarczenie żadnego zadania z przyjętego zakresu. W tym przypadku bardzo istotną rolę pełni Scrum Master oraz klarowna komunikacja pomiędzy zespołem a Product Ownerem. Chciałbym w tym miejscu jeszcze raz podkreślić, iż należy komunikować wszelkie konsekwencje zmiany zakresu sprintu – nawet te najdrobniejsze. Jeśli sytuacja powtarza się na tyle często, to w gestii Scrum Mastera leży zakomunikowanie na „wyższych szczeblach”, iż dialog pomiędzy zespołem a Product Ownerem nie przynosi rezultatów. Jedynie wysoka świadomość we wszystkich pionach organizacji, tego, co dzieje się w projekcie może przyczynić się do rozwiązania tego typu problemu. Istotna jest również jednomyślność i zdecydowanie do działania całego zespołu.

Wykorzystywanie Scruma to ciągłe pogłębianie wiedzy

Przypadków oraz błędów w wykorzystywaniu Scruma, które można opisać jest jeszcze wiele – ważne jest,, aby uczyć się na błędach i stale pogłębiać wiedzę. Chociaż zasady Scruma są proste, to łatwo o nich zapomnieć lub niewłaściwie stosować. Mam nadzieję, iż chociaż w małym stopniu nakreśliłem problematykę.

Warto zapoznać się z:
http://guntherverheyen.com/2013/03/21/scrum-framework-not-methodology/
https://www.scrumalliance.org/community/profile/mitchlacey