Każdy, nawet najlepiej działający niemiecki silnik diesla wymaga co jakiś czas serwisu. Serwis ten ma na celu sprawdzenie niezawodności działania jednostki i przygotowanie go do czekających go wyzwań. Przegląd ten możemy porównać do retrospektywy. Nie inaczej jest z silnikiem Scrum, czyli Scrum Guide.
Ten tekst dotyczy zmian z 2017 roku. Jeśli szukasz komentarza do Scrum Guide 2020, zapraszamy na nasz kanał na YouTube.
Retrospektywa Scrum Guide
Zmiany w Scrum Guide wprowadzone 7 listopada 2017 roku wynikają ze wciąż zmieniającego się świata. Rozpoczynając w 1995 roku pracę ze Scrum, autorzy nie mogli wiedzieć, że metodyka ta znajdzie zastosowanie nie tylko w procesie wytwarzania oprogramowania, ale również w wielu innych aspektach życia. Zgodnie z zasadą Inspect and Adapt dokonali oni retrospekcji założeń i wprowadzili niezbędne zmiany.
„Retrospektywa jest okazją dla Zespołu Scrumowego do przeprowadzenia inspekcji swoich działań i opracowania planu usprawnień, który zostanie wcielony w życie w najbliższym Sprincie” – Scrum Guide
Zmiany w Scrum Guide mają za zadanie przygotowanie go do wyzwań przyszłości.
Konstytucja Scrum
„Konstytucja” Scrum nie zmienia się za często. To słowo zresztą zostało tu użyte świadomie, bo podobnie jak np. Konstytucja Stanów Zjednoczonych Ameryki Północnej Scrum Guide został opisany na zaledwie kilkunastu stronach (19 stron Scrum Guide, 21 stron konstytucji USA).
Porównując Scrum Guide do podręczników innych metodyk (np. RUP) łatwo zauważyć różnicę na korzyść tego pierwszego. Z uwagi na samą wielkość podręcznika, nie ma w nim zbyt wielu miejsc, które mogą zostać udoskonalone.
Zmiany w Scrum Guide 2017
I faktycznie, przeglądając rejestr zmian łatwo możemy zauważyć, że większość modyfikacji dotyczy uszczegółowienia terminów używanych w Scrum Guide. Doprecyzowane zostały przypadki, w których użycie metodyki Scrum przyniosło sukces w skomplikowanym projektach (np. budowa autonomicznego samochodu).
Autorzy Scrum (nawiązując poniekąd do skalowanego Nexusa) zauważają, że Scrum Team realizując zakres przewidziany Product Backlogiem nie działa w próżni. Często jest częścią większej organizacji, która posiada swoje standardy, które z kolei my powinniśmy przestrzegać pracując zgodnie z zasadami Scrum. Co za tym idzie zmiany, które zespół wprowadza do Definition of Done podczas Sprint Retrospective powinny by zgodne ze wspomnianymi wyżej standardami organizacji.
Dodano definicję timebox, która w wyniku niedostatecznego wsparcia zespołów w kwestii nazewnictwa była często mylnie rozumiana jako wymagany czas wydarzenia. W obecnym wydaniu Scrum Guide użyto słów „at most”, które jasno wskazują, że chodzi o maksymalny czas trwania spotkań.
Scrum Master i jego rola
W ramach zmiany w Scrum Guide znajdziemy również nowe podejście do definicji ról i wydarzeń. Jedną ze zmian jest definicja roli Scrum Mastera.Według nowego brzmienia jest on odpowiedzialny za promowanie i wspieranie Scrum. Wyjątkowo ciekawie brzmi zapis dotyczący roli Scrum Mastera polegającej na wskazywaniu, które interakcje na przestrzeni Interesariusze – Scrum Team są wartościowe (i prowadzą do osiągnięcia celu sprintu), a które nie.
Podobnie rzecz ma się w odniesieniu do roli Scrum Mastera i jego wsparcia na rzecz Product Ownera. Scrum Master ma za zadanie upewnić się, że cele, zakres i domena tworzonego produktu są znane przez każdego członka Scrum Teamu.
DSM czyli Daily Scrum Meeting
„Rewolucyjna” zmiana dokonała się w odniesieniu do Daily Scrum. To zespół decyduje o tym, w jaki sposób te spotkanie zostanie przeprowadzone.
Mam wrażenie, że zmiana ta jest ukłonem w stronę „dorosłych” organizacji scrumowych, gdzie odchodzi się od odpowiadania na „trzy pytania” na rzecz weryfikacji aktualnego statusu sprintu poprzez przegląd np. Backlogu Sprintu lub zadań w Jira.
Zmiana ta spowoduje, że wiele zespołów nie będzie miało już dylematów w stylu „czy jesteśmy scrumowi nie odpowiadając na 3 pytania?„. W przypadku, gdy zespół dobrze się czuje odpowiadając na 3 doskonale znane pytania, nie ma potrzeby zmieniać tego podejścia. Bądźmy agile.
Continous Improvment czyli zmiany w Sprint Backlog
„Backlog Sprintu to zbiór elementów Backlogu Produktu wybranych do Sprintu rozszerzony o plan dostarczenia Przyrostu produktu i realizacji Celu Sprintu. Poprzez Backlog Sprintu Zespół Deweloperski prognozuje, które funkcjonalności znajdą się w kolejnym Przyroście i jaką pracę należy wykonać, aby te funkcjonalności dostarczyć w postaci „Ukończonego” Przyrostu.”- Scrum Guide
Stara definicja Backlogu Sprintu przytoczona powyżej już nie obejmuje wszystkich elementów, które muszą się w nim znaleźć zgodnie z nowym brzmieniem Scrum Guide 2017.
Panowie Schwaber i Sutherland polecają wprowadzić do Backlogu Sprintu co najmniej jedno usprawnienie procesu, które na ostatniej Retrospektywie zostało uznane przez zespół za najważniejsze. Ma to na celu podkreślenie procesu ciągłego doskonalenia i zwrócenie większej uwagi na wprowadzanie w życie najbardziej wartościowych usprawnień z punktu widzenia Scrum Team.
Rewolucja czy ewolucja?
Zdecydowanie ewolucja. Jak napisałem na początku, trudno jest zmieniać coś, co działa (dobrze) i zostało zapisane na (zaledwie) 19 stronach.
Większość zmian wprowadzonych przez autorów Scrum dotyczy doprecyzowania definicji zawartych we wcześniejszych wersjach Scrum Guide. Dwie największe modyfikacje mają na celu zbliżenie zapisów znajdujących się w Scrum Guide do praktyki stosowania Scrum w rzeczywistości projektowej.
Czy te zmiany w Scrum Guide były więc potrzebne? Tak, pokazują one, że twórcy Scrum śledzą sytuację na rynku i nie są głusi na zmiany pozwalające na łatwiejszą implementację zasad Scrum w ciągle zmieniającej się rzeczywistości.
Najnowsza wersja Scrum Guide (aktualna na listopad 2017) dostępna jest do pobrania ze strony scrumguides.org
