SCRUM i nie tylko

Recenzja Scrum. O zwinnym zarządzaniu projektami

Okładka książki Scrum. O zwinnym zarządzaniu projektami Mariusz Chrapko

Prowadziłem szkolenie Scrum teoria i praktyka w Warszawie, kiedy dowiedziałem się o pierwszej książce o Scrum polskiego autora. Zaraz po szkoleniu pojechałem do Empika i znalazłem egzemplarz na półce. Kupiłem Kubusia i kabanosy (standardowe smakołyki, kiedy jestem w Polsce) i pojechałem do hotelu czytać. Niestety mój entuzjazm malał. Potrzebowałem pięciu podejść, żeby doczytać tą książkę, żeby napisać recenzję. Kolejnych kilku, żeby napisać recenzję i umieścić negatywną opinię o książce. Trochę dziwnie czuję się wydając tak złą opinię o pierwszej książce o Scrum po polsku, ale fakty pozostają faktami, a jednym z filarów Scrum jest Przejrzystość (ang. Transparency). Obiecałem to kilku osobom, więc presja społeczna/koleżeńska zadziałała w tym przypadku jak marzenie. Wersja dla niecierpliwych: nie polecam tej książki, bo jak można by polecać książkę z podstawowymi błędami w sztuce? Dociekliwych zapraszam dalej.

Nie oceniaj po okładce

Na okładce chyba mamy fragment z programu Gliny. W tym odcinku dwóch wyrostków ucieka przed policją skacząc przez płot. Nie oceniajmy książki po okładce. Zdziwił mnie autor, bo pomimo obserwacji i uczestniczeniu na polskim rynku Agile, nigdy nie spotkałem się z Mariuszem Chrapko, jako trenerem czy tak zwanym specjalistą. Jeśli chodzi o napisanie książki, to podejrzewałbym Tomasza Włodarka, Andy’ego Brandt, Kate Terlecką, Wiktora Żółkowskiego. Mam wrażenie, że autor wyrósł spod ziemi. Wiemy za to, że zajmował się filozofią, muzyką i kotami, o czym później.

Wprowadzenie od Mike’a Cohn’a, który jest bardzo zajętym człowiekiem może wydawać się imponujące tyle samo, co podejrzane. W takim razie, dlaczego to nie jest książka sygnowana „Mike Cohn Signature series”? Po co zadawać sobie tyle trudu, żeby przetłumaczyć całą książkę na angielski, wysłać do jednego z najbardziej rozchwytywanych trenerów po to, żeby napisał stronę A4 o tym, co o niej myśli. Przecież przeczytał książkę, do której napisał wprowadzenie, prawda?  Z drugiej strony, skoro prosić kogoś o wprowadzenie, to ja bym się udał od razu do autorów Scrum, czyli Jeff’a Sutherland’a i Ken’a Schwaber’a. To, co Mike napisał jest bardzo ogólne i w dodatku nazwał autora jedynie doświadczonym ScrumMasterem (pisownia łączna w standardzie Scrum Alliance obowiązuje w książce). Można powiedzieć, że budowanie autorytetu na wprowadzeniu od Cohn’a zadziałało równie skutecznie jak „słit focia” autora książki przy fortepianie. Dlaczego nie w trakcie treningu, albo przy Agile Wall? Nie wiem. Dwie strony podziękowań to trochę przydługo. Mowy przy odbieraniu Oskarów są krótsze. Zamiast wstępu jest … wstęp podparty dwoma przypisami, nazwiskami guru zarządzania, tytułami filmów, utworów muzycznych. Przebrnąłem, chyba zacznie się „książka właściwa”.

Książka właściwa

Przetłumaczenie model Watefall, jako metoda kaskadowa jest nieco dziwne, ale nie bądźmy drobiazgowi. Agile Manisfesto, jak to zwykle w tym temacie musi się znaleźć i jest, ale 12 zasad Agile jest jedynie wspomniane. Wielka szkoda. Zasady bardzo często są pomijane, a stanowią ważne uzupełnienie manifestu. To tak jakby manifest każdy czytał, ale odwrócić kartkę i zobaczyć 12 zasad to już za dużo. A przecież przewrócenie strony może wiele wyjaśnić i zmienić:

