Blog

Ukazała się już uaktualniona wersja Scrum Guide – dokumentu, który stanowi definicję najpopularniejszej metody zwinnej, jaką jest Scrum. Jakie zmiany przynosi?

Szczegółowe omówienie możecie obejrzeć też na nagraniu z webinaru z dnia 19 listopada 2020.

Scrum Guide 2020 z komentarzemPobierz najnowszy Scrum Guide w formie e-booka z obszernym komentarzem Andy’ego Brandta i Rafała Markowicza.

Na początek warto podkreślić, że Scrum się nie zmienił: to wciąż framework („ramy postępowania”) oparty o empiryczną kontrolę procesu, umożliwiający rozwiązywanie złożonych problemów w zmiennym i nieprzewidywalnym środowisku.

Natomiast sam dokument oczywiście się zmienił. Jest zdecydowanie krótszy od poprzednich i zmieniła się jego struktura. Głównym celem jaki przyświecał autorom – Kenowi Schwaberowi i Jeffowi Sutherlandowi – było dalsze uproszczenie Scrum Guide, usunięcie rzeczy, które są w istocie praktykami (czyli mogą wewnątrz Scruma być robione na różne sposoby) oraz poprawienie sformułowań tak, by uniknąć nieporozumień.

Co się zatem zmieniło? W telegraficznym skrócie lista kluczowych zmian wygląda następująco:

• Role zastąpione zostały odpowiedzialnościami konkretnych osób, które w Zespole Scrumowym są Product Ownerem, Developerami i Scrum Masterem.
• Znikł koncept Zespołu Developerskiego, aby podkreślić, że cały Zespół Scrum ma za zadanie efektywnie dostarczać wartość interesariuszom.
• Jednoznacznie wskazana została odpowiedzialność Scrum Mastera za efektywność całego Zespołu Scrumowego.
• Każdy z artefaktów zaopatrzony został w zobowiązanie, które ma zapewnić skupienie Zespołu Scrumowego i przejrzystość artefaktu:
  • Cel Produktu związany jest z Backlogiem Produktu.
  • Cel Sprintu związany jest z Backlogiem Sprintu.
  • Definicja Ukończenia związana jest z Przyrostem.
• Z opisu elementów Scruma usunięte zostały sugerowane sposoby realizacji zdarzeń i pracy z artefaktami oraz praktyki jakich należy do tego używać.
• Usunięte zostały odwołania do praktyk związanych z wytwarzaniem oprogramowania, aby ułatwić użycie Scruma w innych dziedzinach.

W naszej ocenie najnowszy Scrum Guide nie przynosi fundamentalnej zmiany w metodzie i daje zespołom jeszcze większą swobodę w elastycznym jej użyciu, niż do tej pory. Mimo to mamy nadzieję się, że w wielu organizacjach i zespołach wywoła spore zamieszanie, które przyczyni się do poprawy jakości stosowania w nich Scruma. Odpowiedzialność za efekty i wartość pracy zespołu została w Scrum Guide 2020 zdefiniowana w sposób, którego nie da się pogodzić z marnymi praktykami i „zombie Scrumem”. Również traktowanie Product Ownera lub Scrum Mastera jako stanowiska pracy opisanego zestawem wykonywanych czynności nie pasuje do nowego Scrum Guide, bo już nie ma w nim ról.

Jeden Zespół

Koncept Zespołu Developerskiego – zbiorowej roli w Zespole Scrum – sprawiał wiele kłopotów i nieporozumień. Nie zawsze było wiadomo, o którym Zespole mowa, poza tym w praktyce dla większości użytkowników Scruma praktycznie bez znaczenia był Zespół Scrum, traktowany jako coś formalnego, o czym warto pamiętać jedynie podczas egzaminów certyfikacyjnych.

Dużo większym problemem jest to, że istnienie „zespołu w zespole” prowokowało do omawiania ról w Scrumie w taki sposób, jakby Product Owner funkcjonował obok prac odbywających się w Sprincie, a Scrum Master lewitował radośnie gdzieś w oddali. Zbudowało się i utrwaliło patrzenie na Sprinty i wytwarzanie wartości w nich jak na coś, co dotyczy wyłącznie Developerów.

