“Labirynty Scruma”, czyli jak się nie zgubić, chcąc być zwinnym

Dzięki uprzejmości autora w moje ręce dostała się przedpremierowa wersja książki “Labirynty Scruma” napisana przez Jacka Wieczorka. Książka będzie miała swoją premierę 26 września 2017. Została wydana w modelu self publishing i jest do kupienia poprzez stronę http://labiryntyscruma.pl/ w wersji zarówno elektronicznej, jak i papierowej.

Choć na wstępie autor wyraźnie zaznacza, że nie ma potrzeby czytać tej książki od deski do deski, ja właśnie tak zrobiłem – z premedytacją, ciekaw, co jeszcze może pójść źle przy każdym z wymienionych w spisie treści scrumowych aspektów, jednocześnie sprawdzając czy projekt, w który sam jestem aktualnie zaangażowany nie wykazuje patologicznych oznak opisanych w książce. Po lekturze “Labiryntów Scruma” oraz po własnej, jednoosobowej retrospektywie i refleksji na temat własnego projektu doszedłem do wniosku, że istnieją jednak pola do poprawy.

Jak sugeruje tytuł, książka jest o Scrumie, jednak próżno w niej szukać teorii czym jest Scrum. Jeśli ktoś szuka suchego wykładu, to internet jest pełen wiedzy na ten temat, zaczynając od publicznie dostępnego Scrum Guide’a. Autor książki “Labirynty Scruma”, Jacek Wieczorek, skupił się na trudnościach tego procesu, ukazując je jako tytułowe labirynty w jakie łatwo można wpaść.

Scrum, jako framework składa się z trzech części: ról, zdarzeń i artefaktów, i układ książki odpowiada temu podziałowi. W każdej z tych trzech części mamy następnie omówienie tytułowych labiryntów, czyli najczęstszych pułapek. Jacek Wieczorek nie pozostawia jednak czytelnika bez porad, których jest znacznie więcej.

Rozdział pierwszy książki “Labirynty Scruma” skupia się na rolach, jakie występują w Scrumie. Autor zaczyna od Scrum Mastera i jego labiryntów. Podane przykłady stanowią propozycję, jak powinien się zachować w swojej roli, gdy brakuje mu doświadczenia, gdy zachowuje się jak sekretarka i skupia się tylko na aktualizacji tablicy z widocznym backlogiem sprintu, gdy zachowuje się jak pośrednik przekazujący tylko informację albo coach, lub gdy zachowuje się jak kierownik projektu i gdy jest scrum masterem w kilku zespołach równocześnie. Znalazłem również opisaną sytuację, której sam byłem świadkiem mianowicie byłem w sytuacji gdy Scrum Master był rolą przechodnią. Opisane konsekwencje spójnie zgadzają się z moimi spostrzeżeniami. Efekt był taki, że faktycznie rola Scrum Mastera nie była wypełniana. Skutkowało to dalej dokładnie opisanymi daleko idącymi negatywnymi zmianami w działaniu zespołu scrumowego. Zaskakująco w książce poza oczywistym rozwiązaniem “rola Scrum Mastera nie powinna być rotacyjna”, znalazłem też kilka innych propozycji rozwiązań, które wtedy nie przyszły mi do głowy, a być może miały szansę zadziałać i na dłuższą metę skutkować wyszkoleniem Scrum Mastera już nie tymczasowego, a takiego docelowego, zdolnego podejść do tematu usprawniania organizacji.

Kolejna omówiona rola Scrumowa to Właściciel Produktu. I tu również mamy przykład od czego powinien zacząć, gdy brakuje mu doświadczenia. Dalsze labirynty jakie mogą być już udziałem Właściciela Produktu takie jak brak decyzyjności czy brak wizji produktu w propozycjach rozwiązania adresowane są już często poprzez to, jak w takiej sytuacji powinien się zachować Scrum Master – z czym z resztą w pełni się zgadzam.

Ostatnim w pierwszej części jest Zespół Deweloperski. Problemy z współpracą w zespole jeśli się pojawiają są często jeśli nie najcięższymi, to z pewnością problemami ciężkiego kalibru. Problem zbyt dużego zespołu deweloperskiego jak łatwo się domyślić rozwiązać jest łatwo, ale gdy pojawiają się opisane silosy kompetencyjne, brak wewnętrznej współpracy albo opisany problem, z którym sam spotykam często, czyli brak organizacji swojej pracy samodzielnie, to już tak łatwo nie jest. Zaproponowane porady mają szansę zadziałać, ale oczywiście nikt stuprocentowej gwarancji nie da. Jednak nie chodzi o to aby mieć gotowe rozwiązanie, ale aby mieć przykład jak do trudnych problemów podejść w sposób zwinny i takie porady “Labirynty Scruma” oferują.