W drugim rozdziale nawiązania do muzyki już zaczynają nudzić.

Na stronie 48 sięgnąłem po pióro z czerwonym atramentem i zacząłem zaznaczać błędy merytoryczne. Nikt tego nie przeglądał, czy co? Najwyraźniej Mike Cohn czytając książkę nie zauważył, że autor popełnił podstawowy błąd nazywając Scrum zwinną metodą zarządzania projektami ( to samo z resztą na okładce, w dodatku pogrubioną czcionką). Na litość boską ile razy Ken Schweber musi zamieścić artykuły, posty i video, żeby dotarło, że Scrum jest frameworkiem, ramą i nie jest metodą, metodyką ani instrukcją krok po kroku. To sam jest nawet wałkowane w testach na PSM I oraz w Scrum Guide.

„Scrum is not a development method or a formal process, rather it is a compression algorithm for worldwide best practices observed in over 50 years of software development. The Scrum framework is simple to implement and automatically unpacks and encourages a software development team to deploy best practices”

Jeff Sutherland “The Scrum Papers: Nut, Bolts, and Origins of an Agile Framework”

“Scrum is a framework structured to support complex product development.”

“The Scrum Guide. The Definitive Guide to Scrum: The Rules of the Game” Ken Schwaber and Jeff Sutherland

Impediments jest niekonsekwentnie raz tłumaczone jako blokady a raz jako przeszkody. A im dalej w las tym więcej drzew. Twierdzenie, że ScrumMaster to taki „Master Yoda, broniący zespołu przed „ciemną stroną mocy”nie nastawia czytelników dobrze do przyszłej współpracy z resztą organizacji. Może brzmi cool, ale nie da się współpracować z kimś, kogo określamy z góry, jako zło, a sami mamy poczucie misji zwalczania tego zła, prawda? Dowiadujemy się też, że postawa ScrumMastera jest „bardzo służalczą”. Takie określenie w języku polskim ma raczej negatywną konotację i już widzę szeregi przyszłych ScrumMasterów protestujących „Służalczości nie było w umowie!” :)

Mało tego, czytamy, że ScrumMaster ma sterować procesem i prowokować zespół. Dla mnie sterowanie kimś i prowokacja, to po prostu manipulacja. Co to za ScrumMaster? Chyba według autora ScrumMaster realizuje swoją ukrytą agendę sprawiając wrażenie, że zespół sam wpada na takie a nie inne pomysły. TO JEST NAGANNE ZACHOWANIE drogi czytelniku, czytelniczko. Takich ScrumMasterów należy wyrzucić za drzwi firmy jak najszybciej. Zdarzają się tacy delikwenci czasem i zdarza się to w przypadku, kiedy manager zatrudnia zewnętrznego konsultanta tylko po to, żeby nadal mieć władzę nad zespołem, ale w sposób mniej jawny. Przecież konsultant, a w szczególności kontraktor zazwyczaj dąży do podpisania kolejnej umowy, wiec robi to, co zadawala zleceniodawcę. [Na marginesie: jak wyczuwam, że taka jest intencja osoby zatrudniającej mnie, to nie podejmuje się projektu] SM czuwa też, nad tym jak praca ma być wykonana. Doprawdy? A mi się wydawało, że to samoorganizujący się i samo-zarządzalny zespół decyduje o tym. Nikt nie może ingerować w decyzje zespołu co do tego jak wykonać pracę, nawet Master Yoda ;) O i napisane tutaj jest, ze ScrumMaster jest odpowiedzialny za wydajność zespołu. Brzmi to mocno „managersko”.

Można się też dowiedzieć, że ScrumMaster to pies, który „wymaga stałego kontaktu ze swoim panem i ludźmi”. Metafora Owczarka Podhalańskiego chyba wydawała się autorowi trafna.

Pomysł Głównego ScrumMastera (Chief ScrumMaster) to nowość. Standardowo osoba wspomagająca ScrumMasterów i współpracę całej organizacji to po prostu Agile Coach.

