Scrum Guide 2017 — zmiany w przewodniku

utwor­zone przez | Lis 10, 2017 | Blog, Scrum­pe­dia | 0 komen­tarzy

Scrum Guide 2017 ujrzał światło dzi­enne 7 listopa­da 2017, nieco rok po ostan­im wyda­niu. Mając w pamię­ci doty­chcza­sowe tem­po wprowadza­nia zmi­an, moż­na powiedzieć, że to raczej szy­bko. Czy Scrum uległ zmi­an­ie? Czy poprzed­nia wer­s­ja Prze­wod­ni­ka po Scrum przes­tała być aktu­al­na? Nic z tych rzeczy.

Wprowad­zono pięć więk­szych poprawek i kil­ka mniejszych, które nie były ofic­jal­nie ogłos­zone ani sko­men­towane. Powo­dem zmi­an były głównie uwa­gi użytkown­ików Scru­ma zamieszczane na por­talu User Voice. Czy­ta­jąc nową wer­sję moż­na łat­wo zauważyć, że chodz­iło o bardziej jed­noz­naczne, dosad­nie określe­nie pewnych kwestii.

Przy okazji pub­licznego ogłoszenia nowego wyda­nia Ken Schwaber i Jeff Suther­land sko­men­towali kil­ka nieporozu­mień związanych ze złą inter­pre­tacją Scru­ma. Jeff Suther­land użył bard­zo trafnej metafory pod­sumowu­jącej zapędy do usuwa­nia ele­men­tów ze Scrum. Żeby zegarek pokazy­wał właś­ci­wą godz­inę, potrzeb­ne są wszys­tkie try­by, które razem spraw­ia­ja, że mech­a­nizm dzi­ała. Całe nagranie webi­na­ra zostało udostęp­nione na Vimeo.

Cho­ci­aż z 17 stron zro­biło się 19, to nową wer­sję Scrum Guide pod­sumował­by stwierdze­niem, nie zmieniło się nic.

 

5 dużych zmian

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

Zawartość Scrum Guide pow­ięk­szyła się o nowy dzi­ał, Uses of Scrum. W tym miejs­cu twór­cy frame­worku wymieni­a­ją inne oprócz roz­wo­ju opro­gramowa­nia obszary, w których Scrum jest z powodze­niem stosowany.Duże kor­po­rac­je rozu­mieją Scrum jako kole­jną zabawkę dzi­ału IT, która służy do oga­r­nię­cia pro­cesów wyt­warza­nia opro­gramowa­nia. Niedawno na blogu scrum.org pojaw­ił się wpis o stosowa­niu Scrum w policji w Ghanie. Frame­work ten jest na tyle uni­w­er­sal­ny, że równie dobrze pasu­je do mar­ketingu, trans­feru wiedzy, edukacji, budowa­nia sprzę­tu, insta­lacji sieci itd.

Jak to możli­we, że Scrum ma tak sze­rok­ie zas­tosowanie? Jego uni­w­er­sal­ność wyni­ka z braku narzu­conych tech­ni­ki pro­cesów. Wszys­tko opiera się na pra­cy małego zespołu ludzi, który jest w stanie zaadop­tować się szy­bko korzys­ta­jąc z pro­ce­su empirycznego.

Autorzy zas­trzegli w tym miejs­cu, że “devel­op­ment” jako określe­nie odnosi się do wykony­wa­nia złożonej pra­cy.

Nowe ujęcie roli Scrum Master

Będzie brakowało nam ele­ganck­iego sfor­mułowa­nia, że Scrum Mas­ter zapew­nia zrozu­mie­nie i wprowadze­nie Scru­ma (Scrum under­stood and enact­ed) w życie w całej orga­ni­za­cji. Tym razem mamy określe­nie, że Scrum Mas­ter pro­mou­je i wspiera Scrum w takiej postaci jak jest on opisany w Scrum Guide.

Ken i Jeff pokreślili w cza­sie webi­na­ra, że Scrum Mas­ter musi mieć pewne wyczu­cie tego na co orga­ni­za­c­ja jest gotowa w tym momen­cie. Wprowadzanie Scrum wyma­ga cier­pli­woś­ci i umiejęt­noś­ci mięk­kich takich jak poli­ty­czne.

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