Część druga, czyli zdarzenia czasem określane tez jako ceremonie, zaczyna się od Sprintu i znanego problemu – Sprintu Zerowego. Kolejne najciekawsze i jednocześnie najczęściej występujące labirynty to chroniczne niekończenie pracy, wydłużanie Sprintu poza ramy czasowe, zbyt duża ilość otwartej pracy w toku, nieużywanie metryk, ale również rzadziej występujące takie jak realizowanie projektu a nie produktu. Co do tego ostatniego labiryntu miałem do tej pory w głowie gotowe inne rozwiązanie, niż autor zaproponował w książce, tym nie mniej przedstawioną propozycję autora uważam za ciekawą.

Kolejna ceremonia, czyli Daily Scrum to dla mnie dosyć kluczowa sprawa. Co jeśli mechanicznie tylko odpowiadamy sobie pod nosem na trzy pytania? Jak ożywić codzienne spotkanie, aby z mechanicznego stało się platformą do wymiany informacji, tak, aby w dalszej perspektywie przeobraziło się w ożywioną dyskusję? Co należy zrobić aby osiągnąć cel Sprintu? Pozostałe opisane labirynty, zapewne są znane wszystkim z autopsji, czyli Scrum o losowych godzinach, Scrum przez telefon albo – o zgrozo – przez tekstowy czat, brak aktywnego uczestnictwa wszystkich członków zespołu, odbieganie od głównego celu spotkania, czy brak aktualizowania planu przyrostu produktu. Warto przyjrzeć się temu jak to wygląda w anszych projektach i do czego prowadzi. Autor zwraca uwagę czytelnika na te, niby prozaicze, ale jak ważne aspekty, oczywiście oferując też konstruktywne porady.

Przegląd Sprintu – opisane labirynty to brak interesariuszy, brak wartości dla użytkownika, brak planu spotkania oraz labirynty, z którymi się nie spotkałem osobiście, jak na przykład sytuacja gdy Właściciel Produktu prowadzi Przegląd Sprintu albo Zespół nie prezentuje faktycznego przyrostu.

Ostatnia opisana ceremonia, kluczowa dla samego zespołu, to retrospektywa. Ta według mnie najtrudniejsza z ceremonii jest podatna na problemy i wynika to z faktu, że jest najbardziej według mnie ludzką częścią z całego Scruma, bo skupioną na ludziach i interakcjach pomiędzy nimi. A z ludźmi bywa różnie. A to słoń w pokoju, a to ktoś zdominuje całe spotkanie, a to lista akcji okazuje się przeładowana i przypisana na barki tylko jednej osoby – najczęściej Scrum Mastera. Co robić? Znów „Labirynty Scruma” przychodzą z pomocą.

Część trzecia, ostatnia, skupia się na artefaktach. Tych jest trzy i są to przyrost, oraz dwa backlogi. Jeden dla całego produktu, drugi mniejszy dla Sprintu. Labirynty związane z przyrostem często są według mnie skutkiem braku definicji ukończenia, ale okazuje się, że nie tylko. W przypadku wielowarstwowych skomplikowanych systemów częstym występującym labiryntem omówionym w książce jest próba tworzenia przyrostu według warstw architektury, a nie według wartości biznesowej. Moje podejście do tej pory polegało na tym, aby pilnować, by istniała zawsze, choćby minimalna wartość dla użytkownika. Autor proponuje podejście idące dalej trochę w innym kierunku i po zastanowieniu się nad propozycją rozwiązania, muszę przyznać rację, że być może problem nie leży tam, gdzie do tej pory sam go dostrzegałem. Na koniec backlogi. Omówione są osobno, choć labirynty, z którymi możemy się spotkać są podobne, czyli backlog nie istnieje, nie jest przygotowany, nie jest uporządkowany, jest kopią dokumentacji, nie ma dłuższego horyzontu, nie mówi nic o celach jakie są do osiągnięcia lub jest listą sztywnych wymagań pozbawionych kontekstu.

“Labirynty Scruma” zaintrygowały mnie zanim jeszcze książka trafiła w moje ręce. Niezwykle ciekawe ujęcie zagadnienia jest obietnicą wyprowadzenia czytelnika z tytułowych labiryntów. Rozwiązań uczymy się wtedy, gdy zrozumiemy problemy i to bez wątpienia możemy znaleźć w tej lekturze – spojrzenie z boku na to, co trawi proces scrumowy od środka.

Czysto praktyczny aspekt książki sprawia, że polecam ją początkującym Scrum Masterom oraz Właścicielom Produktu, choć osoby bardziej zaawansowane też znajdą dla siebie coś ciekawego. Niezależnie od stopnia znajomości Scruma oraz doświadczenia, każdy znajdzie w książce “Labirynty Scruma” samą ideę czym jest Scrum w postaci inspiracji do zwinnego rozwiązywania codziennych problemów w złożonym i skomplikowanym środowisku wytwarzania oprogramowania. Dla osób bardziej zaznajomionych z tematem, książka może stanowić pewnego rodzaju przegląd aktualnych praktyk, celem sprawdzenia, czy podążając ścieżką Scruma, nie pogubiliśmy się w jednym z wielu labiryntów.