Tymczasem Zespół Scrum jako całość ma konkretny cel: rozwiązywać złożone problemy tak, by osiągać z tego korzyści (by przynosiło to wartość) dzięki częstemu i regularnemu dostarczaniu ukończonych (ang. done) Przyrostów. To implikuje potrzebę dążenia do jak najwyższej efektywności Nie da się tego zrobić bez ścisłej współpracy Developerów z Product Ownerem i bez Scrum Mastera, który nauczy, jak używać Scruma i pomoże zbudować środowisko, w którym metoda ta ma szansę dobrze funkcjonować.

Najnowszy Scrum Guide definiuje więc tylko jeden Zespół Scrumowy, w którym znajdują się Developerzy, Product Owner i Scrum Master rozumiani nie jako „zawody” ale jako odpowiedzialności konkretnych osób w Zespole Scrum.

Odpowiedzialności zamiast ról

Bardzo często na pytanie, czym się zajmują, Scrum Masterzy i Product Ownerzy odpowiadają: „pełnię rolę Scrum Mastera / Product Ownera”. Dużo rzadziej słyszymy „jestem Scrum Masterem / Product Ownerem”. Przy czym nierzadko ci, co „pełnią rolę” nie czują odpowiedzialności, jaka się z tym wiąże, bo „rola” jest dla nich czymś tymczasowym, przerwą w pełnieniu innych (ważniejszych) obowiązków i „ról”. Natomiast ci, co „są Product Ownerem / Scrum Masterem”, potrafią zasklepić się w wąskich ramach definicji roli, traktując ją nierzadko jako osobny zawód i powstrzymując się od działań niezbędnych dla efektywności Zespołu, bo „nie pasują one” do ich rozumienia roli, w jakiej pracują.

Myślenie o rolach, a nie o konkretnych osobach, które przyjmują na siebie odpowiedzialność za coś, prowadzi do rozmycia tej odpowiedzialności. Nie służy to ani zapewnieniu przejrzystości, niezbędnej do empirycznej kontroli procesu, ani efektywności w działaniu (ot, choćby szybkiemu podejmowaniu decyzji).

Zespół Scrum składa się z ludzi, nie z ról. I to ci konkretni ludzie przyjmują na siebie jasno określone zobowiązania. Dlatego w nowym Scrum Guide zamiast o rolach jest mowa o odpowiedzialnościach.

I tu pierwsza ważna zmiana: cały Zespół Scrum odpowiada za zbudowanie wartościowego, działającego Przyrostu (jednego lub wielu kolejnych) w Sprincie. Zespół Scrum, a nie wyłącznie Developerzy. Scrum Master i Product Owner również. Są za to odpowiedzialni w znaczeniu angielskiego słowa accountable, bo choć niekoniecznie wszyscy będą „fizycznie” budować produkt, wszyscy odpowiadają za to by został zbudowany, był wartościowy i nadawał się do użycia (był ukończony).

Product Owner

Osoba będąca Product Ownerem odpowiada za wartość produktu. Ale uwaga: nie tylko za to, by zdefiniować, co nią jest, ale przede wszystkim za wartość tego, co powstało. Odpowiedzialność Product Ownera nie kończy się więc na zdefiniowaniu elementów Backlogu Produktu i określeniu ich kolejności. Odpowiada on również za wartość tego, co znajdzie się rzeczywiście w Przyroście, jaki wytworzą Developerzy. Bo to cały Zespół Scrum (a nie tylko Developerzy) dostarcza Przyrost interesariuszom / użytkownikom.

Developerzy

Osoby będące Developerami odpowiadają za wytworzenie Przyrostu, który jest nośnikiem wartości, jaką zidentyfikował Product Owner. Ale odpowiadają też za jakość produktu, a ciężko mówić o jakości, jeśli budowane jest coś, co nie ma wartości.

Dlatego Developerzy mają prawo i obowiązek wymagać od Product Ownera takiego działania, które pozwala uzyskać wartość. Tak samo mają prawo i obowiązek wymagać od Scrum Mastera pomocy w usuwaniu utrudnień (ang. impediments), które przerastają ich możliwości. I wreszcie mają prawo i obowiązek wymagać od siebie wzajemnie profesjonalizmu i przestrzegania ustalonych standardów pracy.

