Półżartem o największych wyzwaniach Scrumowych

Scrum Master przybywa na ratunek

Tak, jak zajawiłem już we wstępie, przez większość czasu pracy jestem Scrum Masterem w wariancie „koło ratunkowe”. Oznacza to, że wkraczam do projektu w momencie, kiedy popełniono już wszystkie możliwe błędy. Podsumowując, nic nie działa, projekt jest po terminie, wszyscy są sfrustrowani. Jak można się domyślić, nie jest to najłatwiejsze środowisko do pracy.   

Tak między nami, najtrudniej pracuje mi się w projektach, w których to zespół był święcie przekonany, że przecież co jak co, ale pracują w Scrumie. W takich przypadkach często wita mnie stwierdzenie: eee, Scrum nie działa, już próbowaliśmy.

Potrzeba naprawdę wiele cierpliwości i samozaparcia, żeby odwrócić taki tok myślenia i pokazać, że to nie wina metodyki Scrum a nieumiejętnego jej wykorzystania. 

Zespół scrumowy

W takich przypadkach — pół żartem, pół serio — muszę być w pierwszej kolejności trochę psychologiem (a mam na tym polu doświadczenie!). Przydaje się to na starcie projektu, kiedy to podstawowym zadaniem Scrum Mastera jest sprawienie, żeby zespół scrumowy (szeroko rozumiany, włączając również Product Ownera) przeszedł z trybu przetrwania w tryb tworzenia.  

Nie da się w pełni wydajnie pracować z nożem na gardle, dlatego przybywając z akcją ratunkową, na wstępie zarządzam stop-klatkę i powrót do korzeni. Niestety, ale w „scrumowych” projektach tego typu jedyne co mamy ze zwinności to rytuały. 

Wiecie, zespół projektowy ma Jirę i prowadzi jakieś spotkania, ale nie do końca rozumie, w jakim celu to wszystko robi (są w kalendarzu — znaczy, że trzeba). Działając w ten sposób, zyskuje błędne przekonanie, że przecież jest zwinny. I nie piszę tego, żeby komuś coś zarzucać. Chcę uświadomić, że moim zdaniem jedynym sensownym wyjściem w takiej sytuacji jest odwołać wszystkie spotkania. 

A co dalej? Ustawić nowe, „pierwsze” spotkanie, podczas którego na spokojnie tłumaczę, czym tak naprawdę jest ten cały Agile oraz objaśniam podstawowe zasady Scruma.

Metodyka Scrum

Istotą zwinności, w tym Scruma, jest ciągłe podejmowanie decyzji w kontakcie z rzeczywistością. Możemy perfekcyjnie obliczyć czas przejazdu z miejsca A do miejsca B, nawet uwzględniając warunki pogodowe i zwyczajowe korki, ale nie przewidzimy np. wypadku na drodze. Zespół musi zrozumieć, że rzeczywistość projektowa nie różni się od rzeczywistości jako takiej. Zasady są zinternalizowane – dopiero kiedy wszyscy to załapią, przechodzę do stosowania praktyk.  

Plusem jest, że większość zespołów projektowych na tym etapie powoli łapie wiatr w żagle i zaczyna dopytywać, jak wcielić zwinność w życie albo jak zacząć budować wymagania. To dobre pytania, szczególnie że czasami podczas audytu przechodzę przez Jirę i widzę zadania oznaczone jako user story, a wpisane jest tylko… 

Większa czcionka. 

Serio. 

Co ma wspólnego Kant, Lean i Agile?

Przed napisaniem tego tekstu zastanowiłem się, co takiego wydarzyło się w moim życiu, że zacząłem podchodzić do niego w sposób zwinny? Muszę przyznać, że wszystko zaczęło się bardzo dawno temu, kiedy to w latach 80. na lekcjach języka polskiego czytaliśmy pisma Kanta. W tamtym momencie do głowy wbił mi się jeden z imperatywów kategorycznych, który mówi, że w żadnych okolicznościach nie powinniśmy rozpatrywać człowieka jako narzędzia. 

