Można modyfikować Scruma. Ale czy warto? Recenzja książki „Successful ScrumButt”.

Książka, która już w tytule sygnalizuje czytelnikowi, że będzie opisywać jak naginać Scruma, powinna być ciekawą lekturą przede wszystkim dla Scrum Masterów, których jednym z głównych obowiązków jest stanie na straży integralności frameworka. Ja natomiast chciałbym skorzystać z okazji i skierować tę krótką recenzję również do osób, którym Scrum jawi się jako nadmiernie preskryptywny, narzucający zespołom masę sztywnych procedur i szczegółowych reguł. Jest to mit, z którym warto konsekwentnie walczyć.

Z czym zatem mamy do czynienia w przypadku „Successful ScrumButt”? Czy autor pojechał podejściem „Full Scrum Butt” łamiąc każdą z ledwie kilku reguł, których Scrum wymaga jako framework procesów? A może „Successful ScrumButt” jest jak film „The Room” tak zła, że aż dobra? Pozostając w klimatach kinowych, pozwolę sobie na spoiler: jest jeszcze inaczej.

Oceniając całościowo, jest to całkiem przyzwoita i przystępnie napisana książka, a co zaskakujące, największe odstępstwa od Scruma pojawiają się nie w sekcjach zatytułowanych ScrumButt, a w częściach je poprzedzających, mających pokazać jak wygląda Scrum zastosowany poprawnie. Posługując się kilkoma przykładami z książki, chciałbym pokazać, do jakich nieporozumień prowadzi m.in. brak rozróżnienia pomiędzy minimum reguł, jakich Scrum wymaga, aby możliwa była inspekcja i adaptacja, a całą gamą komplementarnych praktyk, z którymi zespoły mogą eksperymentować już w ramach frameworka i pięciu pętli sprzężenia zwrotnego, jakimi są Sprint, Daily Scrum, Planning, Review i Retro.

Już na samym początku Noah Dyer słusznie zauważa, że rozwijanie oprogramowania to bardzo złożony proces i tradycyjne podejście polegające na intensywnym planowaniu, a potem trzymaniu się tego planu za wszelką cenę, po prostu nie działa (na potwierdzenie czego przytacza kilka przykładów z własnego doświadczenia). Jako jeden ze sposobów poradzenia sobie z tym problemem proponuje zastosowanie Scruma, ale… no właśnie.

Pełen tytuł książki brzmi „Successful ScrumButt: Learn to Modify Scrum Project Management for Student and Virtual Teams”, a zatem kierowany jest do studentów oraz „zespołów wirtualnych” (zdalnych, rozproszonych), które według autora mogłyby bardzo skorzystać pracując w Scrumie, ale z uwagi na nietypową specyfikę organizacji pracy i rozproszenie geograficzne, nie mogą sobie na to pozwolić bez wprowadzenia pewnych modyfikacji do samego frameworka.

Zanim przejdę dalej kilka słów o tym, czym jest ScrumBut albo ScrumButt (pun intended I guess ¯\_(ツ)_/¯ ). Pojęcie to powstało około 10 lat temu i opisuje podejście, które można streścić jednym zdaniem „Pracujemy w Scrumie, ale [zintegrowany inkrement oprogramowania mamy raz na pół roku | mamy trzech Product Ownerów | nie mamy Scrum Mastera | etc.]. Jest to pewnego rodzaju wymówka, wynikająca z naturalnej niechęci do zmiany i do kwestionowania status quo (popularne, choć nie zawsze słuszne, „działa – nie ruszaj”). Z mojego doświadczenia, postawa ta jest najbardziej widoczna na poziomie middle-managementu. Zamiast realnie zmienić sposób, w jaki pracują zespoły, łatwiej jest zmodyfikować Scruma, przykrywając problemy, które ujawnił, jednocześnie zachowując (przynajmniej w warstwie deklaracji) status zwinnej organizacji.

Od jakiegoś czasu Ken Schwaber, współtwórca Scruma, sugeruje odejście od tego pojęcia i zastąpienie go hasłem ScrumAnd, czyli „Pracujemy w Scrumie i [co sprint mamy solidnie przetestowany i gotowy do wypuszczenia inkrement oprogramowania | mamy Product Ownera z wizją produktu | mamy Scrum Mastera rozumiejącego wartości stojące za podejściem zwinnym, nie tylko mechanikę | etc.]. Więcej na ten temat można przeczytać na blogach Kena Schwabera i Gunthera Verheyena.