Scrum Master

Osoba będąca Scrum Masterem odpowiada za doprowadzenie do sytuacji, w której Zespół stosuje świadomie Scrum do uzyskiwania korzyści (wartości) przez interesariuszy. Scrum Master jest więc wprost odpowiedzialny za efektywność tego Zespołu.

Inaczej mówiąc Scrum Master ponosi odpowiedzialność za to, by Developerzy i Product Owner potrafili wywiązać się ze swych odpowiedzialności i faktycznie to robili. Z tego wynika konieczność pracy zarówno z Zespołem Scrum, jak i jego otoczeniem (organizacją, interesariuszami, klientami itd.).

Samozarządzanie zamiast samoorganizacji

Skoro w Scrumie jest tylko jeden Zespół, powinien on być samoorganizujący się. Przy czym pojęcie samoorganizacji, używane do tej pory, również mogło wprowadzać w błąd (nawet jeśli już przywykliśmy do niego). Jest to bowiem dużo starszy niż sam Scrum termin opisujący poziom autonomii zespołu (celowo małą literą, bo chodzi o dowolny zespół). Samoorganizacja w tym ogólnym znaczeniu to autonomia członków zespołu pozwalająca im decydować o jego składzie, odpowiedzialnościach, warunkach pracy itd.

Scrum nie wymaga aż tak wysokiego poziomu autonomii. Zespól Scrum organizuje sobie pracę w granicach i wedle zasad określonych przez organizację, która powołała Zespół do życia, określając kto będzie Product Ownerem i konstruując Zespół Scrumowy niezbędny do zbudowania produktu. W praktyce oznacza to, że Zespół Scrum sam zarządza swoją pracą – zarządza, czyli zapewnia jej efektywne wykonanie.

Dlatego nowy Scrum Guide, zamiast o samoorganizacji, pisze o samozarządzaniu Zespołu Scrum. Przy czym nic nie stoi na przeszkodzie, by organizacje gotowe na to, tworzyły Zespoły samoorganizujące się.

Zobowiązania względem artefaktów

Artefakty w każdym procesie powstają jako wytwór tego procesu. Są albo nośnikiem wartości, jaką przyniosło użycie procesu, albo narzędziem niezbędnym do podejmowania decyzji. Nie inaczej jest w Scrumie: każdy artefakt stanowi podmiot inspekcji, który w ramach poszczególnych zdarzeń jest sprawdzany tak, by zapewnić przejrzystość – postępu prac, procesu, stanu produktu itd.

Pewną trudność użytkownikom Scruma stwarzała Definicja Ukończenia, która nie stanowiła osobnego elementu frameworku, tylko związana była z Przyrostem. Jeszcze większy kłopot sprawiał Cel Sprintu, który jawił się wielu osobom jako coś wirtualnego, niekoniecznie wprost związanego z konkretnym artefaktem (a przecież powiązany jest z Backlogiem Sprintu).

Nowy Scrum Guide wzmacnia każdy z artefaktów zobowiązaniem (ang. commitment). Zobowiązania te są swoistymi umowami, jakie zawierają ze sobą członkowie Zespołu Scrum. Są więc deklaracją tego, co i jak Zespół Scrum zamierza zrobić oraz w jaki sposób będzie nad tym pracował.

Cel Produktu

To nowa rzecz, choć świadomych użytkowników Scruma w ogóle nie zdziwi. Jest to zobowiązanie związane z Backlogiem Produktu i ma zapewnić odpowiedź na pytanie o cel, dla którego Backlog Produktu ma w tym momencie taki a nie inny kształt. Zwykle będzie to cel pośredni ku pełniejszej realizacji wizji produktu, lepszemu zaspokojeniu potrzeb klientów czy użytkowników. Ponieważ jest tylko jeden Backlog Produktu i stanowi on listę (a nie szereg równoległych list), istnieć może logicznie tylko jedna odpowiedź na pytanie „czemu Backlog ma taką zawartość i kolejność”. Dlatego Cel Produktu może być również tylko jeden. Dopiero po jego osiągnięciu albo porzuceniu, można zdefiniować inny Cel Produktu.

