The Scrum Guide is Dead — Long Live the Scrum Guide!

Ken Schwaber i Jeff Sutherland co kilka lat wydają kolejną wersję „Scrum Guide”, czyli przewodnika po najpopularniejszym frameworku agile – Scrumie. To dokument wyczerpująco opisujący ramy postępowania w rozwiązywaniu problemów z uwzględnieniem ról, zdarzeń, artefaktów i reguł. W listopadzie 2020 roku pojawiła się jego długo wyczekiwana aktualizacja. Nowy “Scrum Guide 2020” przynosi szereg bardzo ciekawych i dobrych zmian, które nadają całemu procesowi jeszcze większej elastyczności.

Najpierw omówmy krok po kroku zmiany tej metodologii agile, przedstawione na scrum.org (na stronie dostępny jest także “Scrum Guide” po polsku; polski tytuł to “Przewodnik po Scrumie”)

---

1. Jeszcze mniej nakazów

“Scrum Guide” obrósł z biegiem lat pewnymi nakazami. Ken Schwaber i Jeff Sutherland postanowili przywrócić w roku 2020 Scrum do postaci podstawowych ram postępowania – poprzez usunięcie postanowień nakazowych z treści przewodnika, a przynajmniej złagodzenie nakazów (i tak np. usunięto codzienne pytania z Daily Scrum, rozluźniono wymagania dotyczące atrybutów PBI oraz pozycji przeszłych (retro) w rejestrze zadań przebiegu (Sprint Backlog), skrócono część anulowania przebiegu (sprintu) itd.).

>>

Co to znaczy?

Obecnie jest tyle implementacji Scruma, co produktów, w których Scrum wykorzystano jako podstawowe podejście SDLC. Zmiany w “Scrum Guide 2020” czynią ramy postępowania Scruma nieco bardziej elastycznymi. Dlaczego? Przeanalizujmy to dokładnie:

1. Nie trzeba bezwzględnie używać pytań z Daily Scrum. Ważne jest, by ludzie mogli wysłuchać innych, dzielić się opiniami i w razie potrzeby zasięgnąć pomocy. Rozmowę w zespole można stymulować na wiele sposobów, dlatego też nie powinniśmy się ograniczać pytaniami lub stwierdzeniami takimi jak, na przykład, „co zrobiłem”, „co zrobię” i „jakie są przeszkody”.
2. W przypadku PBI (pozycji rejestru wymagań – Product Backlog) dobrze jest zawsze zadbać o wystarczający poziom szczegółowości, wielkości, wartości itd. Jednakże pozycje takie powinny odpowiadać potrzebom i domenom biznesowym. Dlatego PBI nie ograniczają się wyłącznie do takich atrybutów. Złagodzenie wymagań wobec atrybutów PBI zwiększa elastyczność metodyki i pozwala uniknąć konieczności porządkowania.
3. Pozycje przeszłe mają od teraz skróconą postać. Autorzy po prostu nakreślają kluczowe aspekty, które należy omówić podczas spotkania retrospektywnego. Istnieją dziesiątki narzędzi umożliwiających wybór takiego podejścia do retrospektywy, które najlepiej sprawdzi się w danym zespole. Ogólniej rzecz ujmując, znosi to nakazy określające, kto ma konkretnie co robić, a pozwala skupiać się raczej na wynikach prac.
4. Skrócono inne zapisy przewodnika po Scrumie, przez co stały się bardziej czytelne – nie przytłaczają opisu procesu informacjami o oczywistych skutkach pewnych czynności, np. efektów odwołania przebiegu/sprintu.

---

2. Jeden zespół pracuje nad jednym projektem

Celem tej zmiany było usunięcie koncepcji powoływania oddzielnej komórki w zespole projektowym, której obecność wymagała „przedstawiciela” lub podziału na „my i oni” między PO i zespołem developerów. Przewodnik “Scrum Guide” obecnie zakłada istnienie jednego zespołu Scrum pracującego nad jednym i tym samym celem, z podziałem odpowiedzialności na trzy obszary: Product Ownera, Scrum Mastera i developerów.

>>

Co to znaczy?