Wracając do książki, struktura większości rozdziałów wygląda następująco: najpierw omawiany jest któryś z elementów Scruma (rola, zdarzenie, artefakt), a na koniec rozdziału autor sugeruje pewne modyfikacje Scruma dostosowujące się do zespołów studenckich/wirtualnych. Główną tezą książki jest założenie, że bez modyfikacji zespoły wirtualne i studenckie nie będą w stanie pracować w Scrumie.

Paradoksalnie więcej problemów i nieporozumień znajduje się w pierwszych częściach rozdziałów, a sporo sugestii w sekcji ScrumButt w żaden sposób nie łamie żadnej z reguł Scruma. Przyjrzyjmy się zatem na kilku przykładach, jak się mają do siebie interpretacja autora tego, co jest częścią Scruma, a co jest jego (konieczną) modyfikacją.

Product Backlog

Nieporozumienie

W kilku miejscach autor sugeruje, że User Stories są elementem Scruma. Może to tylko skrót myślowy, ale z uwagi na to, że jest to dość częste nieporozumienie, chciałbym podkreślić, że Scrum nigdy nie narzucał i nie narzuca używania User Stories. Jest to jedna z technik, którą można zastosować w ramach Scruma jako frameworka, nie jest natomiast jego częścią. Słyszałem o zespołach, które rezygnowały ze Scruma m.in. dlatego, że nie lubiły formatu User Stories. Szkoda.

Scrum Butt

Propozycją nagięcia Scruma, jeśli chodzi o Product Backlog jest sugestia, aby zespoły wirtualne zamiast fizycznego Backloga (karteczki samoprzylepne na ścianie) używały arkusza online. Problem w tym, że Scrum nigdzie nie narzuca gdzie i w jaki sposób ma być przechowywany Product Backlog, a zatem nie ma tu czego naginać. Backlog ma być transparentny i dostępny dla wszystkich zainteresowanych, ma umożliwić zespołowi Scrumowemu inspekcję i adaptację, nie musi natomiast mieć arbitralnie narzuconej formy. Jeśli zespół będzie chciał go przenieść ze ściany do Excela lub z JIRY na ścianę to nic nie stoi na przeszkodzie.

Planowanie Sprintu

Nieporozumienie

Rozdział na temat Planningu rozpoczyna się stwierdzeniem, że Sprint jest obietnicą daną Product Ownerowi ile pracy zostanie wykonane. Nic bardziej mylnego. Nieporozumienie może wynikać po części ze sformułowania „commitment” (zobowiązanie) obecnego w starszych edycjach Scrum Guida, które zostało jednak zmienione już jakiś czas temu na „forecast” (prognoza). Zmiana miała na celu podkreślenie, że pracując nad złożonymi (complex) systemami, nawet w kilkutygodniowym oknie czasowym nie jesteśmy w stanie zobowiązać się, że dostarczymy każdy zaplanowany wcześniej element. Zamiast obsesyjnego planowania i rozliczania zespołu z niedostarczonych zadań, Scrum zarządza ryzykiem za pomocą Celu Sprintu, który co iterację reprezentuje wybrany, spójny aspekt złożoności całego produktu (np. poprawienie wydajności modułu raportowania o co najmniej 10%, zautomatyzowanie tworzenia kopii zapasowej, dodanie możliwości płatności za pomocą PayPal i SMSa, etc.).

Zatem zespoły nie zobowiązują się dostarczyć 5 historyjek w tym Sprincie, a 7 w innym, ale robią wszystko, aby osiągnąć Cel Sprintu, co niekoniecznie musi oznaczać dostarczenie dokładnie tych zadań, które zidentyfikowano na Sprint Planningu. Może się okazać, że w trakcie Sprintu zespół odkryje zupełnie nieszablonowe podejście, które zrealizuje Cel Sprintu nawet z nawiązką, a nie będzie miało odzwierciedlenia we wcześniej zidentyfikowanych zadaniach. Wbrew pozorom to się zdarza wcale nie tak rzadko, dlatego bardzo ważne jest, żeby zespół współpracował, mając na uwadze (dobrze zdefiniowany) Cel Sprintu, a nie ograniczał się do realizacji pojedynczych zadań przypisanych poszczególnym członkom zespołu.

Scrum Butt

Sugestia z sekcji Scrum Butt, która dla odmiany jest realnym nagięciem Scruma o sporych konsekwencjach brzmi „W zespołach posiadających niedoświadczone osoby, za estymację i rozdział zadań na początku (tzn. jak długo?) powinni być odpowiedzialni seniorzy. Juniorzy powinni obserwować proces szacowania wielkości zadań i jak tylko mają coś (w domyśle ciekawego) do powiedzenia, powinni aktywnie zabierać głos„.