Dlaczego Cel Produktu to zobowiązanie? Bo Zespół Scrum zobowiązuje się do realizacji tego Celu w serii kolejnych Sprintów, skupiając się na nim (nie marnotrawiąc czasu na działania zbędne dla osiągnięcia aktualnego Celu Produktu).

Za zdefiniowanie Celu Produktu, co oczywiste, odpowiada Product Owner, który następnie ma zarządzać Backlogiem Produktu tak, by ku temu Celowi wraz z całym Zespołem podążać. Istotna uwaga jest taka: ten Cel Produktu stanowi integralną część Backlogu Produktu – nie jest kolejnym jego elementem, ale musi być w Backlogu widoczny. Inaczej mówiąc, każdy użytkownik Backlogu Produktu musi widzieć (bez domyślania się i szukania gdzieś indziej) jaki jest Cel Produktu. Jak to zrobić – pozostaje w gestii Product Ownera, który oczywiście może, a nawet powinien, uzgodnić to z całym Zespołem Scrum.

Cel Sprintu

To istniejący koncept, który sprawiał mnóstwo problemów, co samo w sobie jest znamienne, bo przecież Cel Sprintu odpowiadał na pytanie „po co robimy ten Sprint?”. Brak dobrej odpowiedzi źle świadczył o sposobie, w jaki budowany jest Backlog Produktu i nie wróżył dużej efektywności Zespołu.

Nowy Scrum Guide czyni z Celu Sprintu zobowiązanie związane z Backlogiem Sprintu. Cel Sprintu – to nowość – ma być widoczny w Backlogu Sprintu tak, by bez domyślania się i dopytywania dało się określić nad czym pracuje Zespół.

Zmianie – subtelnej, ale bardzo istotnej – ulega też znaczenie Celu Sprintu. Od teraz ma stanowić on odpowiedź na pytanie „jaką wartość przyniesie ten Sprint interesariuszom?”. Cel Sprintu powinien też stanowić logiczny krok ku osiągnięciu Celu Produktu. W ten sposób karkołomne „składkowe” Cele Sprintu w rodzaju „zrobić wszystko” tracą rację bytu w Scrumie.

Dlaczego Cel Sprintu to zobowiązanie? Bo Zespół zobowiązuje się skupić na uzyskaniu tej wartości, której dostarczenie zdeklarował w trakcie Planowania Sprintu.

Warto zauważyć, że wynikiem istnienia takiego zobowiązania jest prawo Developerów, by oczekiwać od Scrum Mastera, Product Ownera lub innych Developerów zaangażowania w Sprint. Choć to głównie Developerzy pracują nad wywiązaniem się ze zobowiązania, jest ono wciąż zobowiązaniem całego Zespołu.

Definicja Ukończenia

To również istniejący od bardzo dawna koncept, jeden z kluczowych w Scrumie. Określa warunki, pod którymi wykonywane w Sprincie prace można uznać za ukończone. W praktyce determinuje, jakie cechy musi spełniać Przyrost i jaki powinien być proces jego wytworzenia, by Przyrostu można było użyć (potencjalnie, bo o faktycznym użyciu – lub wydaniu w przypadku niektórych produktów, np. oprogramowania – decydował Product Owner).

Nowy Scrum Guide czyni z Definicji Ukończenia zobowiązanie związane z Przyrostem.

Ponieważ mamy jeden Zespół Scrum, Definicja Ukończenia jest formułowana – na bazie standardów obowiązujących w organizacji – przez cały Zespół. Pamiętać przy tym należy o odpowiedzialnościach poszczególnych osób. Z tego wynika różny wpływ na formę i zawartość Definicji Ukończenia:

