Jakiś czas temu pisałem o cechach, jakie moim zdaniem powinien mieć skuteczny Scrum Master. Nie stawiałem tezy, że ktoś, kto taki nie jest, nie ma szans na osiągnięcie skuteczności ani – tym bardziej – że na Scrum Mastera się nie nadaje. Osiągnięcie mistrzostwa w każdej dziedzinie wymaga przecież ciągłej nauki, ciężkiej pracy, zbierania doświadczeń i wyciągania wniosków z nieuniknionych porażek. Tylko nieliczni mają wrodzony talent, niektórym pomoże szczęście, a większość musi cierpliwie inwestować czas i wysiłek w samorozwój.
Zdarza się przy tym, że niezależnie od aspiracji zawodowych i czynionych zabiegów, ktoś pozostaje Scrum Masterem słabym, a niektórzy wręcz szkodzą swoim Zespołom oraz organizacjom, zamiast im pomagać. I o takich właśnie Scrum Masterach jest ta krótka seria trzech artykułów.
A zacząć muszę od kilku ważnych zastrzeżeń.
Po pierwsze, dzielę się moimi obserwacjami i przemyśleniami, z którymi nie każdy musi się zgodzić. Nie próbuję stworzyć definicji kiepskiego Scrum Mastera, a jedynie podpowiadam różne wzorce, które mogą, ale nie muszą świadczyć, że Scrum Master marnie sobie radzi.
Po drugie, jeśli ktoś dopiero co podjął się obowiązków Scrum Mastera i ma w tym znikome doświadczenie, niemal na pewno będzie działał nieporadnie. Nie oznacza to, że się do tego nie nadaje. To, o czym piszę, dotyczy osób, które jako Scrum Masterzy pracują długo, byli częścią wielu Zespołów, nierzadko w różnych organizacjach.
Po trzecie wreszcie, moją intencją jest dostarczenie inspiracji samym Scrum Masterom, żeby ułatwić im podejmowanie decyzji odnośnie do swojego rozwoju, skupienie się na jakimś zaniedbanym aspekcie swojej pracy albo… cóż, rezygnację z obowiązków, które nie są dla nich. Bo i tak bywa, że ktoś nie nadaje się na Scrum Mastera i pozostając nim, męczy tak siebie, jak innych.
Po tym przydługim wstępie pora pochylić się nad różnymi przejawami tego, że Scrum Master wcale nie jest takim mistrzem Scruma, jakim być powinien.
Nie potrafi wyjaśnić zasad Scruma
Żeby ktoś z sensem użył metody, musi nie tylko znać obowiązujące w niej zasady, ale też rozumieć, z czego one wynikają. Mechanistyczne stosowanie praktyk, których wartości się nie dostrzega, prowadzi do szybkiego degradowania tak sposobu pracy, jak i zaangażowania w nią ludzi.
Kiepski Scrum Master albo nie potrafi wyjaśnić, jak działa Scrum, dlaczego działa i jak uzyskać z niego korzyści, albo wręcz sam tego tak naprawdę nie wie. Zdarza się, że jedynym argumentem za tym, by coś robić lub z czegoś zrezygnować, jakiego używa, jest „bo tak napisano w Scrum Guide”. Oczywiście na pytanie o to, skąd wziął się taki zapis, kiepski Scrum Master nie będzie miał dobrej odpowiedzi.
Nie potrafi pokazać pragmatyzmu Scruma
Nadmierne posiłkowanie się definicją metody i używanie jej zapisów jako koronnego argumentu za takim lub innym postępowaniem Zespołu często skutkuje uznaniem przez Product Ownera i Developerów, że Scrum to teoria oderwana od rzeczywistości. Zwłaszcza jeśli Scrum Master nie potrafi wyjaśnić, skąd się wzięła.
Częste sięganie po Scrum Guide samo w sobie nie jest błędem – warto to robić, ale nie zamiast wyjaśnienia, jak coś w tej metodzie jest zdefiniowane, ale po wyjaśnieniu jakiejś kwestii. Przykładowo, jeśli Product Owner nie bierze udziału w Retrospekcjach Sprintów z jakiegoś powodu, to chybionym argumentem będzie, że ma się na nich pojawiać, bo tak napisali twórcy metody. Scrum Master przede wszystkim powinien poprowadzić dyskusję tak, by negatywne skutki nieobecności Product Ownera stały się jasne dla wszystkich, podobnie jak korzyści z jego pojawiania się na Retrospekcjach.
I dopiero podsumowując dyskusję, warto powiązać to z definicją Scruma, przez co zaczyna ona być postrzegana nie jako teoria oderwana od rzeczywistości, ale zbiór bardzo pragmatycznych zasad.
Łamie zasady, których uczy innych
Nikt nie lubi hipokrytów, więc Scrum Master niezdolny do postępowania wedle reguł, jakich naucza, zaczyna być ignorowany. Do tego daje silny sygnał, że sam nie wierzy w te reguły. I niestety często tak właśnie jest w przypadku kiepskich Scrum Masterów – radzą sobie marnie, bo tak naprawdę nie rozumieją Scruma, albo wręcz nie zgadzają się z sensownością obowiązujących w nim zasad. Pozostaje tajemnicą, co spowodowało, że podjęli się obowiązków Scrum Mastera…
Nie potrafi działać w duchu wartości Scrum
Niektórzy kiepscy Scrum Masterzy dają jasno do zrozumienia, że wartości to „pitolenie”, a tak naprawdę w Scrumie chodzi o to, żeby dużo „dowieźć”. Są też tacy, którzy co prawda nie wywnętrzają się z pogardą dla wartości Scrum, ale jak ognia unikają mówienia o nich, jakby to było coś złego lub wstydliwego. A przecież nie da się kierować w postępowaniu wartościami, o których nie jest się gotowym rozmawiać z innymi ludźmi i przekonywać ich do uznania ich za własne (nie mylić z indoktrynowaniem lub jakimś chybionym fundamentalizmem).
Najwięcej kiepskich Scrum Masterów ma do wartości stosunek po prostu obojętny, czyli niespecjalnie przejmują się ich naruszaniem lub brakiem w Zespole, ani nie próbują nic zrobić, by je wzmocnić. Dzieje się tak zwykle dlatego, że nie rozumieją związku wartości Scrum z zaufaniem pomiędzy uczestnikami procesu empirycznego, bez którego proces ten nie ma szans dobrze działać.
Redukuje Scrum do metody organizacji pracy Zespołu
Scrum nie służy do zarządzania developmentem produktu czy Zespołem jako takim, nie ma do tego stosownych mechanizmów, ról, zasad itd. Mimo to przez wielu użytkowników jest stosowany właśnie tak, jakby był metodą organizacji pracy i niczym więcej.
Kiepscy Scrum Masterzy albo sami tak postrzegają Scruma, albo nie potrafią wyjaśnić Zespołom i organizacji, że to nieporozumienie. Scrum jest przecież tylko szkieletem procesu empirycznego, zbiorem podstawowych zasad, którymi Zespół może się kierować, żeby zorganizować pracę nad rozwojem produktu w sposób przynoszący wymierne korzyści interesariuszom.
Nie rozumie czym jest empiryzm
Skoro mowa o empiryzmie, to kiepscy Scrum Masterzy zwykle nie potrafią po ludzku wytłumaczyć, co to w ogóle jest i jak praktycznie użyć empirycznej kontroli nad jakimś procesem. Znają teorię i potrafią sypać jak z rękawa przykładami i hasłami, które są piękne, ale potem nie potrafią nijak spowodować, żeby Zespół użył empiryzmu w praktyce.
Skutkiem tego są Backlogi Produktów, które stanowią w istocie plany projektów realizowanych tylko z pozoru zwinnie. Innym skutkiem jest wprowadzanie zmian w produkcie raz-a-dobrze, zamiast ewolucyjnego – czyli iteracyjnego i przyrostowego – ich wdrażania. Jeszcze kolejnym: traktowanie Sprintów po prostu jako kontenery na wykonanie kolejnego zestawu elementów z Backlogu Produktu.
Nie wierzy w istnienie niestabilnej złożoności
Często niezrozumienie, czym jest empiryzm i nieumiejętność jego zastosowania, idzie w parze z brakiem wiary, że problemy faktycznie mogą być złożone i wymagać eksperymentowania, zanim zostaną rozwiązane.
Mamy wtedy do czynienia ze Scrum Masterem, który z jednej strony naucza, jak podejście inkrementalne i iteracyjne pozwala lepiej radzić sobie ze złożonością, a z drugiej jest przekonany, że gdyby więcej czasu poświęcić na dobrą analizę i zrobić lepszy plan, żadne Sprinty i inne scrumowe wynalazki nie byłyby potrzebne…
Niewiara w istnienie problemu, który ma rozwiązać metoda, jakiej stosowania ma się nauczyć innych, skutkuje dość miernymi wynikami owego nauczania. Dlatego kiepscy Scrum Masterzy często pchają Zespół w stronę realizacji klasycznych projektów ukrytych za etykietkami elementów Scruma.
Trzyma się z daleka od zarządzania produktem
O tym, jaki produkt ma powstać, w Scrumie decyduje Product Owner. O tym, jak taki produkt zbudować, decydują Developerzy. Można więc powiedzieć, że wspólnie zarządzają oni tym produktem, dbając o jego wartość i jakość tak użytkową (funkcjonalną), jak i techniczną (strukturalną).
Kiepscy Scrum Masterzy nie uważają za zasadne współuczestniczyć w tym procesie zarządzania produktem, ograniczając się jedynie do sprawdzania, czy wszystko odbywa się zgodnie z zasadami zapisanymi w Scrum Guide. Nie przychodzi im do głowy, że jeśli Product Owner będzie podejmował kiepskie decyzje i Zespół wytworzy coś, co jest niepotrzebne, to współwinnym tej katastrofy jest Scrum Master. Podobnie jak jest współwinnym dostarczania bubli, które nie nadają się do użytku, bo Developerzy nie potrafią albo nie chcą zadbać o jakość tego, co dostarczają.
Tacy Scrum Masterzy, gdy zapyta się ich, za co zatem odpowiadają w Scrumie, wyjaśnią, że za zarządzanie procesem. I to rozumianym właśnie jako „doprowadzenie do tego, żeby wszystko odbywało się zgodnie z definicją Scruma”. A przecież można budować zbędne buble w myśl tej definicji, jeśli Zespół tego zechce albo jeśli nie wie, jak Scruma użyć z sensem.
Nie potrafi wyjaśnić, po co jest potrzebny
Stąd już tylko krok do kolejnego problemu, jakim jest problem z określeniem, po co w Scrumie jest Scrum Master. Kiepscy Scrum Masterzy zapytani o to uciekają w wysokopoziomowe hasła i komunały, z których nie wynika żadna wymierna odpowiedzialność za cokolwiek, albo zaczynają wymieniać listę czynności, jakie wykonują. Zupełnie tak jakby sama konieczność ich wykonania uzasadniała potrzebę istnienia Scrum Mastera.
Zapytani o to, czemu nie mogliby tego zrobić Developerzy albo Product Owner, odpowiadają zwykle, że „nie mogą, bo nie są Scrum Masterami”.
Gdy zasugerować im, że mają zbudować środowisko pozwalające na działanie Scruma, są zdziwieni albo protestują, że przecież nie mają wpływu na organizację, a to ona (jej kierownictwo) podejmuje takie decyzje.
Gdy powiedzieć, że Scrum Master odpowiada za skuteczność Zespołu, czyli zdolność do dostarczenia interesariuszom tego, czego oni potrzebują we właściwym momencie i w akceptowalnej cenie, oburzą się, że za zarządzanie produktem odpowiada przecież Product Owner.
Gdy docisnąć kiepskiego Scrum Mastera pytaniami o to, jak pomaga w podniesieniu efektywności developmentu, usłyszeć zwykle można, że Scrum Master nie jest Developerem. No, chyba że akurat jest, wtedy piorunem zorientujemy się, że tak naprawdę od samego początku rozmawiamy właśnie z Developerem, a ta etykietka „Scrum Master” to się mu do podeszwy przylepiła przez przypadek…
Boi się zwolnienia, więc zbiera dowody swej przydatności
Każdy Scrum Master wcześniej czy później zapytany zostanie przez Zespół albo kogoś spoza Zespołu: czym ty się właściwie zajmujesz? Kiepski Scrum Master nie uzna tego pytania za sygnał, że być może nie jest wystarczająco skuteczny i nie poszuka sposobu, by to zmienić. Zamiast tego skupi się na gromadzeniu „kwitów”, które mają dowodzić, że jest efektywny i dużo robi.
A jeśli kłopotliwe pytania będą się powtarzać, zacznie szukać sposobów, by ludzi zniechęcić do ich zadawania, np. wykazując im, że robią coś nie tak, zasłaniając się zapisami w Scrum Guide itd.
Na wszelki wypadek kiepscy Scrum Masterzy unikają angażowania się w tematy trudne, bo wymagają one dużo wysiłku i niosą ryzyko niepowodzenia, a w międzyczasie można zająć się wieloma drobiazgami i głośno krzyczeć, jak to dużo się robi. Zwykle w parze z takim postępowaniem Scrum Mastera idzie narastające poczucie wśród jego współpracowników, że żadnego pożytku z niego nie ma, a niektórzy tę niechęć do „mistrza” w Scrumie przenoszą na samą metodę.
Uważa, że im mniej robi, tym lepiej
Są i tacy Scrum Masterzy (też kiepscy), którzy przeczytali lub usłyszeli gdzieś, że powinni dążyć do stania się zbędnym w Zespole. I wyciągnęli wnioski, że miarą sukcesu Scrum Mastera jest możliwość bycia bezczynnym. Dlatego nie dość, że nie boją się oskarżeń o lenistwo, to jeszcze się nim szczycą.
Tacy Scrum Masterzy są kiepscy przede wszystkim dlatego, że nie tylko nie potrafią w niczym pomóc swym Zespołom i organizacji, ale mogą wręcz – kierując się własnym interesem – zacząć szkodzić, np. zaprzeczając istnieniu jakiegoś problemu, którym ewidentnie należałoby się zająć. Tyle że wtedy Scrum Master musiałby przyznać, że sytuacja wciąż daleka jest od ideału.
Ciąg dalszy w kolejnym artykule
Aby uniknąć publikowania zbyt długiego tekstu, podzieliłem całość na trzy części. Zapraszam do lektury drugiego artykułu z tej serii, w którym opisuję jedenaście kolejnych objawów tego, że ktoś nie jest zbyt dobrym Scrum Masterem.