Potem na początku lat 90. zetknąłem się z Lean, a właściwie systemem produkcyjnym Toyoty, który cieszył się ogromną popularnością wśród założycieli firmy. Dlatego, kiedy Agile i Scrum zaczęły robić się modne, nie potrafiłem już myśleć inaczej niż po leanowemu. Stąd właśnie praktykach projektowych korzystam z metod problem solvingowych wyniesionych z Lean, czy też adaptuję narzędzia. 

Moim zdaniem (i będę go bronił!) narzędzia zawsze powinny być wtórne do zasad. W sytuacjach ratunkowych najpierw dajemy zespołowi ochłonąć, a następnie naszą Scrum Masterską powinnością jest zbudowanie świadomości, dlaczego powinniśmy pracować zwinnie, a nie zgodnie z metodyką yolo 😉  

Dopiero potem wchodzi praca organiczna, a więc prowadzenie spotkań, które zaczynają być owocne (więcej o meandrach metodyki scrumowej pisała moja koleżanka w artykule: Rola Scrum Mastera we wczesnych fazach projektu).

Pomiar: opresyjny czy optymalizacyjny?

Muszę w tym miejscu zaznaczyć, że rolą Scrum Mastera jest trzymanie ręki na pulsie procesu, czyli badanie tego, w jaki sposób rozkłada się efektywność. Pokazanie, że pomiar nie jest czynnością nastawioną na kontroling, a ma za zadanie pomóc zespołom zobaczyć, czy są na właściwym kursie oraz optymalizować proces. Na dodatek wykres spalania nie jest jedyną miarą, której należy się trzymać.  

Scrum Master w trakcie spotkań korzysta choćby z takich narzędzi, jakie daje Jira. Osobiście moim ulubionym wykresem jest Fix Version, dzięki któremu mogę pokazać jakieś fakty i mieć punkty wyjścia do dyskusji: czy wynik jest zadowalający, czy należy coś poprawić? A prawie zawsze da się coś poprawić. Po więcej w tym wątku odsyłam np. tutaj: Scrum jak Waterfall, czyli jak zarządzać efektywnością zespołów, żeby dowozić na czas.  

Oczywiście, zespół można docisnąć, zmuszając ludzi do nadmiernej pracy.  

Tylko tak jak samochód na nitro nie przejedzie zbyt daleko, tak samo zespół może w ciągu jednego czy dwóch sprintów przynieść bardzo dużo wypalonych story pointów, a następnie przez trzy sprinty zbierać się i przechodzić kryzys. Kto wyjdzie zwycięsko, jeżeli w połowie projektu frustracja i zmęczenie sięgnie zenitu, a ludzie zaczną odchodzić?   

I tu zatoczyliśmy koło, a Kant miał rację — ludzi należy traktować po ludzku, a nie jak narzędzia. 

Scrum Master vs Project Manager vs Product Owner

Nierzadko audytując nieefektywny proces wytwórczy oprogramowania, spotykam się z oporem ze strony Project Managera czy Product Ownera. Wynika to z prostej obawy, że dołączam do zespołu, bo oni robią coś źle i teraz przejmę ich obowiązki. 

Czasami faktycznie role Scrum Mastera i właściciela produktu trochę się równoważą, ale pamiętajmy, że przecież wszyscy pracujemy nad tym samym oprogramowaniem. Nie stoimy naprzeciw i nie konkurujemy ze sobą, ale raczej odpowiadamy na pytanie: jak możemy sobie pomóc? Ja nie chcę pozbawić Product Ownera jego roli w zakresie tworzenia wymagań. Wręcz przeciwnie, dołożę wszelkich starań, aby robił to w sposób jak najdoskonalszy. A że jednym z moich zadań jako Scrum Mastera jest myślenie procesowe, dodatkowo wesprę go przy mapowaniu procesu.  