• Product Owner ma prawo i obowiązek oczekiwać, że Przyrost będzie miał wartość, a to wymaga zapewnienia, że produkt może być użyty – wynikną z tego wymogi formalne (np. istnienie dokumentacji, zgodność z normami prawnymi), niefunkcjonalne (np. wydajność, bezpieczeństwo, ergonomia) albo procesowe (np. formalna certyfikacja przez jakąś instytucję).
• Developerzy mają prawo i obowiązek oczekiwać, że Definicja Ukończenia odzwierciedlać będzie ich możliwości i standardy, wedle których chcą pracować, w tym te wynikające z ogólnych norm obowiązujących w organizacji.
• Scrum Master ma prawo i obowiązek oczekiwać, że Definicja Ukończenia nie obniży możliwości działania empirycznego i pozwoli na binarne stwierdzenie, czy jest spełniona, czy też nie (czy powstał Przyrost, czy nie).

Z tych różnych odpowiedzialności i konieczności ich pogodzenia powstanie Definicja Ukończenia taka, którą realnie posłuży się Zespół Scrum (cały, a nie sami Developerzy).

Definicja Ukończenia ma przy tym zapewnić przejrzystość tego, co to znaczy „ukończona praca” w tym konkretnym Zespole i dla tego konkretnego produktu. Czasami, skutkiem tego bywa ujawnienie różnicy między tym, co Developerzy potrafią wytworzyć, a czego potrzebuje Product Owner. Jak wybrnąć z tej sytuacji zależy indywidualnie od każdego Zespołu, ale kluczowe jest, by używana przez Zespół Definicja Ukończenia bezwzględnie odzwierciedlała to, co jest robione (a nie to, co kiedyś być może uda się zrobić).

Inspekcja, adaptacja i przejrzystość po nowemu

Trzy filary procesu empirycznego nie są niczym nowym, ale sposób, w jaki najnowszy Scrum Guide odnosi się do nich, jest wart komentarza.

Pierwsza istotna kwestia to podkreślenie, że celem inspekcji jest następująca po niej adaptacja. Inaczej mówiąc, dokonywanie sprawdzenia jest bezcelowe, jeśli nie towarzyszy temu gotowość realizacji działań dostosowujących, jeśli ujawni się taka potrzeba. Wydaje się to oczywiste, ale najwyraźniej nie jest takie dla wszystkich – w wielu zespołach zdarzenia Scrum zamieniają się w spotkania statusowe – z definicji służące zebraniu danych, ale nieprowadzące do podjęcia w oparciu o nie decyzji, nie mówiąc o działaniach. W ten sposób stają się one bezwartościową stratą czasu.

Druga zmiana to skupienie procesu empirycznego wprost na wartości dla interesariuszy (użytkowników, klientów itd.) i efektywności działania całego Zespołu Scrum. Przykładem takiej zmiany jest wskazanie, że sprawdzeniu na Przeglądzie Sprintu poddawany jest skutek powstania Przyrostu (ang outcome) a nie sam Przyrost – małe znaczenie ma, czy zrobiona została taka czy inna zmiana w produkcie, a kluczowe jest potwierdzenie, że jej dokonanie pozwoliło uzyskać oczekiwany efekt (dostarczyć wartość).

Wzmocnienie Scrum Mastera

Ważną zmianą, choć niepozorną, jest wzmocnienie osoby Scrum Mastera, którego odpowiedzialności zostały w końcu nazwane wprost:

• Stworzyć środowisko, w którym możliwe jest wykorzystanie empiryzmu do rozwiązywania złożonych problemów.
• Zapewnić, że Scrum jest używany świadomie i w sposób zgodny z definicją zawartą w Scrum Guide – przy czym chodzi to o faktyczne działanie wedle zasad frameworku a nie wytworzenie pozornych artefaktów i realizowanie zdarzeń w sposób pozbawiony empiryzmu.
• Zapewnić efektywność działania Zespołu Scrum – rozumianą jako umiejętność użycia praktyk niezbędnych do regularnego i częstego dostarczania wartości interesariuszom.

Bycie „mistrzem ceremonii”, człowiekiem od „robienia, by było miło” i „rozsiewaczem magicznego pyłku” nie pozwoli się z tych odpowiedzialności wywiązać. Podobnie jak zapomnienie lub brak świadomości, że Scruma używa się po to, by interesariusze zyskali więcej wartości, niż kosztuje ich inwestycja w zespół.