Dai­ly Scrum, czyli najbardziej charak­terysty­czne we frame­worku spotkanie nadal potrze­bu­je dopre­cy­zowa­nia fun­da­men­tal­nych pod­staw. Może pamię­tasz, że jed­ną z różnic pomiędzy Scrum Guide 2011 i 2013 było pod­kreśle­nie skupi­enia na Celu Sprintu poprzez dodanie go do pytań, na które odpowiada­ją członkowie Zespołu Devel­op­er­skiego. Wygla­da na to, że ten zabieg nie wystar­czył. Nadal Zespoły Scru­mowe rozu­mi­ały Codzi­en­ny Scrum jako sta­tus przed Scrum Mas­terem lub Prod­uct Ownerem. Niek­tórzy uważa­ją, że Dai­ly Scrum to run­da “odklepa­nia” trzech pytań.

Na szkole­ni­ach wielokrot­nie pod­kreślam, że każde wydarze­nie Scrum to pęt­la sprawdź i dos­to­suj. Jeżeli połączymy wiedzę o tym, że pyta­nia sku­pi­a­ją się na celu Sprintu, to stanie się jasne, że w Dai­ly Scrum mamy skupić się na postępie i zde­cy­dować co było by najlep­szym planem do kole­jnego spotka­nia.

Oprócz pod­kreśle­nia, tego co powin­no być oczy­wiste, autorzy zwró­cili uwagę, że jest wiele sposobów prowadzenia tego spotka­nia. Trzy pyta­nia stały się jedynie przykład­owym sposobem prowadzenia tego spotka­nia.

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

Time-boxy czyli twarde ramy cza­sowe wydarzeń Scrum z wyjątkiem Sprintu samego w sobie mają określoną maksy­mal­ną dłu­gość. Oznacza to, że jeżeli osiągnęliśmy cel danego wydarzenia, to nie ma sen­su “odsiedzieć” resz­ty pozostałego cza­su.

Na przykład jeżeli Zespół Scrum zaplanował dwu­ty­god­niowy Sprint w ciagu pół godziny, to nie ma obow­iązku siedzieć na spotka­niu kole­jne trzy i pół godziny dla zasady.

Oczy­wiś­cie trze­ba pami­etać też o drugiej stron­ie time­boxa. Jeżeli nie udało się zaplanować Sprintu w ciagu czterech godzin, to spotkanie też się kończy i zaczy­na się pra­ca.

Sprint Backlog zawiera feedback ze Sprint Retrospective

Kole­jny raz Jeff i Ken pod­kreśla­ją znacze­nie Ret­ro­spekcji Sprintu, która ma służyć ciągłe­mu ulep­sza­niu. Zespół Scrum powinien ulep­szać swo­je pro­cesy wewnątrz Scrum i stawać się bardziej wyda­jnym. Nieste­ty bard­zo częs­to Ret­ro­spekc­je kończą się bez konkret­nych postanowień co zmienić w kole­jnym Sprin­cie. Zdarza się też, że nikt nie wie i nie pamię­ta co miało się zmienić lub nad czym mieliśmy pra­cow­ać. Dlat­ego autorzy wprowadzili do Scrum Guide prak­tykę ze Scrum Pat­terns Group pole­ga­jącą na zapisy­wa­niu przy­na­jm­niej jed­nego usprawnienia do Sprint Back­log.

Dzię­ki temu zabiegowi Zespół powinien łat­wo śledz­ić czy real­izu­je to ulep­sze­nie. Zawsze tłu­maczyłem zespołom, że postanowienia z Ret­ro­spekcji Sprintu powin­ny być umieszc­zone w widocznym miejs­cu. Jeżeli to jest pra­ca do wyko­na­nia, to powin­no to być odzwier­cied­lone w Sprint Back­log. Prak­ty­ka pod­powia­da mi, że za chwile pojaw­ią się wąt­ki w gru­pach scru­mowych na tem­at “To w jakiej formie mam zapisy­wać uspraw­ni­a­nia w Sprint Back­log?”.

Wyjaśnienie nieporozumień w interpretacji Scrum

Scrum zawiera więcej niż tworzenie oprogramowania

Korzys­ta­jąc ze Scrum budu­je­my użyteczne pro­duk­ty, w których opro­gramowanie jest jed­nym ze skład­ników. Poza tym nie tylko samo wyt­worze­nie powin­no być częś­cią Prod­uct Back­log. Wdroże­nie, szkole­nia i mar­ket­ing też powin­ny uwz­gled­nione na tej liś­cie, bo stanow­ią pracę do wyko­na­nia w pro­duk­cie.

Możesz wydawać częściej

Przy okazji kon­fer­encji i wypowiedzi różnych ekspertów z innych metod pra­cy moż­na było spotkać się ze stwierdze­niem, że Scrum ogranicza zespoły, bo pozwala na wydanie na pro­dukc­je tylko na koniec Sprintu. Jed­ną z takich wypowiedzi moż­na znaleźc w wywiadzie z Donem Rein­ert­sen­em.

