Scrum Guide 2020

Po trzech latach doczekaliśmy się kolejnej aktualizacji Scrum Guide’a. W niniejszym tekście postaram się odnieść do wg mnie najważniejszych zmian w kontekście potencjalnych korzyści, jakie owe zmiany mogą wywołać.

Koncentracja na wartościowych elementach produktu – LEAN

Dotychczasowe definicje używane w Scrum Guide dość jasno precyzowały, w jakim celu używamy Scrum’a. Dla wszystkich jasne było (i jest), że organizując pracę w Zespołach Scrumowych, chcemy dostarczać najbardziej wartościowy produkt, używając kreatywności i kolektywnej inteligencji zespołu. Myśląc o Scrumie, wiele osób łączyło podejście do budowania produktu z cechami podejścia Lean. Jak się okazało, był to był dobry trop. Nowy Scrum Guide oficjalnie wprowadza zakres filozofii Lean i jasno definiuje, na czym powinien skupiać się scrum team. Kluczem jest koncentracja na kluczowych elementach produktu, odrzucając, w miarę możliwości, elementy zbędne! Takie podejście pozwala skrócić czas wejścia na rynek, a co się z tym wiąże, poprzez szybszą pętlę zwrotną przetestować hipotezy biznesowe. Jednocześnie zachowane zostają zarówno jakość, jak i funkcjonalność wytwarzanego produktu. Takie podejście do budowania produktu cyfrowego sprawdza się idealnie w rozwoju startupów, co niejednokrotnie miałem okazję obserwować w Pragmatic Coders.

Empiryzm odpowiedzią na określenie niewiadomych

Drugim jasnym sygnałem zmian zawartych w nowym przewodniku jest podkreślenie istoty braku wiedzy, jaki towarzyszy budowaniu nowego produktu. Zespół Scrumowy ma umiejętności oraz doświadczenie potrzebne do realizacji projektu. Mimo to, jest prawie pewne, że pojawią się nowe wyzwania, bariery technologiczne itp. Wobec czego zespół ma nie tylko posiadać umiejętności potrzebne do budowy nowego produktu, lecz również cechy, które pozwolą rozszerzyć dotychczasową, lub nabyć nową wiedzę! Dla mnie to istotny przekaz, wskazujący cechę, którą powinien posiadać każdy członek zespołu. Mianowicie, otwartość na nowe wyzwania i chęć adaptacji na potrzeby realizacji celu.

Jasne określenie zależności pomiędzy filarami Scrum’a

Zaistnienie procesu empirycznego wymaga iteracyjnego stosowania procesów inspekcji i adaptacji. Opierają się one, jak opisano już w poprzednich wersjach przewodnika, o trzy filary Scrum’a (transparencja, adaptacja i inspekcja). W najnowszej wersji autorzy podkreślili silne zależności między wspomnianymi filarami. Pominięcie w stosowaniu Scruma choćby jednego z nich prowadzi do zaburzeń, w wyniku których Scrum jako metodologia/framework przestaje działać skutecznie. Wybiórcza implementacja zasad Scruma, może doprowadzić do wyniku odwrotnego niż zamierzony. Niestety zazwyczaj wiąże się to z poniesieniem znacznych kosztów własnych oraz opóźnieniem w dostarczeniu wartościowego produktu. Potwierdzają to moje rozmowy z osobami pracującymi w Zespołach Scrumowych, gdzie ten problem występuje.

Zaangażowanie i odpowiedzialność jako wartość zespołowa

Zaangażowanie i praca zespołowa są nierozerwalnie związane ze Scrumem. Zmiany wprowadzone w tym roku zbliżają w odpowiedzialności wszystkich członków zespołu. Zrezygnowano z modelu, w którym istnieje zespół deweloperski. Deweloperzy nigdy nie stanowili oddzielnego elementu Scrum’a. Jednak nazywanie deweloperów zespołem, wytwarzało błędne oczekiwania jego członków względem siebie.
Cały Zespół Scrumowy stanowi teraz centralny element Scrum’a. Ponadto poprzez wzrost autonomii zespołu (samozarządzanie) zwiększono też jego odpowiedzialność za wynik końcowy.
Jestem przekonany, że skutkiem wprowadzenia samozarządzania, będzie powiększenie możliwości adaptacji Zespołu Scrumowego do dynamicznie zmieniających się wymagań biznesowych.

Wartościowy przyrost produktu w każdym sprincie

Kolejna udana zmiana w nowym Scrum Guide związana z dostarczaniem wartości poprzez inkrementalny przyrost. Sprecyzowano, że Zespół Scrumowy pracuje iteracyjne, tak aby w każdym Sprincie dostarczyć wartościowy i w pełni funkcjonalny element produktu.
W mojej opinii kluczowy jest tutaj nacisk na słowo “każdy”. Takie postawienie sprawy wymusza pewne zachowania na zespole. Wynikiem tej zmiany będzie wytworzenie takich elementów backlogu (biorąc pod uwagę zakres prac), które dają możliwość cyklicznego dostarczania wartości.

Gdzie zmierzamy? – Product Goal

Product Goal to nowy artefakt Scrum’a, który wbrew pozorom wnosi bardzo dużo do procesu planowania i usystematyzowania prac. Widoczny staje się długoterminowy kierunek działania zespołu. Jasno określono: zakres pracy, granice produktu, zasięg, potencjalnych użytkowników itd. Sprecyzowany cel wprowadza więcej stabilności w zwinnym podejściu do zarządzania projektem. Ponadto, mając na uwadze Product Goal, Zespół Scrumowy będzie mógł lepiej zarządzać backlogiem. Pozwoli to skuteczniej realizować podejście Lean i znaleźć najbardziej wartościową, a zarazem najszybszą ścieżkę prowadzącą do wytworzenia produktu.

Definition of Done, wskaźnik dostarczenia przyrostu

Podoba mi się przeniesienie definicji “Definition of Done” (DoD) do sekcji “Increment”. Samo określenie, czym jest DoD, było jasno sprecyzowane już w poprzednich wersjach Guide’a. Doprecyzowanie istotności DoD oraz silne związanie tego artefaktu z samym przyrostem ucina wszelkie dyskusje o tym, co nazywamy przyrostem i kiedy się materializuje.

Podsumowanie

Oceniając nową wersję Scrum Guide’a, muszę przyznać, że twórcy zauważyli potrzebę zmian i odpowiedzieli na aktualne wymagania rynku.
Autorzy dostrzegli problemy w interpretacji zasad Scrum’a, z jakimi zmagają się zespoły w codziennej pracy. Doprecyzowanie definicji kluczowych elementów, a także zależności pomiędzy nimi oraz skrócenie zbędnych opisów, jest według mnie dobrą próbą rozwiązania wspomnianych problemów. Dodatkowo uogólnienie opisów zasad oraz odejście od języka bliskiego tylko branży IT, zachęcają odbiorcę do stosowania Scruma w innych gałęziach rynku.
Jestem przekonany, że nowa wersja Scrum Gudie’a spowoduje głębsze zrozumienie opisanej w nim metodologii i pozwoli na osiągnięcie jeszcze lepszych rezultatów wszystkim zespołom w niej pracującym.