To ważna zmiana przede wszystkim dlatego, że dla wielu osób Scrum Master stał się stanowiskiem pracy, a nierzadko osobnym zawodem. Ze stanowiskiem i zawodem wiążą się konkretne umiejętności i obowiązki – rozumiane jako określone czynności – ale niekoniecznie odpowiedzialność za skutki działania całego Zespołu. „Pełnienie roli Scrum Mastera” często rozmijało się z dążeniem do tego, by Scrum używany w Zespole faktycznie przynosił wartość interesariuszom, bo wysiłki szły na przykład na „rozwijanie relacji” między Developerami (rzecz ważna, ale drugorzędna, środek do celu a nie cel sam w sobie).

Tymczasem organizacja ma prawo (obowiązek nawet) wymagać od Scrum Mastera, by ten doprowadził Zespół (Developerów i Product Ownera) do możliwości częstego i regularnego dostarczania wartości dla interesariuszy. To kluczowa odpowiedzialność, zwłaszcza biorąc pod uwagę, że Scrum Master nie jest kierownikiem Zespołu i nie może wydawać poleceń ani zlecać wykonania konkretnych działań członkom Zespołu.

Nowy Scrum Guide może sprawić kłopot wielu Scrum Masterom, którzy trzymają się z dala od „tematów developerskich” i są nietechniczni, ale pracują z zespołami mocno technicznymi, budującymi produkty silnie oparte o technologię. W praktyce mogą nie mieć szans, by wywiązać się z odpowiedzialności, jaka na nich spoczywa, o ile szybko nie zaczną się tych „tematów developerskich” uczyć. Bez podstawowej choćby wiedzy o tym co większość zespołu – czyli Developerzy – robi przez większość czasu pracy w Scrumie (czyli przez większość Sprintu) tacy Scrum Masterzy nawet nie będą mogli stwierdzić, czy Zespół jest efektywny, już nie mówiąc o pomocy w efektywności tej podnoszeniu.

Scrum to narzędzie

Scrum Guide 2020 przypadł nam do gustu z wielu powodów – prostota opisu, koncept odpowiedzialności, jeden Zespół – to naprawdę dobre zmiany. Przy czym widzimy te zmiany jako lepsze, bardziej dobitne, jasne wyrażenie tego, czym Scrum był zawsze, a co niestety przez te lata stało się mniej czytelne.

W naszym odczuciu nowy Scrum Guide lepiej opisuje Scrum taki, jakim go poznaliśmy lata temu – i jakim zawsze postrzegaliśmy. W szczególności wyraźniej, niż do tej pory, widać w nim, że Ken Schwaber i Jeff Sutherland oferują narzędzie zarządzania – proste, choć wymagające świadomego użycia, jeśli chce się uzyskać korzyści przy jego pomocy. Nie owijają też w bawełnę i piszą wprost: wartość, to korzyść, jaką dla interesariuszy wytwarza Zespół Scrum.

W czasach, gdy ruch Agile i Scrum będący jego częścią również, zaczyna być traktowany jako „filozofia”, „zawód” czy nawet „styl życia” – ten nowy Scrum Guide pozwala mieć nadzieję na przywrócenie niektórym pojęciom ich pierwotnego zdarzenia.

Kiedy zmienią się szkolenia i egzaminy Scrum.org?

Do 9 stycznia 2021 włącznie, egzaminy certyfikacyjne będą zdawane według Scrum Guide 2017. 10 stycznia 2021 egzaminy będą niedostępne. Od 11 stycznia 2021 egzaminy będą się odbywać zgodnie z nowym Scrum Guide 2020.

Wszystkie kody pozwalające przystąpić do egzaminów zachowają ważność. Zmiana jest wprowadzana stopniowo, aby dać przystępującym do egzaminów czas na zapoznanie się z nowym Scrum Guide. Scrum.org uważa, że byłoby nie fair kazać ludziom natychmiast zdawać egzaminy według nowego Scrum Guide, z którym nie mieli okazji się wcześniej zapoznać.

W związku z tym również materiały szkoleń certyfikacyjnych nie będą zmienione do końca bieżącego roku. Natomiast w każdym naszym szkoleniu znajdzie się blok poświęcony omówieniu zmian wprowadzanych w Scrum Guide 2020.