W poprzedniej wersji przewodnika nie przewidziano podrzędnych zespołów, komórek w zespole developerów – w najnowszej wersji takie podejście objęło szczebel całego zespołu Scrum. Mentalność „my i oni” usunięto po raz pierwszy w wydaniu z 2011 r., rezygnując z porównania do „kur i prosiaków”. Logicznym krokiem było zatem, w obecnym wydaniu, usunięcie podziału na zespoły PO i developerów. Wielkość zespołu w obecnej wersji przewodnika odpowiada wielkości całego zespołu Scrum , nie zaś wyłącznie zespołu developerów (a więc także Product Owner i Scrum Master). W wydaniu “Scrum Guide” z 2020 r. zaleca się (choć zapis ten nie ma charakteru bezwzględnego), by zespół Scrum liczył nie więcej niż 10 osób, a także rozsądnie uzasadniono, dlaczego zespół mniejszy pracuje lepiej.

Cel tych zmian to zwiększona odpowiedzialność zespołu Scrum za produkt i proces. Im ściślej członkowie współpracują ze sobą, tym lepiej wychodzi im realizacja naprawdę wartościowych produktów. Odpowiedzialności Product Ownera, Scrum Mastera i developerów działają w ramach wspólnego celu.

---

3. Wprowadzenie pojęcia „celu produktu”

Przewodnik “Scrum Guide” w wersji z 2020 r., obok Celu Sprintu i Definicji Ukonczenia wprowadza pojęcie „Product Goal”, czyli „celu produktu” – w założeniu ma ono skupić zespół Scrum na większym, bardziej wartościowym celu. Dlatego każdy przebieg (sprint) powinien zbliżać założony produkt coraz bardziej do ogólnego, znanego „celu produktu”.

>>

Co to znaczy?

Chyba najważniejszą z ostatnich zmian w ogólnej koncepcji ram postępowania w Scrumie jest pojęcie „celu produktu”. Metodyka Scruma trafiła do mnóstwa dziedzin wykraczających poza tworzenie produktów oprogramowania, z czego przecież wyrosła. Produktem może być zatem usługa, fizyczny wyrób lub coś bardziej abstrakcyjnego. W zależności od oczekiwanych wyników – w rozumieniu różnych podejść – można za produkt uznać wynik pośredni tych produktów, których wartość dzieli się na etapy kluczowe („kamienie milowe”) lub wydania („release’y”).

Cel produktu opisuje przyszły stan tworzonego produktu, dlatego należy przede wszystkim podążać za ustalonym celem i tym samym, w sposób ciągły, sprawdzać, czy zespół Scrum tworzy wartościowe produkty. Jeśli podczas kolejnego sprintu brakuje systematycznego dążenia do celu produktu, zespół Scrum może przysłowiowo zejść na manowce, skazując produkt na porażkę.

---

4. „Dom” celu przebiegu, „Definition of Done” (definicja ukończenia), a cel produktu

W poprzednich wydaniach przewodnika “Scrum Guide” opisano cel przebiegu (Sprint Goal) oraz definicję ukończenia (Definition of Done), lecz tak naprawdę nie określono ich tożsamości, tj. czym konkretnie są. Nie były w pełni artefaktami, lecz pojęciami związanymi z artefaktami. Jednakże wraz z wprowadzeniem „celu produktu”, wersja “Scrum Guide 2020” pozwala uściślić pozostałe dwa pojęcia. Tym samym od teraz wszystkie trzy artefakty mają „zobowiązania” („commitment”) wobec nich. W przypadku rejestru wymagań (Produkt Backlog), zobowiązaniem jest cel produktu, w przypadku rejestru zadań przebiegu (Sprint Backlog) jest to cel przebiegu, zaś dla przyrostu (Increment) jest to definicja ukończenia (Definition of Done – zauważmy, że zapisywana od teraz bez cudzysłowu). Zobowiązania wprowadzono, aby uściślić każdy z trzech omawianych artefaktów oraz by skupić się na postępach ich realizacji.

>>

Co to znaczy?