Podobnie mało ciekawym pomysłem jest wprowadzanie 3 stopniowej hierarchii Product Ownerów. To na pewno przyspieszy pracę zespołów i poprawi komunikację w organizacji ;)

Z kolei określenie, że „Platon to starożytny „mędrol”, który szwendając się po Atenach, wykoncypował sobie pojęcie „idei”” napisał, za autora, jeden z jego kotów po zjedzeniu trawy w ogrodzie.

Określenie „S” w akronimie INVEST, jako mała historyjka, która mieści się w Sprincie jest kolejnym błędem merytorycznym. S oznacza Sized Approprietaly, czyli odpowiedniego rozmiaru do momentu, w którym o niej mówimy zgodnie z konceptem Product Backlog Iceberg. Chyba Mike Cohn mówił o tym na szkoleniu, na którym był autor?

Kilka innych uwag bez rozwinięcia

Po co grooming (spotkanie pielęgnacyjne) dawać do Sprint Backlog? Pod jaką User Story to byłoby podpięte? Bufor stosowany na Planning Meeting jest od tego.

„Punktów używamy do oceny skomplikowania danej funkcjonalności” – Słucham? I teraz rzecz najzabawniejsza. Mike Cohn opublikował post pod tytułem „It’s Effort, Not Complexity”. Czyli pogląd autora wprowadzenia do książki jest skrajnie inny niż autora książki :)

“So, story points are about the effort involved. Feel free to adjust your estimate of effort based on things like risk and uncertainty, but point-based estimating is about the time the work will take. It's what our clients, bosses, customers, and stakeholders care about.”

Na tym etapie nawiązania do muzyki i słów piosenki Natalii Kukulskiej robi się tak samo nudne jak wiersze i śpiewy elfów we Władcy Pierścieni.

Czy ktoś przeczytał trzy strony dialogów z filmu M.A.S.H.?

Autor proponuje podzielić zespół na dwa mniejsze w trakcie Planning Poker, jeśli jest większy niż 10 osób. Hellloooooł! Ale przecież rozmiar zespołu Scrum jest określony na maksymalnie 9 osób.

Pisanie User Story, jako użytkownik (user) to oczywisty błąd. Gdzie jest Wizja i gdzie są Persony?

Horrendalny jest pomysł przerw 1-2 dni pomiędzy Sprint'ami. Firma Atlassian nie wykorzystuje FedEx Days, które już jakiś czas temu zmieniły nazwę na ShipIt Days z powodu interwencji fimry FedEx, do wypełniania przerw między iteracjami. ShipIt Days to 24 godziny raz na kwartał. Praca w Scrum powinna mieć stałe tempo i dawać Zespołowi wysoką satysfakcję. Wtedy przerwy nie są potrzebne. Pomysł przerw pomiędzy iteracjami wytrąca z tempa i rutyny i jest z reguły szkodliwy.

Dalej mamy niestandardowe pytania dotyczące Daily Scrum:

  • Co robiłem wczoraj?
  • Co będę robił dzisiaj?
  • Co mi przeszkadza?

Przecież to właśnie status meeting i przeciwieństwo Daily Scrum. Kogo obchodzi, czym są zajęci członkowie Zespołu i co im przeszkadza? Ważne, co zrobili od ostatniego spotkania (czas dokonany), co planują zrobić do kolejnego spotkania i czy potrzebują pomocy albo krótkiej narady. Oryginalne pytania ze Scrum Guide (wersja Oct 2011 PL)

  • Co zostało wykonane od ostatniego spotkania?
  • Co zostanie wykonane przed kolejnym spotkaniem?
  • Jakie przeszkody stoją na drodze?

Chodzi o to, co zostało ukończone.

Kilka dobrych pomysłów

Są też, oczywiście ciekawe koncepty i dobra wiedza w tej książce. Na przykład metafora członków Zespołów na kształt litery T. Podoba mi się określenie, że idealny rozmiar zespołu, to taki, który może posilić się dwiema pizzami. Pokazanie lejka niepewności estymacji dobrze obrazuje problemy z szacowaniem.