Z doświadczenia wiem, że czasem Product Owner, będąc w środku wydarzeń, nie widzi całości procesu w taki sposób, jak osoby z zewnątrz. W tym właśnie ja. Taki dystans jest niezbędny, aby zadawać — z pozoru głupie — pytania (takie, których nie zada nikt inny) i nakierunkowywać zespół na efektywniejsze tory. 

Kto pyta, nie błądzi, a Scrum Master musi zadawać dużo pytań. 

Na straży potrzeb klienta

Podam Wam przykład – spotkałem kiedyś na swojej drodze Product Ownera, który miał za zadanie stworzyć produkt pomagający sprawniej obsługiwać noty księgowe przychodzące do ich firmy. Pierwsze co, to zadałem pytanie: czym u licha jest nota księgowa? W odpowiedzi usłyszałem, że jak zrobią jakiś błąd w papierologii, ich biuro księgowe przysyła notę z informacją, co należy poprawić. 

Niby prosta sprawa, ale kiedy zobaczyłem skalę, ile takich not przychodzi w miesiącu, zacząłem drążyć. Czy oby na pewno ich problemem jest, że nie obsługują not księgowych czy może istota zamieszania leży gdzieś głębiej? Na przykład po stronie wystawiania dokumentów. 

Chyba wszystkim potrzeby był taki orzeźwiający prysznic i uświadomienie, że jak zespół Product Ownera będzie miał dobrze zrobiony proces uzupełniania dokumentów, to nie będzie not księgowych, a nowy produkt do ich obsługi stanie się zupełnie zbędny. 

Przegląd wizji produktu

No i właśnie, to też jest rola Scrum Mastera. Wyjść poza ramy, oczyścić przestrzeń projektową, wyklarować zakres projektu. Czasami przyzwyczajenia nie pozwalają wyrwać się poza określoną perspektywę, a Scrum Master przychodzi z czystą głową. 

Dodatkowo moim zadaniem jest również urealnianie potrzeb. Spójrzmy prawdzie w oczy, nie wszystkie funkcjonalności są faktycznie potrzebne w danym procesie, a ludzie (w tym i właściciele produktów) mają tendencję do delikatnego wyolbrzymiania. Szczególnie w przypadku dużej konkurencyjności na rynku. Firmy zaczynają prześcigać się w wymyślaniu rozwiązań oraz zastanawianiu się, co jeszcze dorzucić do swojego rozwiązania, czego nie ma nikt inny. 

Trudno wtedy przyznać — nawet przed samym sobą — że nikt tego nie ma, bo być może nikt tego nie potrzebuje. 

Scrum Master a Project Manager

Hm, a co z Project Managerem?   

Czasami przychodzi do mnie Project Manager i pyta: no okej, to co ja mam robić? Odpowiadam mu wtedy, że nie wiem, bo Scrum Guide nie uwzględnia takiej roli 😉 

Natomiast w rzeczywistości Project Manager jest ogromnym wsparciem w zakresie organizacyjno-administracyjnym, a także pomaga mi usuwać przeszkody, z którymi boryka się zespół projektowy. Natomiast ja mam zadanie odciążyć go z wielu zadań związanych z efektywnością zespołów, jak również dostarczać informacji wynikających z pomiarów wraz z objaśnieniami. 

Mity i przekonania, które hamują zwinne zarządzanie

W tej części tekstu chciałbym podzielić się kilkoma problemami i przekonaniami, które napotykam na swojej drodze, a które skutecznie zabijają Scruma. Niech poniższe przykłady będą przestrogą i potwierdzeniem, że metodyka sama w sobie nie zdziała cudów, jeżeli nie będziemy jej rozumieć i trzymać się zasad. 

Za dużo tego Scruma

Pamiętam jeden taki projekt, gdzie wszystko było już prawie dopięte na ostatni guzik i mieliśmy startować z działaniami, aż tu nagle klient wyskakuje z tekstem: tylko żeby nie było za dużo tego całego Scruma. No i tu konsternacja, bo po czym właściwie poznać, że Scruma jest już za dużo? Szybko wyjaśniło się, że w opinii klienta oznaczało to zbyt wiele „dziwnych” spotkań o skomplikowanych nazwach.  