Zobowiązaniem jest chęć starannej pracy, włożenia wysiłku i poświęcenia czasu na jakieś zadanie lub czynność. Stworzenie artefaktu podyktowane powinno być chęcią osiągnięcia konkretnych celów. Dzięki „zobowiązaniom” możemy bezpośrednio powiązać pozycję rejestru wymagań (PBI) z pożądanym, oczekiwanym stanem naszego produktu. PBI staje się „przyrostem”, gdy spełni przesłanki zobowiązania „definicji ukończenia”. Zbiór przyrostów zgodnych ze zobowiązaniem „celu przebiegu” zbliża opracowywany produkt do jego stanu pożądanego, który z kolei nakreślono w zobowiązaniu „celu produktu”.

---

5. Samozarządzanie zamiast samoorganizacji

W poprzednich wydaniach przewodnika po Scrumie mówiono, że zespoły developerskie organizują się samodzielnie, określając niezależnie, kto ma wykonać daną pracę i w jaki sposób. Nowy “Scrum Guide” z 2020 r. skupia się raczej na zespole Scrum (Scrum Master, Product Owner i developerzy), a tym samym podkreśla istotność jego „samodzielnego zarządzania sobą samym” – wedle którego to zespół Scrum określa, kto ma wykonać daną pracę, sposób, w jaki ma ją wykonać, i nad czym będzie pracował.

>>

Co to znaczy?

Wprowadzenie właściciela produktu (PO, Product Owner) i developerów do jednego zespołu Scrum pozwala „wypłaszczyć” SDLC w taki sposób, aby lepiej uwzględnić aspekty do rozważenia podczas prac rozwojowych.

---

6. Trzy tematy planowania przebiegów

Poza tematami planowania przebiegu/sprintu będącymi kwestiami „co?” i „jak?”, w przewodniku po Scrumie na 2020 r. skupiono się na trzecim zagadnieniu związanym z celem przebiegu – „Dlaczego?”.

>>

Co to znaczy?

To bardzo proste. Na etapie planowania sprintu, PO (właściciel produktu) proponuje, w jaki sposób wartość produktu może wzrosnąć w ramach obecnego przebiegu. Następnie cały zespół Scrum pracuje nad ustaleniem celu przebiegu, który jest odpowiedzią na pytanie, dlaczego przebieg ma wartość dla osób nim zainteresowanych.

Kolejność planowania sprintu: Dlaczego? -> Co? -> Jak?

Jest to jednocześnie kolejna okazja, by sprawić, że bieżący cel przebiegu zwiększy wartość produktu. W takiej metodzie planowania łączy się cel sprintu z celem produktu.

---

Scrum guide po polsku – przejrzystość w Scrumie

Przewodnik „Scrum Guide” na 2020 r. napisano językiem uproszczonym, bardziej zrozumiałym dla szerszego kręgu odbiorców. Przede wszystkim usunięto w nim złożone, zbędne zapisy oraz resztki nawiązań do pracy typowej dla sektora IT (np. testowanie, system, budowa, wymagania itp.). Najnowszy „Scrum Guide” liczy mniej niż 13 stron.

Dlaczego?

Bieżące wydanie ma język o charakterze mniej nakazowym, ponieważ, ze względu na współczesne realia i powszechność metodyki Scruma, jej podstawowe elementy powinny odpowiadać kontekstowi i zależeć od konkretnych produktów lub uwarunkowań, zamiast stanowić kompleksowe rozwiązanie, które pasuje tylko do pewnych produktów, a do innych już nie.

Od Scruma do GlobalLogic

Odkąd Ken Schwaber i Jeff Sutherland po raz pierwszy zaprezentowali Scruma w 1995 roku, stał się on jedną z najpopularniejszych metod Agile. Ta nazwa staje się kartą przetargową w CV, coraz więcej ludzi interesują materiały na ten temat i odbywa ze Scruma szkolenia. W roku 2020 Scrum, Agile czy Lean Management są już oczywistością dla osób realizujących projekty.

W GlobalLogic Agile to podstawa naszej pracy. Jeśli nie jest ci obcy, jeśli z pasją pracujesz od sprintu do sprintu, a przede wszystkim jeśli nazwa Scrum to budulec twojej drogi zawodowej – szukamy właśnie Ciebie. Utalentowany Scrum Master zawsze znajdzie u nas swoje miejsce. Aplikuj jeszcze dziś!