Labirynty Scruma – recenzja książki

By 22 listopada 2017Recenzje

Jakiś czas temu skontaktował się z nami Jacek Wieczorek – autor „Labiryntów Scruma” z propozycją recenzji książki. Muszę przyznać, że byłem dość sceptycznie nastawiony – książka jest wydana w modelu Self-Publishing, co często niestety wiąże się z niedopracowanym produtem końcowym lub ciężkim do ‚strawienia’ stylem/słownictwem. Na szczęście w tym wypadku nie miałem racji :) Ale po kolei…

Książka jest reklamowana jako praktyczny przewodnik po Scrumie i w założeniu autora jest przeznaczona dla osób, które wiedzą już czym jest Scrum i szukają sposobów na pogłębienie swojej wiedzy lub wskazówek, jak radzić sobie z określonymi problemami (do tego się odniesiemy jeszcze niżej). Niezaprzeczalnym plusem książki jest to, że została napisana przez polskiego autor w rodzimym języku, dzięki czemu nie spotkamy dziwnych konstrukcji zapożyczonych z innych języków, niespójnego tłumaczenia lub tłumaczenia słów z pominięciem kontekstu / żargonu. Książka podzielona jest na perspektywy (np. Scrum Master, Zespół Deweloperski, Właściciel Produktu itp), w ramach każdej z nich mamy przykładowe problemy/sytuacje. Te z kolei są opisane w strukturze sytuacja-konsekwencje-możliwości, dzięki czemu czyta się ją bardzo wygodnie i nie ma potrzeby czytania ‚od deski do deski’ – jeśli interesuje nas jakieś konkretne zagadnienie, rozdziały są od siebie niezależne i wystarczy przeczytać to, co nas interesuje. Językowo czy w kwestii składu „Labirynty” są na wysokim poziomie – trudno znaleźć w tym zakresie cokolwiek, do czego można by mieć zastrzeżenia.

Merytorycznie, często łapałem się na potakiwaniu podczas czytania ;) Autor jest oczywiście praktykiem, z bogatym doświadczeniem w wielu organizacjach, dzięki czemu opisuje problemy i potencjalne rozwiązania z szerokiej perspektywy. Opisywane problemy/sytuacje są ‚najczęściej pojawiającymi się’ – to oczywiście bardzo uznaniowe określenie, ale w moim odczuciu porusza najważniejsze kwestie i nie byłbym w stanie wskazać jakiegoś elementu, którego brakuje. Praktycznie każdy problem zawiera wiele możliwych rozwiązań, często z krótkim omówieniem kontekstu lub potencjalnych wad takiego rozwiązania. „Krótkie” to tutaj słowo klucz – cała książka jest dość zwięzła, autor nie wchodzi w szczegóły a raczej odsyła do źródeł i innych materiałów, co osobiście uważam za plus – nie znajdziemy tutaj szczegółowych opisów czym jest GTD, bo to temat na osobną książkę (których zresztą wiele powstało). Nie ma też niepotrzebnych opisów i okrągłych słów – czyli po prostu krótko i na temat. Jest to taki „ekstrakt”, do przeczytania w jeden wieczór.

Taka forma książki powoduje jednak sporą ilość odnośników – do innych rozdziałów, do książek czy materiałów online. Jako że używaliśmy ebooka, było to wygodne – niemniej w wersji papierowej książki może to być problematyczne i irytujące (nie przeglądaliśmy jednak wersji papierowej – być może jest to rozwiązane w jakiś sposób).
Książka ta jest też targetowana w osoby z jakimś doświadczeniem – wydaje mi się, że można by jednak dodać wstęp w stylu „Czym jest Scrum” albo „Dzień z życia (tutaj po kolei role) w projekcie Scrumowym” i spokojnie byłaby to pozycja dla osób bez doświadczenia, chcących zdobyć trochę wiedzy nie tylko czysto teoretycznej o procesach w firmie/projekcie.

