W pierwszej części krótkiej serii artykułów o umiarkowanie wydarzonych Scrum Masterach opisałem jedenaście różnych objawów tego, że z kimś takim mamy do czynienia. Pora kontynuować tę ponurą wyliczankę.
Boi się zmian i podejmowania ryzyka
Kiepscy Scrum Masterzy mogą szkodzić poprzez zaniechanie działań, które są potrzebne, ale zmuszałyby Scrum Mastera do podjęcia ryzyka lub pozbawiłyby go poczucia stabilności, w jakim aktualnie funkcjonuje. Oczywiście mowa tutaj o ryzyku uzasadnionym, którego podjęcie wynikać powinno nie z lekkomyślności, ale z dążenia do uzyskania czegoś wartościowego.
Zdarza się niestety, że Scrum Masterzy, ważąc za i przeciw, kierują się własnym interesem, a nie odpowiedzialnością za skuteczność Zespołu, dlatego nie robią tego, co robić powinni. Efektem jest brak eliminacji utrudnień i ograniczeń, które negatywnie wpływają na możliwości działania całego Zespołu albo wymiernie mu szkodzą. Grunt, że Scrum Master jest bezpieczny. Kiepski Scrum Master, bez dwóch zdań.
Broni status quo, zamiast je zwalczać
Przy czym nie zawsze musi to być wyrachowana decyzja, czasami dzieje się to bezwiednie. Brak otwartości na zmiany powoduje, że rozważając jakieś działanie, Scrum Master zaczyna sam siebie przekonywać, że może i nie jest idealnie, ale zmiany mogą pogorszyć stan spraw, więc lepiej nie ryzykować. Taka postawa jest wysoce zakaźna i łatwo przenieść ją na cały Zespół, a wtedy brak rozwoju i zamiatanie problemów pod dywan jest niemal pewne.
Żeby podnieść skuteczność Zespołu i uzyskać nowe możliwości, konieczne jest usunięcie ograniczeń, które wynikają ze stanu spraw, jaki istnieje obecnie. Brak ochoty na zwalczanie status quo (nie dla zasady, bezmyślnie, ale w sposób świadomy, w ramach dążenia do udoskonaleń) to jedna z cech, która właściwie dyskwalifikuje Scrum Mastera.
Osoba taka musi być agentem zmiany i nieustannie poszukiwać sposobu na zrobienie lepiej czegoś, co już działa dobrze – bo zawsze się da to zrobić. Zdecydowanie nie powinien Scrum Master być kimś, kto poklepuje wszystkich po plecach, mówiąc, że „jest dobrze, tak jak jest”. Bezczynność i brak rozwoju spowodują, że rzeczywistość wyprzedzi Zespół i nagle to „jest dobrze” okaże się stanem zupełnie katastrofalnym.
Redukuje swoją pracę do zdefiniowanej listy działań
Kiepscy Scrum Masterzy często trzymają się jakiejś mniej lub bardziej formalnej listy czynności, które mają wykonywać. Nierzadko są to opisy stanowisk, na jakich są zatrudnieni w firmach, ale bywa, że sami sobie taką listę tworzą, posiłkując się wsparciem „ekspertów”, którzy w dobrze działającym Scrumie nigdy nie mieli okazji pracować.
W skrajnym przypadku tacy Scrum Masterzy wręcz posługują się procedurami lub swoistymi algorytmami, zupełnie nie zastanawiając się, czy w bieżącej sytuacji jakieś inne działanie – spoza predefiniowanej listy – nie byłoby lepsze.
O ile niedoświadczeni Scrum Masterzy potrzebują wielu podpowiedzi, o tyle od kogoś, kto już z wieloma Zespołami pracował i z różnymi organizacjami się zetknął, można oczekiwać, że będzie w stanie wymyślić coś nowego, dokonać fuzji różnych praktyk itd. – zależnie od potrzeb. Brak takiej umiejętności nie jest czymś tragicznym, bo i tego można się nauczyć. Tragiczny natomiast jest brak świadomości, że trzeba się tego nauczyć. Ewentualnie brak starań, by to zrobić.
Jest fundamentalistą
Trzymanie się jakiegoś zamkniętego kanonu „zalecanych” działań Scrum Mastera może przybrać bardziej skrajną formę scrumowego fundamentalizmu, połączonego z faryzejskim podejściem do zasad metody. Ten rodzaj kiepskich Scrum Masterów stawia sobie za cel uzyskanie zgodności z zapisami Scrum Guide, zupełnie nie dbając o to, czy idzie za tym wymierna wartość dla kogokolwiek i czy aby nie są to po prostu jedynie pozory zgodności.
Zdarzają się również fundamentaliści, którzy świetnie rozumieją Scruma i nawet potrafią go nauczyć innych, jednak mają zbyt radykalne podejście i przez to są przez Zespoły odrzucani. To ludzie, którzy działają w myśl zasady, że tylko Scrum jest dobry i to niezależnie od tego, do czego ktoś zechce go użyć (a to nieprawda).
Innym przykładem szkodliwego fundamentalizmu jest uznanie, że tylko idealny sposób działania jest właściwy, przez co kiepski Scrum Master, zamiast pomóc ludziom w dokonaniu usprawnień, oczekuje od nich dokonania cudu tu i teraz. A gdy cud nie następuje (bo co niby miałoby go spowodować), taki nieudolny Scrum Master rujnuje swe relacje z Zespołem i zniechęca go do metody, nieustannie oskarżając, że wszystko robią źle. Przy czym zwykle twierdzi, że robi to, bo na tym rzekomo polegać ma jego praca… Dlatego krytykuje do upadłego wszystko, co nie jest ideałem. I na koniec jest wywalany z hukiem z Zespołu, chyba że zdoła zawczasu doszczętnie zaszczuć ludzi, z którymi pracuje.
Pajacuje i oczekuje pajacowania od innych
Każdy pewnie zetknął się z osobnikiem zachowującym się niczym wodzirej, który przez pomyłkę zamiast na wesele pojawił się na stypie. Niektórzy kiepscy Scrum Masterzy w ten właśnie sposób próbują stworzyć na siłę dobrą atmosferę i tym samym spowodować, że praca stanie się dla ludzi zabawą. Nie zadają sobie jednak zawczasu trudu sprawdzenia, czy na pewno Zespół, z którym pracują, ma na coś takiego ochotę.
A wiele Zespołów z różnych powodów nie ma ochoty na gry i zabawy – albo w ogóle, albo przynajmniej w tym momencie, gdy Scrum Master próbuje zamienić miejsce pracy w piaskownicę. Takie nietrafione pajacowanie, często połączone z zewnętrzną presją „doradców”, którzy zasugerowali, że to na pewno pomoże Zespołom, doprowadziło do erozji poważania dla Scrum Masterów wśród wielu Developerów i Product Ownerów.
Jeśli dziś ktoś wciąż sięga po infantylne artefakty i zamienia przestrzeń Zespołu w przedszkole, ignorując przy tym sugestie, że nikt nie ma na to ochoty, to dobrym Scrum Masterem nie jest, bo ci potrafią dobrać sposób działania do charakteru ludzi, z którymi pracują.
Znika, gdy jest potrzebny, bo ma inne obowiązki
Wielu Scrum Masterów łączy tę odpowiedzialność z pracą jako Developer albo Product Owner (rzadziej, bo to trudne), ewentualnie ze zobowiązaniami poza Zespołem. Umiejętność zarządzania swoją pracą w takiej sytuacji jest kluczowa.
Kiepscy Scrum Masterzy zwykle są bardziej chętni wziąć na siebie wiele obowiązków naraz, a potem gorzej sobie z nimi radzą. Przykładowo, godzą się na podział w rodzaju „80% czasu na development jako Developer w Zespole, 20% na obowiązki Scrum Mastera”, po czym twardo trzymają się tych proporcji, nawet jeśli bieżąca sytuacja wymaga pilnie działania Scrum Mastera niemal na pełen etat.
Inny przykład braku radzenia sobie z takim podziałem to skupienie się na developmencie, gdy Sprint się kończy, bo „trzeba dowieźć jak najwięcej”. Przez to Zespół w praktyce traci Scrum Mastera w momencie, gdy mógłby on pomóc w takim zorganizowaniu pracy wszystkich Developerów, by faktycznie udało się zrealizować maksymalną liczbę rzeczy.
Nie pracuje z otoczeniem Zespołów
Scrum Master pracuje na rzecz swojego Zespołu, ale nie oznacza to, że wyłącznie w nim. W miarę, jak Zespół staje się coraz bardziej dojrzały, utrudnienia i ograniczenia, jakie godzą w jego skuteczność, coraz rzadziej mają źródło w nim samym. Oznacza to, że ich rozwiązanie leży poza Zespołem i Scrum Master powinien pomóc w odnalezieniu tego rozwiązania, nierzadko sam o nie zabiegając.
Brak umiejętności pracy z otoczeniem, świadomości takiej potrzeby lub ochoty, by ją podjąć, źle świadczy o Scrum Masterze. W praktyce prowadzi do tego, że spełnia się wspomniana już wcześniej fałszywa przepowiednia o tym, jakoby z czasem Scrum Master miał stać się zbędny. Stanie się zbędny, jeśli wszystko, co potrzebne Zespołowi, można uzyskać z zewnątrz, a Scrum Master nie potrafi tego zrobić, nie chce mu się tym zająć, albo w ogóle nie wie, że to jego obowiązek.
Nie potrafi zbudować rozwijającego się Zespołu
Może być i tak, że Zespół istnieje już długo, a mimo to wciąż kluczowe problemy, z jakimi się boryka, mają swoje źródło w samym Zespole, nie zaś w jego otoczeniu. Wtedy faktycznie można powiedzieć, że skupienie Scrum Mastera na pracy z Developerami i Product Ownerem jest do pewnego stopnia uzasadnione, tylko że… no, cóż, efektów tej pracy jakby nie widać.
Jeśli Scrum Master nie potrafi pomóc Zespołowi uwolnić się od wewnętrznych ograniczeń, choćby poprzez zaangażowanie w to organizacji (jej kierownictwa) i nie następuje przynajmniej powolny rozwój, to ciężko uznać, że wywiązał się dobrze ze swego obowiązku.
Oczywiście są przypadki Zespołów tak beznadziejnie źle skonstruowanych i zarządzanych, że nijak nie da się im pomóc. Niemniej w takim przypadku Scrum Master powinien być tym, który uświadomi to organizacji, a jeśli ma ona to gdzieś (zdarza się i tak), logiczną konsekwencją będzie rezygnacja z misji Scrum Mastera w tym konkretnym Zespole.
Jest dyrektywny bez potrzeby i bez umiaru
Zanim Scrum Master wywiesi białą flagę, powinien wykorzystać wszystkie siły i środki, w jakie wyposaży go organizacja i którymi sam dysponuje (umiejętności, wiedza itd.). Nie jest bowiem prawdą, że Scrum Master nie może niczego się domagać, niczego narzucać, niczego nakazać – jeśli to potrzebne i jeśli zdoła to zrobić, ma prawo tak postąpić.
W praktyce oznacza to, że czasami dyrektywna postawa jest niezbędna, ale należy się z niej cofać tak szybko, jak to tylko możliwe, by pozostawić przestrzeń dla Zespołu do nauki samozarządzania swoją pracą.
Są jednak Scrum Masterzy, którzy zauważyli, że są w stanie zarządzać swoimi Zespołami niczym kierownicy, a wtedy zdecydowanie łatwiej uzyskać to, co wydaje im się korzystne. I nie porzucają dyrektywnej postawy niezależnie od sytuacji. Zamiast budować Zespoły zdolne do samodzielnego działania, uzależniają je od siebie, tłamsząc ich rozwój. A pytani o motywację, uzasadniają to koniecznością zapewnienia wysokiej skuteczności działania, co dowodzi, że zupełnie nie zrozumieli, w jaki sposób Scrum Master powinien do niej dążyć wraz z Zespołem.
Jest zbyt wycofany i nie działa, gdy powinien
Nie zawsze brak wyczucia Scrum Masterów skutkuje nadmiernie dyrektywną postawą, bywają kiepscy Scrum Masterzy, którzy tak boją się zaszkodzić swoim Zespołom, że nie podejmują interwencji nawet w sytuacjach krytycznych. Są niczym pilot na statku, który widzi, że sternik wybrał nieprawidłowy kurs, ale nie mają odwagi sami złapać za koło sterowe, nim dojdzie do katastrofy.
O ile niedoświadczony Scrum Master może mieć problemy z dobraniem sposobu działania właściwego do sytuacji, o tyle ktoś, kto pracował już z kilkoma Zespołami i zetknął się z różnymi sytuacjami, powinien mieć dość wyczucia, by nie pozostawać bezczynnym zbyt długo. Jeśli tego wyczucia nie nabył, być może nie będzie nigdy dobrym Scrum Masterem…
Do wszystkiego próbuje użyć coachingu
Wielu Scrum Masterów uważa – nie wiem, czy na pewno słusznie – że postawa coachingowa jest najlepszą, jaką mogą przyjąć w swej pracy. W ten sposób pozostawiają maksymalną przestrzeń do działania i podejmowania osobom, z którymi pracują. Ja dodam złośliwie, że pozostawiają tym osobom całość odpowiedzialności za skutki… ale na ten rant przyjdzie pora w osobnym artykule.
Zgadzam się, że warto sięgać po postawę coacha, gdy tylko jest taka możliwość, tyle że często potrzeba działać o wiele mniej subtelniej i szybciej. W szczególności, jeśli z Zespołu właśnie zwolniła się kluczowa osoba, której kompetencje ciężko będzie zastąpić, a do tego popsuło się ważne narzędzie, bez którego bardzo trudno zrobić cokolwiek, Scrum Master jako coach w niczym nie pomoże. Co najwyżej dostarczy swojemu Zespołowi argumentów do twierdzenia, że jest bezużyteczny.
Nadmierne zachłyśnięcie się coachingiem i szczycenie się, że przede wszystkim taką postawę przyjmuje się w pracy, może być – choć niekoniecznie musi – sygnałem, że Scrum Master kiepsko rozumie swoją odpowiedzialność.
Zakończenie w kolejnym artykule
Pozostało kolejnych jedenaście objawów tego, że ktoś może być kiepskim Scrum Masterem. Opisuję je w kolejnym, ostatnim już artykule z tej krótkiej serii.