Zespół miał k o d o w a ć.  

No i znowu, musiałem zrobić krok w tył, szybkie warsztaty z metodyki i wyjaśnienie, do czego właściwie służą te egzotycznie brzmiące sprint review, refinement czy retrospektywa. Dlatego tak często podkreślam, że rolą Scrum Mastera jest także budowanie świadomości, iż Scrum to dokładnie przemyślana metodyka, która w zdroworozsądkowy sposób stoi za maksymalizacją skuteczności i produkcyjności zespołów zwinnych.  

W tym przypadku dopiero po drugiej iteracji warsztatów zaobserwowałem u klienta olśnienie, że faktycznie zrobienie refinementu, który trwa dwie godziny, pozwoli zaoszczędzić sześciu godzin na powracające pytania i tłumaczenie zagadnień niejasnych dla zespołu. 

Klątwa Empiku

Widzieliście kiedyś półkę z motywująco-zarządczymi książkami w Empiku? Dziesiątki pozycji obiecujące, że można robić więcej i szybciej. Problem w tym, że niektóre osoby w managemencie czytają okładki, ale nie sięgają po całość.   

W ten sposób, dla zarządu, celem samym w sobie staje się podejście dużo i szybko, bo w końcu — według specjalistów — przecież można. A kiedy projekt nagle się sypie i przychodzi Scrum Master ze swoją zwyczajową opowieścią o wprowadzeniu pewnych zasad, pierwsze co słyszy to: nie, nie, nie, robić, robić, robić.   

Nie ma czasu na Scruma, chociaż projekt w teorii jest w nim realizowany.

Plaga clickabaitów

Jak widać na przykładzie powyżej, Scrum niestety bywa postrzegany przez pryzmat clickbaitowych tytułów i rozdmuchanych obietnic. Wciąż wiele osób myśli, że skoro pracujemy zwinnie, to i zwinnie uporamy się z każdym dodatkowym wymaganiem, które nagle pojawi się w trakcie trwania projektu.  

I teoretycznie tak właśnie jest, tylko odbije się to na harmonogramie i budżecie całości. 

W pracy nie ma cudów.  

Ponadto ujmę to dość kontrowersyjnie, ale Scrum jest metodą tworzenia produktów, a niekoniecznie zarządzania projektem. Jako Scrum Masterzy przede wszystkim trzymamy rękę na pulsie i dbamy o to, żeby powstał wartościowy produkt.

Karny Scrum Master

Na koniec, usłyszałem to kiedyś na żywo i do tej pory trochę śmieje się przez łzy:   

Jak będziecie źle pracować, to dostaniecie Scrum Mastera, który już Wam ten cały Scrum zrobi i to raz-dwa. 

Scrum Master jako członek zespołu

Podsumowując, w projekcie ratunkowym — czyli takim, gdzie Scrum Master „wpuszczany” jest, aby jakoś poprawić wyniki — dużym wyzwaniem jest odczarowanie tej roli w oczach zespołu. Na początku muszę uświadomić, że nie jestem wyjątkowo drogą sekretarką i nie przybywam, żeby ustawiać spotkania w kalendarzu. Jestem strażnikiem logicznie prowadzonego procesu wytwórczego, zgodnego z wizją produktu, a problemy rozwiązuje metodycznie.  

Moją rolą jest, aby ci, którzy dostarczają wartości, dostarczali je z jak najmniejszą liczbą przeszkód.  

I w ludzkich warunkach.  

W końcu najbardziej kreatywni jesteśmy wtedy, kiedy pielęgnuje się naszą godność i sprawczość. 

Być może początek artykułu brzmiał, jakbym narzekał, że większość mojej pracy to audyty i patrzenie na procesy innych. Jednak tak naprawdę bardzo wiele fajnych informacji zwrotnych dostaje się właśnie dzięki takim audytom. Nie zawsze wszystko jest źle, czasem wystarczy mały tuning postępowania, żeby poprawić jakość i wydajność procesu wytwarzania oprogramowania.