Momentami miałem też wrażenie, że autor wpada w pułapkę struktury, którą sam sobie narzucił. Przykładowo omawiając problem Scrum Mastera wchodzącego w rolę coacha w części rozwiązań mamy opis innych ról i podejść do określania ról – sprawia to wrażenie wiedzy lekko ‚upchniętej’ z braku lepszego miejsca (wydaje mi się, że wspomniany „wstęp teoretyczny” byłby dla tego typu informacji lepszym miejscem). W książce znajdziemy też trochę autopromocji – opisy zagadnień są odnośnikami do innych publikacji autora/grup, w których autor działa. Nie jest to nachalne czy bardzo przesadzone, ale warto byłoby dodać także inne źródła, choćby tylko dla innej perspektywy. W książce zabrakło mi także wydzielonej perspektywy organizacji – niestety często problemem w realizacji projektów jest sama organizacja (nawyki, podejście, polityki itp). Te problemy są omawiane przy innych perspektywach pośrednio (więc nie jest to stricte brak tych informacji) – wydaje mi się jednak, że organizacja jest źródłem problemów na tyle często, że ‚zasłużyła’ na własny rozdział. Ostatnim, i właściwie największym zastrzeżeniem jest wybiórczość w podawaniu opcji – np. przy opisie technik zarządzania czasem mamy wymienioną technikę GTD oraz jedno narzędzie z którego korzysta autor. Jako że różne narzędzia i techniki sprawdzają się dla różnych zespołów/sytuacji, warto byłoby wymienić nawet w punktach inne popularne (w tym konkretnym przykładzie choćby Pomodoro, ‚Zjedz tę żabę’ czy macierz ważne/pilne). Podobnie ‚widoczna’ luka była w przypadku wizji produktu – wypisanie innych opcji (jak np. release note+FAQ czy interaktywne makiety) – w kilku innych miejscach też można by rozwinąć wachlarz opcji (nawet w punktach – po prostu jako dostępne możliwości).

Ogólnie książka jest bardzo solidną pozycją w temacie Scruma – nie jako jedyna książka, ale jako uzupełnienie bardziej teoretycznych pozycji (np. książki Jeffa Schutlanda). Z uwagi na ilość odniesień wewnątrz książki, polecamy raczej wersję elektroniczną z ‚klikalnymi’ linkami. Pomimo, że jest to raczej książka do czytania wybiórczego w zależności od sytuacji, gorąco zachęcamy do poświęcenia jednego wieczoru na przeczytanie (czy nawet przekartkowanie) całości – czasem nie zdajemy sobie sprawy z problemów, które mogą być (jeszcze) mniej intensywne lub po prostu się przyzwyczailiśmy. W obecnej formie może być ciężka do przyswojenia przez osoby całkowicie bez doświadczenia z uwagi na brak kontekstu, ale może mimo tego warto się z nią zapoznać i wrócić po jakimś czasie.

Konkurs!

Dzięki uprzejmości autora, pana Jacka Wieczorka, mamy dla Was trzy kopie książki do wygrania! Aby wziąć udział w konkursie, wystarczy odpowiedzieć na poniższe pytanie w komentarzu pod wpisem lub pod informacją o konkursie na FB:

Opisz krótko problem, z jakim się spotkałeś/spotkałaś w zespole i jak go rozwiązaliście?
Zdajemy sobie sprawę, że nie o wszystkim można pisać wprost, dlatego ogólnikowe informacje też są ok w tym wypadku.