Podsumowanie

Mnóstwo podstawowych błędów i „opowieści muzyczne” przekreślają tę książkę w mojej subiektywnej opinii. Czy ktoś, kto się zna przeglądał tą książkę przed wydaniem? Jak poszedł przegląd edytorski, który jest częścią procesu publikacji? Niestety istnieje wysokie ryzyko, że autor teraz będzie uznawany za guru Scrum w Polsce, bo „przecież napisał książkę” i będzie beztrosko wdrażał swoje pomysły w organizacjach i szkolił przyszłych ScrumMasterów. Jak zwykle polecam przy ograniczeniu edukacji do książek w języku angielskim, zaczynając od klasyków: Ken Schwaber, Jeff Sutherland, Mike Cohn i seria „A Mike Cohn signature book”.


Re: Nie chcę bronić autora

Panie MJ, dziękuję za komentarz. Cytuje Pan tutaj fragment polskiego tłumaczenia Scrum Guide, które zawiera ten sam błąd, co książka. Czy fakt pojawienia się błędu w tłumaczeniu usprawiedliwia błąd w książce? Scrum Guide w oryginale. W Polskiej wersji tłumaczenia z 2010 roku był inny błąd, zawarty w samym tytule "Scrum Guide - Przewodnik po metodyce Scrum"
Tak jak cytowałem wyżej Scrum jest framework'iem. Scrum nie jest metodą, metodyką ani instrukcją krok po kroku. Pytanie o to pojawia się na teście PSM I.
Zajrzyjmy do Wikipedii:
Metodologia jest to nauka o metodach badań naukowych, ich skuteczności i wartości poznawczej.
Metodyka koncentruje się na poszukiwaniu odpowiedzi na pytanie: Jak to należy robić?
Scrum nie mówi ani co, ani jak robić. Scrum określa pewne elementy potrzebne do wytwarzania skomplikowanych produktów. Określa początek i koniec cyklu, ale środek "The Work" pozostaje procesem empirycznym tworzonym na bieżąco przez Zespół.
Słowo framework nie ma swojego odpowiednika w języku polskim które by dobrze brzmiało, można użyć jedynie przybliżenia rama lub szkielet, ale taki nie oddaje pełnego znaczenia. Ten problem istnieje już od pewnego czasu i manifestowany jest próbach tłumaczeń różnych narzędzi dla oprogramowania.
Twórcy propagandy mawiali, że kłamstwo powtórzone tysiąc razy staje się prawdą. Przestańmy powtarzać ten błąd.

Nie chcę bronić autora

Nie chcę bronić autora książki, ale może Pana zarzut " Na litość boską ile razy Ken Schweber musi zamieścić artykuły, posty i video, żeby dotarło, że Scrum jest frameworkiem, ramą i nie jest metodą, metodyką ani instrukcją krok po kroku." wynika z tego, że w linkowanej przez Pana Scrum Guide (wersja Oct 2011 PL) możemy przeczytać:

"Cel przewodnika
Scrum jest metodą wytwarzania i utrzymywania złożonych produktów. Niniejszy przewodnik zawiera definicję tej metody, na którą składają się: role, zdarzenia, artefakty i zestaw reguł, które spajają te elementy w jedną, nierozerwalną całość. Scrum został stworzony przez Kena Schwabera i Jeffa Sutherlanda, a niniejszy przewodnik został przez nich przygotowany i udostępniony. To oni, autorzy Scruma, stoją za jego treścią.

Scrum – informacje ogólne
Scrum (rzecz.): metoda, przy użyciu której ludzie mogą z powodzeniem rozwiązywać złożone problemy adaptacyjne, by w sposób produktywny i kreatywny wytwarzać produkty o najwyższej możliwej wartości."

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.

Skomentuj

The content of this field is kept private and will not be shown publicly.
CAPTCHA
To pytanie sprawdza czy jesteś człowiekiem, czy botem spamującym
Image CAPTCHA
Wpisz znaki widoczne na obrazku.