Scrum Guide 2017 — zmiany w przewodniku

Scrum Guide 2017 ujrzał światło dzienne 7 listopada 2017, nieco rok po ostanim wydaniu. Mając w pamięci dotychczasowe tempo wprowadzania zmian, można powiedzieć, że to raczej szybko. Czy Scrum uległ zmianie? Czy poprzednia wersja Przewodnika po Scrum przestała być aktualna? Nic z tych rzeczy.

Wprowadzono pięć większych poprawek i kilka mniejszych, które nie były oficjalnie ogłoszone ani skomentowane. Powodem zmian były głównie uwagi użytkowników Scruma zamieszczane na portalu User Voice. Czytając nową wersję można łatwo zauważyć, że chodziło o bardziej jednoznaczne, dosadnie określenie pewnych kwestii.

Przy okazji publicznego ogłoszenia nowego wydania Ken Schwaber i Jeff Sutherland skomentowali kilka nieporozumień związanych ze złą interpretacją Scruma. Jeff Sutherland użył bardzo trafnej metafory podsumowującej zapędy do usuwania elementów ze Scrum. Żeby zegarek pokazywał właściwą godzinę, potrzebne są wszystkie tryby, które razem sprawiaja, że mechanizm działa. Całe nagranie webinara zostało udostępnione na Vimeo.

Chociaż z 17 stron zrobiło się 19, to nową wersję Scrum Guide podsumowałby stwierdzeniem, nie zmieniło się nic.

5 dużych zmian

Uses of Scrum, czyli gdzie można stosować Scrum

Zawartość Scrum Guide powiększyła się o nowy dział, Uses of Scrum. W tym miejscu twórcy frameworku wymieniają inne oprócz rozwoju oprogramowania obszary, w których Scrum jest z powodzeniem stosowany.Duże korporacje rozumieją Scrum jako kolejną zabawkę działu IT, która służy do ogarnięcia procesów wytwarzania oprogramowania. Niedawno na blogu scrum.org pojawił się wpis o stosowaniu Scrum w policji w Ghanie. Framework ten jest na tyle uniwersalny, że równie dobrze pasuje do marketingu, transferu wiedzy, edukacji, budowania sprzętu, instalacji sieci itd.

Nowe ujęcie roli Scrum Master

Będzie brakowało nam eleganckiego sformułowania, że Scrum Master zapewnia zrozumienie i wprowadzenie Scruma (Scrum understood and enacted) w życie w całej organizacji. Tym razem mamy określenie, że Scrum Master promouje i wspiera Scrum w takiej postaci jak jest on opisany w Scrum Guide.

Ken i Jeff pokreślili w czasie webinara, że Scrum Master musi mieć pewne wyczucie tego na co organizacja jest gotowa w tym momencie. Wprowadzanie Scrum wymaga cierpliwości i umiejętności miękkich takich jak polityczne.

Daily Scrum służy Sprawdzeniu i Dostosowaniu, żeby zapewnić postęp w kierunku Celu Sprintu

Daily Scrum, czyli najbardziej charakterystyczne we frameworku spotkanie nadal potrzebuje doprecyzowania fundamentalnych podstaw. Może pamiętasz, że jedną z różnic pomiędzy Scrum Guide 2011 i 2013 było podkreślenie skupienia na Celu Sprintu poprzez dodanie go do pytań, na które odpowiadają członkowie Zespołu Developerskiego. Wyglada na to, że ten zabieg nie wystarczył. Nadal Zespoły Scrumowe rozumiały Codzienny Scrum jako status przed Scrum Masterem lub Product Ownerem. Niektórzy uważają, że Daily Scrum to runda “odklepania” trzech pytań.

Na szkoleniach wielokrotnie podkreślam, że każde wydarzenie Scrum to pętla sprawdź i dostosuj. Jeżeli połączymy wiedzę o tym, że pytania skupiają się na celu Sprintu, to stanie się jasne, że w Daily Scrum mamy skupić się na postępie i zdecydować co było by najlepszym planem do kolejnego spotkania.

Oprócz podkreślenia, tego co powinno być oczywiste, autorzy zwrócili uwagę, że jest wiele sposobów prowadzenia tego spotkania. Trzy pytania stały się jedynie przykładowym sposobem prowadzenia tego spotkania.

Time-boxy mają maksymalną długość

Time-boxy czyli twarde ramy czasowe wydarzeń Scrum z wyjątkiem Sprintu samego w sobie mają określoną maksymalną długość. Oznacza to, że jeżeli osiągnęliśmy cel danego wydarzenia, to nie ma sensu “odsiedzieć” reszty pozostałego czasu.

Na przykład jeżeli Zespół Scrum zaplanował dwutygodniowy Sprint w ciagu pół godziny, to nie ma obowiązku siedzieć na spotkaniu kolejne trzy i pół godziny dla zasady.

Oczywiście trzeba pamietać też o drugiej stronie timeboxa. Jeżeli nie udało się zaplanować Sprintu w ciagu czterech godzin, to spotkanie też się kończy i zaczyna się praca.

Sprint Backlog zawiera feedback ze Sprint Retrospective