Odpowiedzi można nadsyłać do końca Listopada 2017. Spośród nadesłanych na czas odpowiedzi wybierzemy trzy osoby, które otrzymają książkę „Labirynty Scruma”!

  •  
  •  
  •  
  •  
  •  
  • Magdalena D.

    Częstą praktyką jest wykorzystywanie tylko pewnych elementów Scruma, tak by odpowiednio go dopasować do potrzeb zespołu. U nas przez długi czas nie było daily, przez co czasem nie było wiadomo co i kiedy będzie zrobione już teraz, a co dopiero pod koniec sprintu. Dzięki daily rozwiązaliśmy ten problem i mamy większą kontrolę nad przebiegiem sprintu, mogąc szybciej reagować na pojawiające się w trakcie problemy czy ewentualne opóźnienia.

  • Jacek Wieczorek

    Jakub, dziękuję za recenzję. Zachęcam do udziału w konkursie – książki czekają :)

  • Kalina Jo En

    U mnie zazwyczaj problem pojawia się na linii oczekiwania klienta, QA vs programista, dlatego ostatnią linią decyzji pozostaje zazwyczaj PM ;)

  • Dzięki za ciekawą recenzję! Na pewno zainteresowała mnie książką :). Ciekaw jestem z ilu problemów w niej przedstawionych nie zdaję sobie sprawy w codziennej pracy…

    Problem jaki ostatnio udało nam się rozwiązać w zespole wiązał się ze znacznie przedłużającym się planowaniem sprintu (czasem nawet do dwóch dni). Wynikało to z faktu, że zadania które mieliśmy rozwiązywać w danym sprincie były dla nas niejasne. W związku z czym na planowaniu musieliśmy wyjaśnić wątpliwości, ustalić ‚definition of done’ i wyestymować wszystkie zadania. Finalnym rozwiązaniem problemu było umówienie się na ‚mini-groomingi’, czyli krótkie spotkania (max 15) po daily scrumie, na których omawialiśmy jedno jeszcze niejasne zadanie z backlogu.

  • Marysia Korbas

    Książka „Labirynty Scruma” wydaje się być bardzo interesująca. Moje doświadczenie ze Scrumem jest jeszcze niewielkie, a nasza praca w tej metodologii nie trwa jeszcze zbyt długo. Jeżeli myślę o problemach to na początku mieliśmy problem z estymacją naszych zadań. Trudno było nam zrozumieć, że np. jeden story point niekoniecznie równa się jednej godzinie. Na początku naszych estymacji w zespole występowały duże różnice w przyznawaniu story pointów poszczególnym zadaniom i konieczna była dyskusja, żeby wyjaśnić dane rozbieżności. Na szczęście wraz z praktyką idzie nam coraz lepiej, łatwiej też przychodzi nam ocenienie poszczególnych zadań.

  • Zmieniłem pracę itrafiłem do zespołu, który pracuje w Scrumie. Cięzko mi się połapać w nazewnictwie i tym czego mają dotyczyć kolejne spotkania. Liczę, że dzięki książce szybko to ogarnę i znajdę dodatkową inspirację, bo niedługo moja kolej prowadzenia retro :)

  • Karolina

    Fajny konkurs, a pytanie wydaje się proste, ale po zastanowieniu już takie nie jest.
    Jedne z częstszych problemów z jakimi się spotykałam to:
    1. Rotacja i wdrażanie nowych osób. Ciężko się pracuje jeśli sporo osób jest nowych, z małym doświadczeniem, nie zna produktu który rozwijamy, nie wie co już jest zaimplementowane, a czego nie ma i wiele innych. Wyeliminować rotacji się nie udało, bo wiadomo że ona będzie. W rekrutacje zostały zaangażowane osoby z zespołu, tak aby decyzja kto będzie z nami pracował nie zależała tylko on managera. Dodatkowo, z zespołem opracowaliśmy plan wdrażania nowych osób. Przy współpracy z Product Ownerem, zwracamy uwagę na to żeby zadania/historyjki były opisane zrozumiale, nawet dla osoby z zewnątrz. Może nasze próby radzenia sobie z sytuacją, nie rozwiązują problemu do końca, ale na pewno ułatwiają pracę.
    2. Brak czasu/budżetu na refaktor i utrzymanie kodu. Czas na zrefaktoryzowanie/przepisanie całego projektu się nie znalazł i pewnie w większości firm, by się nie znalazł. Trzeba było się pogodzić, że zmiany musimy wprowadzać systematycznie i przy okazji, a przez pewien czas będą w kodzie funkcjonowały dwa podejścia.

  • Trina

    Dziękuję za recenzję, chętnie przeczytam książkę, jeśli będę miała okazje.
    Co do pytania konkursowego, to chyba problemem z jakim ostatnio często spotykał się zespól, w którym pracuje, była liczba błędów znajdowana na koniec sprintu, co uniemożliwiało nam zamknięcie sprintu. Często wynikało to ze źle opisanych historyjek, braku wymagań itp. Historie były omawiane tylko podczas spotkań zespołu (backlogów). Do momentu spotkania, PO odpowiadał za spisanie wymagań. Postanowiliśmy wiec, ze rozdzielamy niezaczęte jeszcze historie wśród pozostałych członków zespołu, tak, żeby odpowiedzialność za jakość kryteriów akceptacji nie spoczywała tylko na PO. Wybrana osoba ma za zadanie przemyśleć, przedyskutować z PO historyjkę i ewentualnie poprawić opis. Dopiero potem historyjka jest omawiana z całym zespołem i praca jest estymowana. W rezultacie znacznie więcej ważnych rzeczy udaje się przewidzieć jeszcze przed rozpoczęciem sprintu.

  • Wyniki konkursu :)
    Książki trafiają do Marysia Korbas, Piotr Gajowniczek oraz Trina. Gratulujemy i będziemy kontaktować się na maila w celu ustalenia szczegółów!

    • Jacek Wieczorek

      Gratuluję zwycięzcom :) Przyjemnej lektury!