Oczy­wiś­cie to nie jest praw­da. W Scrum Guide jest stwierdznie, że na koniec Sprintu ma być ukońc­zony przy­rost pro­duk­tu bez wzglę­du na to, czy Prod­uct Own­er chce go wydać. Nie wyk­lucza to posi­ada­nia przy­ros­tu w takim stanie wcześniej ani wydań przed końcem Sprintu. Prak­ty­ki Con­tin­u­ous Deploy­ment czy Con­tin­u­ous Deliv­ery jak najbardziej pasu­ją do Scrum.

Trze­ba też pamię­tać, że Sprint Review to nie jest bram­ka jakoś­ciowa w pro­ce­sie czy też spotkanie typu Go-No Go.

Scrum to także DevOps

Od pewnego cza­su obser­wu­ję z pewną fas­cy­nacją jak rozwi­ja się ruch DevOps. Przez książkę Phenix Project nie przeszedłem pomi­mo kilku prób. Pomysł, że jak będziemy chcieli instalować nowe przy­rosty samodziel­nie  na pro­dukcji, to to się nazy­wa DevOps i są do tego super narzędzia wydawał się dzi­wny. A dlaczego Zespół Devel­op­er­s­ki nie miał­by korzys­tać z Jenk­ins, Pup­pet, Dock­er? Dla mnie od zawsze wpisy­wało sie to ideę cross-func­tion­al team.

Głównie Ken Schwaber wyraźnie pod­kreślał, że pomysł nazy­wa­nia takie sposobu pra­cy osob­ną metodą i trak­towanie tego jak kole­jnej obiet­ni­cy rozwiąza­nia prob­lemów jest absurdalne. Bard­zo ciekawe jest zaz­nacze­nie, że zwłaszcza w pier­wszych Sprint­ach, kiedy dążymy do osiąg­nię­cia MVP powin­niśmy mieć spec­jal­istów od oper­acji, architek­tu­ry i infra­struk­tu­ry w Zes­pole. To też wyjaś­nia jak według twór­ców Scrum powin­no wyglą­dać to, co jest określane jako Sprint Zero.

Dąże­nie do jak najszyb­szego sprawdzenia gotowosci oper­a­cyjnej i wroże­nia pier­wszej użytecznej wer­sji pro­duk­tu jest prze­cież prostym sposobem na min­i­mal­iza­cję ryzy­ka.

Mniejsze zmiany w Scrum Guide

  • Scrum Mas­ter został też odpowiedzial­ny za pomoc Prod­uct Ownerowi w tym, że cele, zakres i dom­e­na sa zrozu­mi­ałe przez każdego w Scrum Team.
  • Pod­nosze­nie Def­i­n­i­tion of Done powodu­je, że stwarza­my pracę do wyko­na­nia (dlug tech­niczny) w poprzed­nich przy­rostach
  • Pojaw­iła się wiz­ja jako określe­nie. Każdy przy­rost pro­duk­tu to krok w kierunku osiąg­nię­cia wiz­ji lub celu
  • Scrum Mas­ter zapew­nia, że Sprint ret­ro­spec­tive jest poy­ty­wnym i por­duk­ty­wnym spotkaniem

Podsumowanie

Warto jest prze­jść szkole­nie z proffesjon­al­nym trenerem takie jak nasz Pro­fes­sion­al Scrum Mas­ter, żeby praw­idłowo zrozu­mieć Scrum. Wszys­tkie aspek­ty omaw­iane na tym webi­na­rze są omaw­iane przeze mnie na szkole­ni­ach od lat. Czy­tanie Scrum Guide bez właś­ci­wej intepre­tacji może szy­bko prowadz­ić do nieporozu­mień, a co gorsza do dys­funkcji.

Niesamow­itym osiąg­niem w moich oczach jest to, że dwóch ludzi stworzyło w 1993 roku sposób pra­cy, który jest do dzisi­aj aktu­lany i tak sze­roko stosowany. Jeff Suther­land pracu­je ze Scrum Alliance, a Ken Schwaber stworzył scrum.org. Nie przeszkadza to jed­nak ludziom, którzy spotkali się 30 lat temu pro­mować taką samą wiz­je Scrum.

Scrum Guide z założe­nia miał być jak najbardziej min­i­mal­isty­czny w formie i wycz­er­pu­ja­cy w przekazie. Nieste­ty tym razem Scrum Guide rozrósł się o dwie storny. Nie wszys­tko da się spisać, a tym bardziej nie wszys­tko da się tak napisać, żeby każdy zrozu­mi­ał. Ken Schwaber pod­sumował to bard­zo dosad­nie mówiąc “Scrum is not for peo­ple who can’t think”.