Jak przebiega proces Scrum? 

Tyle mówimy i piszemy o samym Scrumie, ale jakoś do tej pory nie opowiedzieliśmy o tym, jak przebiega proces Scrum. Co się dzieje od samego początku, do samego końca oraz, przede wszystkim, gdzie zacząć?

Proces Scrum został zaktualizowany wraz z opublikowaniem nowej wersji Scrum Guide w listopadzie 2020. Poniższy wpis uwzględnia zmiany wprowadzone w Podręczniku Scrum.

Czym jest Scrum?

Jeżeli chodzi o czysto teoretyczny aspekt tego czym jest Scrum, to polecam nasz nieco już wiekowy film na YouTube. Niedługo pewnie nagramy go od nowa, bo w międzyczasie wymieniliśmy prawie wszystkie komponenty naszego przenośnego studia, a i sam Scrum zmienił się znacznie (patrz: Zmiany w Scrum Guide 2020).  Niniejszy tekst ucieka od „dlaczego” i skupia się na „jak”. Jest absolutnie podstawowym wprowadzeniem w to, jak działa Scrum. Pamiętajmy jednak, że zawiera on wiele niuansów, które warto byłoby zgłębić, zanim zaczniemy w ten sposób pracować.

Mówiąc o Scrumie często używamy słowa „metodyka„. Czasami nazywamy go „iteracyjnym i przyrostowym sposobem pracy”, co też uzasadnialiśmy w tekście opisującym oba te aspekty. W skrócie: korzystając ze Scruma układamy sobie prace w krótkich iteracjach (Sprintach). Rezultat naszej pracy (Przyrost) powstaje, zgodnie z nazwą, przyrostowo. To znaczy, że ciągle dokładamy do niego kolejne elementy i spełniamy kolejne potrzeby biznesowe (wymagania).

Cechą Scruma, która będzie nam dzisiaj nieco przeszkadzać, jest jego cykliczność. Proces Scrum nie ma ani początku, ani końca. Jest on co prawda ujarzmiony w Sprintach, ale nie mamy tutaj żadnych etapów przygotowawczych, ani żadnego podsumowania. Startujemy niejako ze środka i kręcimy się w kolejnych iteracjach. Założeniem, które pozwala nam w ten sposób działać jest fakt, że budujemy złożony produkt i będziemy go rozwijać tak długo, jak korzyści będą przewyższały nakłady.

Gdzieś w okolicach egzaminów na certyfikaty Scrum pojawia się stwierdzenie, że aby zacząć pracę potrzebujemy jedynie Product Ownera z pomysłami do realizacji, Deweloperzy gotowy te pomysły zrealizować oraz Scrum Mastera znającego Scrum i potrafiącego wesprzeć zespół. Tylko tyle i aż tyle.

Ale skoro pracujemy cyklicznie, niejako w pętli, to wciąż brakuje nam jakiegoś punktu zaczepienia albo momentu startu.

Od czego zacząć działać w Scrum?

Zawsze kiedy mam opowiedzieć o tym jak przebiega proces Scrum, to zaczynam od backlogu. A konkretniej od Backlogu Produktu i Product Ownera. Jak już powiedzieliśmy, musimy mieć osobę posiadającą wizję „czegoś” do realizacji oraz wymagania na to „coś”, zebrane w jednym miejscu. To „coś” to nasz produkt, który mniej więcej wiemy jak chcemy rozwijać.

Tak więc Product Owner posiada Cel Produktu, do którego chce dotrzeć realizując poszczególne Elementy Backlogu Produktu, ułożone w postaci listy uporządkowanej. W Backlogu Produktu jest miejsce na wszystko – od bliskich planów, przez błędy do poprawy, aż do marzeń i koncepcji, aby tylko wspierało zdefiniowany przez PO Cel Produktu.

Idealnie byłoby, gdyby te wymagania były uporządkowane od najważniejszych (które będą realizowane niebawem) do tych najmniej ważnych (którymi zajmiemy się „kiedyś”). Te pierwsze zwykle będą też bardziej szczegółowo opisane i mniejsze. Deweloperzy będzie je realizowali w najbliższym Sprincie, muszą więc one być dość dobrze określone.

Mamy więc jedną osobę z potrzebami/wymaganiami (PO) oraz niewielką grupę („około pięciu”, a tak naprawdę zwykle do dziewięciu-jedenastu) Deweloperów. Pod pojęciem „Deweloper” rozumiemy tutaj każdego, kto wytwarza nasz produkt. Dodajmy do tej grupy jeszcze Scrum Mastera, którego odpowiedzialności nie sposób zmieścić w tym krótkim tekście, a w rezultacie dostaniemy cały Scrum Team.

To jest dla nas punkt wyjścia, dzięki któremu możemy wejść w iteracyjny proces Scrum. A to znaczy, że wszystko, co teraz będziemy omawiać, dzieje się cyklicznie.

Jak rozpoczyna się proces Scrum?

Sprint („ograniczenie czasowe trwające miesiąc bądź krócej”) zaczyna się Planowaniem Sprintu, które to wydarzenie ma trzy części.

W pierwszej części Planowania Product Owner mówi, w jaki sposób nasz produkt mógłby stać się bardziej wartościowy przez czas tego Sprintu. Następnie na tej podstawie Scrum Team bierze pod uwagę Cel Produktu i Product Backlog i tworzy Cel Sprintu – coś co chcemy osiągnąć.

W kolejnym kroku Deweloperzy decydują o tym, co będą realizowali w najbliższej iteracji. Oczywiście, nie wybierają wymagań jak im się podoba, ale idą od góry Product Backlogu i bierze tyle, ile wydaje im się, że dadzą radę zrealizować. Te wybrane wrzuca do artefaktu zwanego Sprint Backlog. Oczywiście na tym etapie mogą pojawić się negocjacje z PO, bo nie zawsze kolejność w backlogu jest rozsądna i optymalna. Wszystko to jest dopuszczalne, o ile są to wspólne ustalenia.

Product Owner przyda się także w trzeciej części planowania, gdzie zespół będzie opracowywał zgrubny sposób realizacji wymagań wybranych w części pierwszej. Te szczegóły (plan realizacji) również trafiają do Sprint Backlogu.

Planowanie kończy się gdy upłynie timebox lub gdy wszyscy wiedzą za co się zabrać i są w stanie opowiedzieć, jak będą realizować Cel Sprintu.

Reszta czasu przeznaczonego na Sprint przebiega na realizowaniu planu zapisanego w Sprint Backlogu, czyli na budowie Przyrostu. Szczególnym kwadransem każdego dnia jest Daily Scrum, na którym Deweloperzy synchronizują i planują następne dwadzieścia cztery godziny. Tak działamy do momentu, aż dotrzemy do dwóch ostatnich wydarzeń.

Każdy koniec to początek

Każdy Sprint kończy się dwoma wydarzeniami, na których mówimy o zupełnie różnych rzeczach. To trudne, bo ludzie mają tendencje do poruszania wszystkiego, co ich zdaniem jest ważne, ale dobry Scrum Master zadba o osiąganie konkretnych celów poszczególnych wydarzeń.

Na Sprint Review zapraszamy interesariuszy i oglądamy to, co powstało (Przyrost) oraz Product Backlog i postępy w kierunku Celu Produktu. Naszym celem jest ustalenie strategii na kolejne Sprinty, zaktualizowanie priorytetów i porozmawianie o tym, co się zmieniło w ostatnim czasie. Warto też pokazać/obejrzeć nasz produkt i usłyszeć tradycyjne „ojej, ale nie o to nam chodziło”.

Z kolei na Sprint Retrospective (już bez interesariuszy) mówimy o ludziach, procesach, relacjach, narzędziach oraz Definition of Done. Tu właśnie tuningujemy nasz proces Scrumowy, czyli usprawniamy to, jak pracujemy w Sprintach. Identyfikujemy sukcesy i porażki oraz przygotowujemy usprawnienia. Mamy nadzieję, że dzięki nim od następnej iteracji pracowało się nam będzie lepiej, wydajniej lub osiągniemy wyższą jakość.

Gdy upłynie ostatnia sekunda Sprint Retrospective, ruszamy na planowanie kolejnego Sprintu. I tak działamy do momentu, w którym ktoś stwierdzi, że nie warto już tego dalej ciągnąć. Póki jest backlog, póty jest praca.

Czego nam jeszcze brakuje w procesie Scrum?

W tym całym opisie zabrakło jednej bardzo istotnej rzeczy, bez której cały proces Scrum legnie w gruzach. Bo nawet jeśli Product Owner będzie miał pomysły na pierwszy Sprint, to w którymś momencie backlog nam się po prostu skończy. A nawet jeśli nie, to zostaną tam same ogromne tematy i wymagania, o których nikt nic nie wie. A takich rzeczy nie zaplanujemy.

Na szczęście twórcy Scruma przewidzieli ten scenariusz i w ramach procesu scrumowego mamy coś, co nazywa się Product Backlog Refinement. Jest to proces ciągły polegający na dekompozycji, rozpoznawaniu, szacowaniu i dzieleniu wymagań już znajdujących się w Backlogu Produktu. Mówiąc inaczej, jest to przygotowanie wymagań do planowania. Żadna tam analiza, ani prototypowanie, tylko konkretnie – refinement.

Dzieje się on niejako w tle Sprintu i dotyczy grillowania przyszłych wymagań tak, abyśmy nigdy nie stanęli przed problemem „nie wiem co jest w backlogu i nie umiemy zaplanować następnej iteracji”. Doskonalenie Backlogu Produktu to temat rzeka. Poza podlinkowanym tekstem na blogu polecamy także poświęcony mu film z kategorii „Wszystko co chcielibyście wiedzieć o…”

Dopiero teraz, uwzględniając „PBR”, możemy powiedzieć, że na bardzo ogólnym poziomie udało nam się omówić proces Scrum. Uffff!

Jeśli chcecie dowiedzieć się jeszcze więcej o niuansach naszej ulubionej metodyki, zapraszamy na nasz kanał na YouTube oraz na nasze szkolenia Scrum i Agile. Znajdziecie tam propozycje dla zespołów, Scrum Masterów, Product Ownerów, analityków i nie tylko. Z chęcią także przygotujemy indywidualny program spełniający Twoje oczekiwania.