Kolejny raz Jeff i Ken podkreślają znaczenie Retrospekcji Sprintu, która ma służyć ciągłemu ulepszaniu. Zespół Scrum powinien ulepszać swoje procesy wewnątrz Scrum i stawać się bardziej wydajnym. Niestety bardzo często Retrospekcje kończą się bez konkretnych postanowień co zmienić w kolejnym Sprincie. Zdarza się też, że nikt nie wie i nie pamięta co miało się zmienić lub nad czym mieliśmy pracować. Dlatego autorzy wprowadzili do Scrum Guide praktykę ze Scrum Patterns Group polegającą na zapisywaniu przynajmniej jednego usprawnienia do Sprint Backlog.

Dzięki temu zabiegowi Zespół powinien łatwo śledzić czy realizuje to ulepszenie. Zawsze tłumaczyłem zespołom, że postanowienia z Retrospekcji Sprintu powinny być umieszczone w widocznym miejscu. Jeżeli to jest praca do wykonania, to powinno to być odzwierciedlone w Sprint Backlog. Praktyka podpowiada mi, że za chwile pojawią się wątki w grupach scrumowych na temat “To w jakiej formie mam zapisywać usprawniania w Sprint Backlog?”.

Wyjaśnienie nieporozumień w interpretacji Scrum

Scrum zawiera więcej niż tworzenie oprogramowania

Korzystając ze Scrum budujemy użyteczne produkty, w których oprogramowanie jest jednym ze składników. Poza tym nie tylko samo wytworzenie powinno być częścią Product Backlog. Wdrożenie, szkolenia i marketing też powinny uwzglednione na tej liście, bo stanowią pracę do wykonania w produkcie.

Możesz wydawać częściej

Przy okazji konferencji i wypowiedzi różnych ekspertów z innych metod pracy można było spotkać się ze stwierdzeniem, że Scrum ogranicza zespoły, bo pozwala na wydanie na produkcje tylko na koniec Sprintu. Jedną z takich wypowiedzi można znaleźc w wywiadzie z Donem Reinertsenem.

Oczywiście to nie jest prawda. W Scrum Guide jest stwierdznie, że na koniec Sprintu ma być ukończony przyrost produktu bez względu na to, czy Product Owner chce go wydać. Nie wyklucza to posiadania przyrostu w takim stanie wcześniej ani wydań przed końcem Sprintu. Praktyki Continuous Deployment czy Continuous Delivery jak najbardziej pasują do Scrum.

Trzeba też pamiętać, że Sprint Review to nie jest bramka jakościowa w procesie czy też spotkanie typu Go-No Go.

Scrum to także DevOps

Od pewnego czasu obserwuję z pewną fascynacją jak rozwija się ruch DevOps. Przez książkę Phenix Project nie przeszedłem pomimo kilku prób. Pomysł, że jak będziemy chcieli instalować nowe przyrosty samodzielnie  na produkcji, to to się nazywa DevOps i są do tego super narzędzia wydawał się dziwny. A dlaczego Zespół Developerski nie miałby korzystać z Jenkins, Puppet, Docker? Dla mnie od zawsze wpisywało sie to ideę cross-functional team.

Głównie Ken Schwaber wyraźnie podkreślał, że pomysł nazywania takie sposobu pracy osobną metodą i traktowanie tego jak kolejnej obietnicy rozwiązania problemów jest absurdalne. Bardzo ciekawe jest zaznaczenie, że zwłaszcza w pierwszych Sprintach, kiedy dążymy do osiągnięcia MVP powinniśmy mieć specjalistów od operacji, architektury i infrastruktury w Zespole. To też wyjaśnia jak według twórców Scrum powinno wyglądać to, co jest określane jako Sprint Zero.

Dążenie do jak najszybszego sprawdzenia gotowosci operacyjnej i wrożenia pierwszej użytecznej wersji produktu jest przecież prostym sposobem na minimalizację ryzyka.

Mniejsze zmiany w Scrum Guide

• Scrum Master został też odpowiedzialny za pomoc Product Ownerowi w tym, że cele, zakres i domena sa zrozumiałe przez każdego w Scrum Team.
• Podnoszenie Definition of Done powoduje, że stwarzamy pracę do wykonania (dlug techniczny) w poprzednich przyrostach
• Pojawiła się wizja jako określenie. Każdy przyrost produktu to krok w kierunku osiągnięcia wizji lub celu
• Scrum Master zapewnia, że Sprint retrospective jest poytywnym i porduktywnym spotkaniem

Podsumowanie

Warto jest przejść szkolenie z proffesjonalnym trenerem takie jak nasz Professional Scrum Master, żeby prawidłowo zrozumieć Scrum. Wszystkie aspekty omawiane na tym webinarze są omawiane przeze mnie na szkoleniach od lat. Czytanie Scrum Guide bez właściwej intepretacji może szybko prowadzić do nieporozumień, a co gorsza do dysfunkcji.

Niesamowitym osiągniem w moich oczach jest to, że dwóch ludzi stworzyło w 1993 roku sposób pracy, który jest do dzisiaj aktulany i tak szeroko stosowany. Jeff Sutherland pracuje ze Scrum Alliance, a Ken Schwaber stworzył scrum.org. Nie przeszkadza to jednak ludziom, którzy spotkali się 30 lat temu promować taką samą wizje Scrum.

Scrum Guide z założenia miał być jak najbardziej minimalistyczny w formie i wyczerpujacy w przekazie. Niestety tym razem Scrum Guide rozrósł się o dwie storny. Nie wszystko da się spisać, a tym bardziej nie wszystko da się tak napisać, żeby każdy zrozumiał. Ken Schwaber podsumował to bardzo dosadnie mówiąc “Scrum is not for people who can’t think”.