Scrum ma za sobą już całkiem długą historię. Warto zauważyć, że framework jeszcze przed oficjalnych wydaniem Scrum Guide przeszedł wiele metamorfoz. Począwszy od kategoryzowania Scruma jako metodologii i samej roli Product Managera do wyodrębnionej roli Scrum Mastera. Jednak gdyby ktoś był zainteresowany historią samego powstania frameworku odsyłam do pierwszej części serii. Tymczasem zapraszam do analizy tego jakie zmiany zaszły w Scrum Guide od 2010 roku do dnia dzisiejszego.
Grooming
W pierwszej wersji Scrum Guide zawierał wiele wskazówek dotyczących poszczególnych elementów frameworku. Jedną z nich był Product Backlog Grooming. Podczas tej aktywności Scrum Teamy miały zajmować się przeglądem i ulepszaniem elementów Product Backlogu.
W lipcu 2011 roku, w drugiej wersji Scrum Guide Grooming zajął już oficjalne miejsce w przewodniku, nie był już tylko wskazówką. Był wówczas aktywnością w czasie trwania Sprintu podczas której nad Product Backlogiem (PB) pracują wspólnie Product Owner i Development Team. Jednocześnie mógł być również aktywnością podczas której to sam Development Team pochylał się nad PB, jako ekspert domenowy. Wtedy nie było żadnej konkretnej struktury czy ram czasowych dla tej aktywności, a jedynie wskazówka, dotycząca długości. Autorzy wspominali, że pielęgnacja backlogu powinna trwać nie dłużej niż 10% czasu Development Teamu.
Sama definicja aktywności specjalnie się nie zmieniła na przestrzeni lat, zmianie uległa jedynie nazwa. W wersji z lipca 2013 można zobaczyć pierwsze zmiany w Scrum Guide. Wtedy to zastąpiono nazwę Grooming na Refinement po to żeby pozbyć się ewentualnego negatywnego brzmienia słowa. Dla mnie Refinement jest bardzo ważną aktywnością w samym procesie, bez niej nie wyobrażam sobie pracy nad produktem. Dla przykładu współpracę z każdym nowym zespołem i produktem zaczynam od sesji Refinementowej, często z użyciem Event Stormingu.
Chickens and pigs
Moim zdaniem zdecydowanie najbardziej kontrowersyjny i dość szybko usunięty zapis znajdował się w pierwszym wydaniu Scrum Guide’a. Pozwolę sobie zacytować oryginalny fragment, z którego to wzięła się inspiracja autorów w graficznej odsłonie:
Metafora, nawiązująca do Chickens and Pigs mówiła o tym, że wszyscy członkowie Scrum Team’u są “świniami”. Product Owner jest “świnią” odpowiedzialną za Product Backlog. Scrum Master jako “świnia” jest z kolei odpowiedzialny za przebieg procesu samego Scrum’a. Development Team można nazwać “świnią” odpowiedzialną za pracę w Sprincie. Brzmi to trochę dziwnie, prawda? Autorom chodziło o podkreślenie, że wszyscy inni są “kurami” i nikt, włączając w to wspomniane “kury”, nie może powiedzieć “świniom” jak powinny pracować. Jedną z odpowiedzialności Scrum Mastera było wówczas pilnowanie, żeby “kury” nie przeszkadzały i nie zabierały głosu na Daily Scrum.
Ta trochę dziwna historia, która spotkała się z negatywnym odbiorem i spowodowała, że zmiany w Scrum Guide nastąpiły już w jego drugiej odsłonie. Budziła ona wiele kontrowersji i podziałów nawet wśród członków zespołu czy organizacji. W międzyczasie dało się usłyszeć zdania typu: “I know I’m just a chicken, so I can’t say anything.” Dlatego Ken Schwaber i Jeff Sutherland zastąpili tę metaforę poniższą zasadą:
No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality.
(Źródło: Scrum Guide, 2010)
Moim zdaniem przekaz jest ten sam, ale brzmienie zupełnie inne. A wy co myślicie?
3 pytania na Daily Scrum
Już w pierwszej oficjalnej wersji przewodnika można znaleźć dobrze nam znane zdarzenie jakim jest Daily Scrum. Od początku ma ono za zadanie wspierać inspekcję i adaptację. Powinno odbywać się codziennie o tej samej porze, w tym samym czasie i nie trwać dłużej niż 15 minut. Podczas spotkania członkowie zespołu powinni odpowiedzieć na następujące pytania:
Rola Scrum Mastera w tym cyklu zdarzeń mocno nawiązuje do opisanej wyżej metafory o “kurach i świniach”. Ma on za zadanie pilnować żeby nikt poza Development Teamem nie brał udziału w spotkaniu ani go nie zakłócał. Dodatkowo do jego obowiązków należy również dbanie o to żeby każdy, kto zajmuje się przekształcaniem elementów Product Backlogu na Increment wypowiedział się na spotkaniu.
The Scrum Master also enforces the rule that chickens are not allowed to talk or in anyway interfere with the Daily Scrum.
(Źródło: Scrum Guide, 2010)
Daily Scrum zostało opisane w takie sposób, że mimo podkreślenia w samym przewodniku –
The Daily Scrum is not a status meeting
(Źródło: Scrum Guide, 2010)
to ze względu na formę obowiązkowych pytań stało się ono właśnie statusowym spotkaniem. Zupełnie nie nakierowanym na dokonywanie wyżej wspomnianej inspekcji i adaptacji naszej pracy w nawiązaniu do Celu Sprintu.
Zmiany w pytaniach
Po kilku latach bo już w lipcu 2011 dokonano kolejnej zmiany w Scrum Guide i pytania przeszły małą kosmetykę – zmieniono ich formę na bezosobową. Wtedy to dodano zapis o tym, że daily ma służyć zaplanowaniu pracy na kolejne 24h, (jeszcze bez konkretnego odniesienia do celu sprintu). W ten sposób chciano zapobiec statusowej formie spotkania. Tylko nieco później, w 2013 roku, pojawiły się kolejne zmiany , które jeszcze bardziej miały wzmocnić cel zadawania pytań. Zmieniono ich charakter w taki sposób, żeby maksymalnie nakierowywać odpowiadających na współpracę niezbędną do osiągnięcia Celu Sprintu. Oto jak wówczas brzmiały:
1. What did I do yesterday that helped the Development Team meet the Sprint
2. What will I do today to help the Development Team meet the Sprint Goal?
3. Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?(Źródło: Scrum Guide, 2013)
I tak oto przyszła kolej na ostatnią dostępną wersję Scrum Guide z listopada 2017. Pytania nie są już obowiązkowe, a ich forma nie uległa więcej zmianie.
Mają one jedynie pomóc Development Teamowi w prowadzeniu dyskusji. Ważny jest cel samego spotkania, a nie struktura, czyli zaplanowanie pracy na najbliższe 24 godziny. Pracę należy planować tak, żeby jak najbardziej zbliżyć cały zespół, do osiągnięcia Celu Sprintu.
Every day, the Development Team should understand how it intends to work together as a self-organizing team to accomplish the Sprint Goal and create the anticipated Increment by the end of the Sprint.
(Źródło: Scrum Guide, 2013)
Realizacja zadań ze Sprint Backlogu
Scrum Guide z 2010 opisuje powiązanie pomiędzy wybrany zadaniami z Product Backlogu a Sprint Goalem:
The Team has committed to a Sprint Goal, and to these Product Backlog items.
(Źródło: Scrum Guide, 2010)
Według pierwotnej wersji wszystkie zadania, które były omawiane na dwuczęściowej sesji planningu i których wykonanie deklarował się Development Team, musiały zostać zrealizowane podczas iteracji.
Niespełna rok po pierwszym wydaniu ukazała się kolejna wersja przewodnika. Wówczas Sprint Planning miał służyć jedynie zbudowaniu prognozy zbioru zadań (czyli Sprint Backlogu), w którego realizację wierzy Development Team i Product Owner. Nadrzędną rzeczą, którą miał kierować się DT był Sprint Goal. To on pozwalał im się maksymalnie skupić na najważniejszych zadaniach w Sprint Backlogu, które zbliżały ich do osiągnięcia celu. Dzięki niemu mogli na Daily Scrum tak zaplanować swoją pracę by być pewnym, że zdążą osiągnąć Cel przed ukończeniem Sprintu.
To Sprint Goal im przyświecał a nie realizacja wszystkich zadań. Elementy, które znalazły się w Sprint Backlogu mogły zostać wymienione z innymi Product Backlog Items. Oczywiście w taki sposób żeby nie wpłynąć na możliwość realizacji celu Sprintu. Dzięki takiemu rozwiązaniu, prognoza, wspierała filary Scruma i pozwalała na zachowanie transparentności, dokonywania inspekcji i adaptacji każdego dnia. Cel ten nie zmienił się na przestrzeni lat.
The Sprint Backlog is the set of Product Backlog items selected for the Sprint, plus a plan for delivering the product Increment and realizing the Sprint Goal. The Sprint Backlog is a forecast by the Development Team about what functionality will be in the next Increment and the work needed to deliver that functionality into a “Done” Increment.
(Źródło: Scrum Guide, 2017)
Podsumowanie
To tylko cztery z wielu zmian jakie zaszły na przestrzeni lat w Scrum Guide, jednak moim zdaniem jedne z bardziej znaczących. Gorąco zachęcam do przeczytania wszystkich poprzednich wersji przewodnika i odnalezienia tam innych ciekawostek – podzielcie się znaleziskami w komentarzach. Moim zdaniem metamorfoza jaką przeszedł Scrum Guide tylko potwierdza empiryczność samego frameworku.
O tym jak zmieniał się Scrum przed oficjalnym wydaniem Scrum Guide możecie poczytać w pierwszej części serii (Scrum ewolucja I).
Warto poczytać:
- Scrum.org – Chickens and Pigs
- Scrum.org – Forum
- Scrum Guides – Revisions
- Search Software Quality – Pigs and Chickens
- Scrum Guide – February 2010
Sprawdź nasze ostatnie wpisy:
