Scrum Guide 2020 – luźne przemyślenia

Scrum świętuje w tym roku swoje 25. urodziny. W prezencie otrzymaliśmy nową – mocno odświeżoną wersję przewodnika. W tym tekście znajdziesz kilka luźnych przemyśleń na gorąco po lekturze.

Nowy Scrum Guide

Nowa wersja jest odchudzona i jeszcze krótsza, bo lżejsza w stosunku do poprzedniej wersji o pięć stron (z 18-tu do 13-tu).

Czytając ją (i na bieżąco porównując z wydaniem z 2017) doszedłem do wniosku, że… jego poprzednia wersja była strasznie przegadana! Więc zmiana zdecydowanie na korzyść.

Warto wspomnieć, że premierze nowego Guide’a towarzyszyło oficjalne wydarzenie on-line. W jego trakcie Ken i Jeff opowiedzieli o nowościach w przewodniku, odbyły się dwa panele z ekspertami (m.in. o tym jak zmiany w treści wpłyną na naszą pracę), a na koniec odbyła się sesja Q&A z Sutherlandem. Zapis wydarzenia znajdziecie pod tym linkiem.

Jeśli po lekturze wspomnianych trzynastu stron odczuwać będziesz niedosyt – warto sięgnąć po stworzoną przez przyjaciół z CodeSprinters wersję rozszerzoną (37 stron), zawierającą obszerny komentarz Andy’ego Brandta i Rafała Markowicza.

A jeśli wciąż odczuwać będziesz niedosyt – zajrzyj do The Scrum Guide 2020 – Reordered autorstwa Stefana Wolpersa, który na blisko 60 stronach (ponownie) wywrócił treść SG do góry nogami. W dokumencie tworzy obszerne definicje dla poszczególnych haseł zestawiając wszystkie ich wystąpienia w treści Scrum Guide’a w jednym miejscu.

Wśród ważnych zmian warto wymienić choćby zamianę Zespołu Deweloperskiego w Deweloperów – nie mamy już zespołu w zespole, ale jeden Zespół Scrumowy. Składający się z jednego Scrum Mastera, jednego Product Ownera i Deweloperów. Nie są to już role (ani tym bardziej stanowiska), a odpowiedzialności osób. A do artefaktów – do Celu Sprintu i Definicji Ukończenia dołącza Cel Produktu.

Ale… nie zamierzam w tym miejscu listować wszelkich zmian, które pojawiły się w nowym dokumencie. Lada moment pojawią się z pewnością obszerne artykuły z takimi zestawieniami. W tej chwili szczegółową analizę znajdziecie choćby we wspomnianym ebooku CodeSprinters.

W dalszej części wylistuję kwestie, które mocno zarezonowały we mnie w trakcie pierwszej lektury.

Nowy Scrum Guide – subiektywnie

Inteligencja zbiorowa wchodzi do Scrum Guide’a

O inteligencji zbiorowej zaczęliśmy mówić w naszych prezentacjach w okolicach 2018.

Dziś debiutuje w Scrum Guidzie. W rozdziale z definicją Scruma znajdziemy zdanie, że zbudowany jest na inteligencji zbiorowej ludzi z niego korzystających („Scrum is built upon by the collective intelligence of the people using it.”). No i fajnie ?

Scrum Master jasno określony

Od zawsze jasnym było, czym zajmuje się zespół developerski – wykonuje pracę dostarczenia gotowego do potencjalnego wydania przyrostu na koniec każdego sprintu. Product Owner odpowiada za „maksymalizację wartości produktu i pracy Zespołu Deweloperskiego” (SG 2017). A Scrum Master? Poprzedni SG definiował, że jest „odpowiedzialny za to, by Scrum był rozumiany i stosowany” ?‍♂️.

Nowa wersja bardzo dokładnie określa zakres jego odpowiedzialności. W pełni zgadzam się z Kate Hobler – to nie tak, że wcześniej zakres jego odpowiedzialności nie był opisany. Ale nie był opisany tak bardzo wprost, jak ma to miejsce teraz.

Po pierwsze: informacja o tym pojawia się już w drugim zdaniu definicji Scruma („Scrum requires a Scrum Master to foster an environment where…„).

Scrum wymaga Scrum Mastera, który tworzy środowisko, w którym dzieją się wszystkie Scrumowe procesy.

Po drugie: Scrum Master nie jest już („tylko”) odpowiedzialny za rozumienie i stosowanie Scruma. Zostało powiedziane wprost: jest odpowiedzialny za wprowadzenie i stosowanie Scruma zgodnego ze Scrum Guidem.

Po trzecie: Scrum Master jest odpowiedzialny za efektywność Zespołu Scrumowego.

Oczywiście wszystkie powyższe kwestie znaleźć można było w poprzednich wersjach – czasem opisane większą ilością słów, czasem opisane między wierszami. Teraz pojawiają się w tak klarowny sposób.

Przeszkody i wydarzenia

W kontekście Scrum Mastera cieszą mnie jeszcze dwie kwestie:

usuwanie przeszkód ograniczających postępy prac Zespołu Dev („removing impediments…„) zastąpione zostało sprawianiem usuwania przeszkód („causing the removal of impediments„); w końcu Scrum Master nie jest tym, który jest odpowiedzialny za usuwanie wszystkich przeszkód (z czym spotkać można się było w dysfunkcyjnych zespołach), a jego rola sprowadzona jest do tego, który dba, by przeszkody były usuwane (np. ucząc zespół je dostrzegać i radzić sobie z nimi)
facylitacja wydarzeń scrumowych, gdy zostanie o to poproszony lub gdy będzie to potrzebne („facilitating Scrum events as requested or needed„) zastąpione zostało dbałością o to, by wszystkie wydarzenia Scrumowe odbywały się, były „pozytywne”, produktywne i trzymały się ram czasowych („ensuring that all Scrum events take place and are positive, productive, and kept within the timebox„); koniec z praktyką „Scrum Master prowadzący każde retro”!