Jak autor uzasadnia tę modyfikację? Ano tak, że niedoświadczone osoby będą mieć problem z poprawnym oszacowaniem swoich zadań. I tu leży źródło nieporozumienia. W Scrumie cały zespół developerski jest odpowiedzialny za dostarczenie zintegrowanego, działającego kawałka produktu, co najmniej raz na Sprint, przed Sprint Review (oczywiście, jeśli jest w stanie częściej to tym lepiej). Nie istnieje coś takiego jak moje i twoje zadanie, są zadania zespołu. Jeśli nawaliliśmy, to bierzemy odpowiedzialność jako cały zespół, a na retro zastanawiamy się jak lepiej współpracować, żeby do takich sytuacji nie dopuścić w przyszłości. Nie zostawiamy nikogo na pastwę losu z „jego” zadaniem i nie wskazujemy go palcem, gdy coś się nie udało.

Jakie są inne minusy? Na starcie zespół dzieli się na równych i równiejszych, co może się utrwalić i odbić w przyszłości na samoorganizacji i chęci poszerzania swoich kompetencji (bardzo często można spotkać sytuację, że estymują wyłącznie osoby o kompetencjach programistycznych). Ostatni problem to dyskusja. Estymowanie przez cały zespół daje dużo większą szansę wypowiedzieć się wszystkim. Stwierdzenie „każdy może się wypowiedzieć, jeśli tylko ma coś do powiedzenia” niespecjalnie zachęca do zabierania głosu osoby mniej doświadczone lub nieśmiałe. Scrum Master powinien uczyć zespół, jak istotne jest, aby każdy miał realną możliwość zabrania głosu. Jeśli już jesteśmy przy Scrum Masterze, to zobaczmy na koniec, jak autor rozumie jego rolę,  w podejściu poprawnym i zaproponowanej przez siebie modyfikacji Scrum Butt.

Scrum Master

Nieporozumienie

Według autora, aby chronić zespół developerski przed przerwaniami, Scrum Master powinien być kanałem, przez który do zespołu przechodzi cała zewnętrzna komunikacja. Żeby tego było mało, Scrum Master powinien być również z automatu delegowany przez zespół do brania udziału w nieplanowanych spotkaniach (emergency meetings).

Owszem, dobrze, jeśli Scrum Master bierze sobie do serca ochronę zespołu przed pewnym rodzajem nieproduktywnych interakcji oraz edukuje innych na temat wpływu przerwań na zespół. Nie znaczy to jednak, że ma dźwigać ciężar całej komunikacji i interakcji zespołu z resztą firmy i świata zewnętrznego. Nietrudno zgadnąć, że w takiej sytuacji Scrum Master szybko stanie się wąskim gardłem, a zespół, zamiast rozwijać asertywność i umiejętności miękkie, przywyknie do tego, że nie musi na co dzień rozmawiać z biznesem czy innymi zespołami rozwijającymi ten sam produkt.

Scrum Butt

Jako modyfikację Scruma autor sugeruje, aby młode, studenckie i wirtualne zespoły, a w szczególności młodzi Scrum Masterzy, korzystali z wiedzy i porad bardziej doświadczonych Scrum Coachów. Ponownie… Scrum nigdzie tego nie zabrania, nie ma zatem co modyfikować.

Podsumowanie

W sekcji Scrum Butt rozdziału poświęconego roli Scrum Mastera pada konkluzja, że skoro będziemy naginać Scruma w pewnych miejscach, to powinniśmy tym bardziej ściśle przestrzegać go w pozostałych.

Jak, mam nadzieję, udało mi się pokazać, sporo sugerowanych modyfikacji w rzeczywistości nic nie zmienia, a Scrum nie wymusza wielu reguł i praktyk, które zwykło mu się przypisywać.

Zamiast tego, w książce pojawia się wiele nieporozumień i technik, które są komplementarne do, ale nigdy nie były i nie są częścią Scruma.

Scrum jest lekkim frameworkiem, który działa, gdy wszystkie jego elementy są na miejscu. Nie modyfikujmy go zatem przy pierwszej lepszej okazji, ale eksperymentujmy z różnymi praktykami i technikami, w ramach pętli feedbacku, które nam oferuje. Nie rezygnujmy też ze Scruma w momencie, w którym jakaś z technik się nie sprawdzi. Poszukajmy wtedy innej albo za pomocą wbudowanych w Scruma mechanizmów inspekcji i adaptacji dopasujmy daną technikę lub rozwiązanie do naszych warunków.

Moja ocena: 2/5

Link do recenzji w serwisie Goodreads: https://www.goodreads.com/review/show/2162794901

Zachęcam również do polajkowania fanpejdża Będąc Młodym Scrum Masterem.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *