Po tym jak zapoznaliście się z krótką historią powstania Scrum Guide i zmianami jakie zachodziły na jego kartkach chciałabym skonfrontować to co mamy na papierze z praktycznym zastosowaniem procesu. Zanim opowiem o podstawowych problemach jakie rodzi adaptacja Scruma, zacznę od krótkiego cytatu, który pokazuje postawę jednego z zespołów, z którym jakiś czas temu miałam okazję rozpoczynać współpracę:
Mamy przecież wszystkie spotkania, mieścimy się z nimi w czasie, ale nie dowozimy sprintów, ten scrum to w ogóle nie działa.
Wiele problemów jakie powoduje adaptacja Scruma wiąże się z jego niezrozumieniem. Przez wiele osób Scrum jest bowiem pojmowany tylko jako zbiór spotkań towarzyszący sprintom oraz ewentualnie z rolami w zespole. Często nawet nie zdajemy sobie sprawy z odpowiedzialności jakie są przyporządkowane do poszczególnych ról lub rozumiemy je tylko powierzchownie. Przyznając się szczerze – sama kiedyś żyłam w błędnym przekonaniu, że to Product Owner jest odpowiedzialny za tworzenie PBI (Product Backlog Item) i jeżeli on tego nie zrobi no to przysłowiowa kaplica. Wiele innych ale i podobnych refleksji skłoniło mnie do częstszego zaglądania do Scrum Guidea. Dzięki takiemu podejściu niejednokrotnie odkrywałam odpowiedzi na nurtujące mnie pytania.
The Product Owner may do the above work, or have the Development Team do it. However, the Product Owner remains accountable.
(Źródło: Scrum Guide, 2017)
Takie fragmenty z przewodnika jak powyższy udowodniły mi, jak często powinnam do niego wracać. Pokazały mi również jak dużo czasu trzeba poświęcić na naukę by dobrze zrozumieć ideę frameworku. Ba! Wciąż jako zwolennik wszystkiego co agile uczę się i odkrywam nowe rzeczy. Zarówno w samym przewodniku jak i dzięki społecznościom wśród których można wymieniać się szeregiem dobrych praktyk. Ale do rzeczy!
Zdarzenia w Scrumie
W Scrum Guide możemy znaleźć rozdział zatytułowany “Scrum Events” i w nim szczegółowe omówienie poszczególnych zdarzeń:
Każde zdarzenie posiada jasny cel, strukturę, ramy czasowe i ma wspierać filary Scruma. Warte podkreślenia jest to, że o ile pierwsze trzy punkty są w miarę przez wszystkich przestrzegane, to niestety wspomniane filary często są czymś o czym zapominamy. Czymś co powoduje, że adaptacja Scruma po prostu nie wychodzi. Tak jak w moim przykładzie z początku artykułu.
Będąc uczestnikiem wdrażania Scruma, czy też weryfikowania zarzutów “czemu ten Scrum u nas nie działa?” niejednokrotnie widziałam jak zespoły wykorzystują tylko Retrospektywę do dokonywania inspekcji i adaptacji. Zapominają, o tym że każde zdarzenie powinno służyć znalezieniu miejsc do usprawnień i wyznaczeniu potencjalnych hipotez oraz planu na to jak je zweryfikować.
Other than the Sprint itself, which is a container for all other events, each event in Scrum is a formal opportunity to inspect and adapt something. These events are specifically designed to enable critical transparency and inspection. Failure to include any of these events results in reduced transparency and is a lost opportunity to inspect and adapt.
(Źródło: Scrum Guide, 2017)
Rozważmy to na konkretnym przykładzie
Sprint Review wspiera empiryzm dzięki możliwości inspekcji powstałego Przyrostu i dokonania na tej podstawie adaptacji Backlogu Produktu przez Scrum Team i zaproszonych interesariuszy. Jednocześnie każdy ma możliwość zobaczenia tego co zostało zaimplementowane, co wspiera już ostatni z filarów Scruma, czyli transparentność.
Wiele osób, z którymi miałam okazję współpracować dopiero po takim wytłumaczeniu wszystkich zdarzeń jak powyższe zaczynała rozumieć ideę empiryzmu procesu. Skupiliśmy się nie na zachowaniu struktury Scruma lecz na jego zrozumieniu, co w konsekwencji przełożyło się na efektywniejsze wykorzystanie zdarzeń. Nie zawsze jednak przytoczenie takiego wytłumaczenie jest wystarczające, niejednokrotnie jest to walka z wiatrakami. “Czy ja muszę iść na to demo?” to często słyszane zdanie od członków zespołu deweloperskiego. Podróż, której zwieńczeniem jest zrozumienie idei często jest drogą usłaną cierniami. Jako agenci zmiany nie możemy się jednak poddawać.
Definition of Done, czyli definicja ukończenia
Podczas każdego Sprintu należy też pamiętać o jego nadrzędnym celu, czyli o zbudowaniu Przyrostu potencjalnie gotowego do wydania. Taki Przyrost powinien być “ukończony”, tzn, że wszystkie PBI, które składały się na jego budowę powinny spełniać wymagania im postawione, czyli definicję ukończenia.
Each Sprint may be considered a project with no more than a one-month horizon. Like projects, Sprints are used to accomplish something. Each Sprint has a goal of what is to be built, a design and flexible plan that will guide building it, the work, and the resultant product increment.
(Źródło: Scrum Guide, 2017)
Problem związany z definicją ukończenia jaki najczęściej spotykałam, to po prostu jej brak. Zespoły przechodziły do zamykania kolejnych iteracji bez głębszej refleksji na temat tego co tak naprawdę dla nich oznacza to DONE. Kiedyś zaraz po daily spytałam developera, który powiedział “ja skończyłem te zadanie X, teraz robię Y” – co to znaczy, że skończyłeś zadanie? Trochę się jąkał i zmieszał, ale co najważniejsze sam doszedł do wniosku, że zakończył jedynie implementację. Później wspólnie z całym zespole usiedliśmy na Retrospektywie i ustaliliśmy naszą definicję pojęcia DONE. Całe to zdarzenie było inspiracją dla reszty organizacji do zaczerpnięcia wypracowanej definicji ukończenia do swoich zespołów.
Artefakty Scruma
Pisałam już o samych artefaktach Scuma i o tym, że często nawet osoby które rekrutują na stanowisko Scrum Mastera nie wiedzą ile ich tak właściwie jest. Dodatkowo często mylą pojęcia i nazewnictwo, dołączając do listy artefaktów np. Sprint Review. Trochę abstrakcja, ale jednak tak się dzieje. Jakiś czas temu natrafiłam na publikację na Scrum Alliance, której fragment znajdziecie poniżej:
Autorzy w kilku miejscach podkreślają, że są cztery artefakty Scruma.
Dziwi mnie to najbardziej przez to, że autorzy powołują się na oficjalną wersję Scrum Guide. Niejednokrotnie jednak zgadzają się z przewodnikiem. Na przykład piszą o Sprint Burndown Charts i podkreślają, że nie należy on do oficjalnej listy artefaktów.
Dlaczego mnie to dziwi? Ponieważ ludzie, którzy szukają miejsc w sieci do poszerzenia swojej wiedzy o Scrumie lub w ogóle miejsc w których mogą wiedzą na temat procesu znaleźć – często trafiają na takie strony. Przyswajają błędne informację i później uczą ich innych. To takie błędne koło. Scrum Alliance również prowadzi certyfikację i możliwość dołączenia do Scrummunity, gdzie takie informację są szerzone. W gwoli wyjaśnienia w Scrum Guide mamy wymienione tylko trzy artefakty Scruma i Sprint Goal do nich nie należy.
Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances.
(Źródło: Scrum Guide, 2017)
Tłumacząc samą ideę artefaktów Scruma często powoływałam się na filary procesu. A to dlatego, że jednym z ich zadań jest wspieranie podstaw procesu oraz empirycznego podejście do wytwarzania produktów.
Teoria a praktyka
Jak widać, to co mamy możliwość do przeczytania na 19 stronach Scrum Guide (w oryginalnej wersji językowej) często bywa błędnie zinterpretowane i w niewłaściwej formie przekazywane dalej. To z kolei powoduje, że adaptacja Scruma nie przebiega prawidłowo i często kończy się fiaskiem. Jako osoby szerzące Scruma powinniśmy dobrze się z nim zapoznać i zrozumieć nie samą strukturę procesu ale i ideę. Kiedyś to Scrum Master był odpowiedzialny za sukces Scruma:
The Scrum Master is responsible for the success of Scrum.
(Źródło: Agile Software Development with Scrum by Ken Schwaber and Mike Meedle (2002)
Dziś jest odpowiedzialny za szerzenie i zrozumienie teorii, praktyk, roli i wartości Scruma.
The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide. Scrum Masters do this by helping everyone understand Scrum theory, practices, rules, and values.
(Scrum Guide 2017)
Tytułem zakończenia chciałabym wszystkich entuzjastów procesu zaprosić do częstszego zaglądania do Scrum Guide i odkrywania w nim nowych fragmentów ‘WOW’. Jako odpowiedzialni za zrozumienie teorii Scruma jesteśmy zobowiązani do dobrego i pełnego jego zrozumienia oraz dbania o samorozwój.
Sprawdź nasze ostatnie wpisy:
![Read more about the article Czego warto słuchać? Top 5 podcastów o Agile i Scrum [en]](https://agilehunters.com/wp-content/uploads/2021/05/lee-campbell-GI6L2pkiZgQ-unsplash-scaled-e1621771993217-768x576.jpg)