Odpowiedzialności

Pamiętam bolesne doświadczenie, gdy w ramach usprawnienia pracy w zespołach zaproponowałem wprowadzenie macierzy RACI, by jasno określić kto w zespole jest za co odpowiedzialny. Problem, z którym się zderzyłem polegał na wspólnym zrozumieniu różnic pomiędzy poziomem R, czyli Responsible a A, czyli Accountable. W obu przypadkach polskie znaczenie to „odpowiedzialny„. Ba, google translator podpowiada nawet te słowa jako synonimy. W skrócie przyjmijmy, że:

odpowiedzialność w rozumieniu responsible to odpowiedzialność za fizyczne wykonanie pracy związanej z zadaniem (ja wykonuję daną pracę);
odpowiedzialność w rozumieniu accountable to wzięcie na siebie odpowiedzialności za fakt, że dane zadanie zostanie wykonane (czyli ja nie muszę wykonywać, ale zapewniam, że zostanie wykonane).

Nowy Scrum Guide definiuje, że cały Zespół Scrumowy jest odpowiedzialny (w rozumieniu responsible) za wszystkie aktywności związane z produktem. Czyli nie tylko Product Owner jest odpowiedzialny za kontakty z interesariuszami. Tak samo jak nie tylko Scrum Master jest odpowiedzialny za proces. Oznacza to również, że Product Owner nie musi samemu odpowiadać za uzupełnianie elementów Backloga – może je delegować na członków zespołu.

Równocześnie SG 2020 odpowiedzialność (w rozumieniu accountable) za wartościowy i użyteczny przyrost przenosi na cały Zespół Scrumowy. Oznacza to, że Product Owner już „nie tylko” jest odpowiedzialny za kolejność elementów Backloga, ale również za to, co powstanie na koniec sprintu.

Dodatkowo, nowy Przewodnik zastępuje role Product Ownera, Scrum Mastera i Developera konkretnymi odpowiedzialnościami (w rozumieniu accountable). Zdecydowanie zachęcam do eksploracji tego fragmentu Scrum Guide’a.

Pozytywne wydarzenia Scrumowe

Warto zaznaczyć, że w dbałości o „pozytywne” wydarzenia nie chodzi o to, by zawsze było milutko.

Pozwolę sobie zacytować komentarz Andy’ego i Rafała:

„(…) nie chodzi tu o dążenie do tego, by było „miło za wszelką cenę”, bo to sprzeczne będzie z postulatem produktywności. „Pozytywność”, o której mowa, związana jest z nastawieniem zdarzeń na rozwiązywanie problemów i otwieranie nowych możliwości, zamiast na rozliczenia i szukanie wymówek albo winnych. W szczególności Scrum Master ma spowodować, by Zespół nie powtarzał „nie da się”, tylko poszukał możliwości (tego, co „da się” zrobić).”

Cel retrospektywy

Celem retrospektywy jest plan podniesienia jakości i efektywności. Kropka.

Nie rozmowa o tym, dlaczego nam jest smutno. Nie rozmowa o tym, jak rozwiązać problemy w relacjach w zespole. W ramach tego wydarzenia powinniśmy przede wszystkim skupiać się na szukaniu usprawnień, mających na celu zwiększanie jakości realizowanej pracy oraz podnoszenia efektywności naszego zespołu.

Daily to nie jedyny czas na synchro!

Z dostępnej w wersji z 2017 definicji Codziennych Scrumów wyciągnąć można było mylne wnioski, że jest to jedyny czas i miejsce, w którym zespół może dokonać synchronizacji bieżących prac (często spotykałem się z takimi opiniami). Przejawia się to czekaniem z aktualizacją stanu zadań „do stand-upu” lub czekaniem z omówieniem w większym gronie napotkanych przeszkód na „poranne spotkanie”.

Wersja 2020 rozjaśnia tę kwestię, mówiąc wprost: Daily to nie jedyny czas, kiedy Deweloperzy mogą dostosować swój plan. Często spotykają się w ciągu dnia, by przedyskutować postępy prac i przeplanować dalszą część Sprintu.

Releasy częstsze niż co Sprint

Kolejnym mitem, z którym autorzy postanowili się rozprawić w nowym Scrum Guidzie były release’y raz na Sprint. Często stosowaną praktyką było czekanie z „wrzuceniem na produkcję” kolejnych aktualizacji na zakończenie Sprintu – a konkretniej na jego podsumowanie (Sprint Review).

„Podsumowanie Sprintu nigdy nie powinno być traktowane jako bramka do uwalniania wartości” („The Sprint Review should never be considered a gate to releasing value”) – tako rzekli Jeff i Ken.

Obrazowe wyjaśnienie czym jest produkt

W sekcji o Celu Produktu pojawia się jasna definicja czym w rozumieniu autorów przewodnika ów produkt jest:

(…) jest wehikiłem dla wartości. Posiada jasne granice, znanych interesariuszy, dobrze zidentyfikowanych użytkowników lub klientów. Produkt może być usługą, fizycznym produktem lub czymś bardziej abstrakcyjnym.

Warto zaznaczyć, że w tej wersji autorzy dołożyli wszelkich starań, by Scrum Guide i sam Scrum traktowane były jako przewodnik i framework o zastosowaniu znacznie już wykraczającym poza świat IT. Scrum sprawdził się już w tak wielu sektorach i branżach, że czas zacząć traktować go jako dużo bardziej wszechstronne narzędzie.