Każdy, kto zetknął się ze Scrumem i wie coś o tej metodzie, na pewno słyszał choć raz opinię, że Scrum Master ma dążyć do tego, by Zespół przestał go potrzebować. Taka możliwość wycofania się przez Scrum Mastera z Zespołu ma dowodzić, że ten pierwszy dobrze wykonał swoją pracę, a ten drugi jest już w pełni dojrzały.
Wizja ta czyni pracę Scrum Mastera wyjątkowo niewdzięczną. Jest odpowiedzialny za skuteczność działania Zespołu, ale nie może kierować Zespołem w tradycyjny sposób, bo stłamsi jego rozwój i ograniczy możliwość samozarządzania. Gdy kierownicy kogoś chwalą, to Developerów i Product Ownera, a rzadko Scrum Mastera. Kiedy zaś trzeba kogoś obsztorcować, to Scrum Master często zbiera cięgi, ot choćby za brak wspomnianej powyżej skuteczności. Ma powodować zmianę w organizacji, choć najczęściej nie ma realnej władzy nad niczym… A tu na domiar złego, jego celem jest stanie się zbędnym?!
Na szczęście taka interpretacja odpowiedzialności Scrum Mastera rozmija się z tym, jak definiuje ją Scrum Guide, w którym o znikaniu Scrum Mastera mowy nie ma. Gdyby zresztą miarą sukcesu Scrum Mastera miało być stanie się zbędnym, to ten sukces najłatwiej osiągaliby marni pseudo-Scrum Masterzy. Oni faktycznie są zbędni, a często wręcz szkodzą, więc nawet lepiej, by ich nie było.
Odpowiedzialność, nie stanowisko
Scrum Master to osoba, która nie zajmuje się developmentem ani podejmowaniem decyzji odnośnie do kierunku rozwoju produktu, ale dba o to, by cały Zespół podnosił nieustannie swoją skuteczność w działaniu i postępował zgodnie z zasadami Scruma (skoro się nim posługuje) oraz przez samych członków Zespołu.
Odpowiedzialność taka istnieje w Zespole niezależnie od tego, jak bardzo ten Zespół jest doświadczony, bo wciąż musi dążyć do dalszego rozwoju, podnoszenia skuteczności, usuwania utrudnień itd. Inaczej mówiąc, nawet jeśli jakaś osoba, która jest Scrum Masterem Zespołu, odejdzie – bo uzna, że jest zbędna – to jej odpowiedzialność musi zostać przejęta przez kogoś innego. Formalnie czy nieformalnie, to nie ma znaczenia. Jeśli tak się nie stanie, czyli jeśli Zespół przestanie w ogóle dbać o skuteczność i usprawnienia, szybko dopadną go skutki zaniechań, bo rzeczywistość jest zmienna i trzeba się do niej nieustannie dostosowywać.
Pozorne znikanie
Skąd wziął się w ogóle pomysł, że Scrum Master ma zniknąć? Jest to wynik niezrozumienia tego, jak wraz z dojrzałością Zespołu zmienia się charakter pracy, którą wykonuje w nim Scrum Master. Przesuwa się też obszar jego działania, żeby nadążyć za potrzebami Zespołu.
Na początku Scrum Master zaangażowany jest w liczne działania w samym Zespole, bo też i większość problemów wynika z wewnętrznych ograniczeń Zespołu, który wciąż się dociera i uczy współpracy.
Z czasem to, co sprawia problemy Zespołowi, ale też wszystko to, co daje mu nowe możliwości, uzależnione jest od sposobu funkcjonowania środowiska, czyli organizacji wokół Zespołu. Siłą rzeczy Scrum Master zaczyna potrzebować coraz więcej czasu na interakcje z kierownictwem, ekspertami, innymi Zespołami itd.
Tym samym Scrum Master wciąż pracuje na rzecz swojego Zespołu, ale mniej intensywnie z jego członkami. Przy okazji warto podkreślić, że całkowite skupienie na Zespole i brak interakcji Scrum Mastera z otoczeniem jest błędem niezależnie od poziomu doświadczenia Zespołu. Nawet zupełnie nieogarnięci ludzie, którzy dopiero co zaczęli pracować w Scrumie, będą potrzebować wsparcia, którego Scrum Master nie zdoła im zapewnić bez współpracy np. z kadrą zarządzającą firmy.
Ten proces przesuwania się obszaru skupienia działań Scrum Mastera jest czymś naturalnym, ale ciężko nazwać go znikaniem. Oczywiście jest możliwe, że na jakimś etapie Scrum Master uzna, iż lepiej byłoby, gdyby odpowiedzialność od niego przejął ktoś chętny w Zespole (uwaga: chętny, a nie wyznaczony na siłę!). Może wtedy podjąć współpracę z Zespołem mniej doświadczonym, ale to nie oznaczy, że w tym, z którego odchodzi, Scrum Mastera już nie będzie. Po prostu będzie nim kto inny.
Scrum Master w klatce
Napisałem, że zmiana charakteru pracy Scrum Mastera z czasem w każdym Zespole jest naturalnym procesem, ale bywa, że organizacja tłamsi go lub wypacza różnymi sztucznymi ograniczeniami.
Zdarza się, że Scrum Masterom narzuca się, czym dokładnie mają się zajmować, a czego robić im nie wolno. Wraz ze wzrostem dojrzałości Zespołu spada wtedy możliwość działania Scrum Mastera, aż w końcu dochodzi on do punktu, w którym, aby zrobić cokolwiek, musiałby przekroczyć czerwoną linię wytyczoną przez organizację. Nie każdy zdecyduje się na to, więc trudno dziwić się, że pojawi się w końcu wniosek: Scrum Master jest w tym Zespole zbędny.
Jeszcze częściej można zetknąć się z rozdzieleniem odpowiedzialności między Scrum Masterów, którzy mają zajmować się tym, co dzieje się wewnątrz Zespołu, a Agile coachów, którzy funkcjonują na poziomie organizacji. Skutek jest dokładnie taki sam, jak powyżej: gdy możliwości skutecznego działania Scrum Mastera wyczerpią się, pojawi się wniosek, że Zespół go nie potrzebuje i od tej pory pomagać będą mu Agile coachowie.
Z punktu widzenia Scruma jest to pozbawione sensu, bo każdy Scrum Master to Agile coach. Ma działać tak, by skutecznie pomagać swojemu Zespołowi, który dzięki temu przynosi korzyści organizacji. Jeśli wymaga to współpracy z ludźmi spoza Zespołu (a jest oczywiste, że tak właśnie jest), ma tę współpracę nawiązać.
Dla porządku: nie neguję tu wartości Agile coachów pracujących poza Zespołami i pomagających różnym obszarom organizacji. Zwracam jedynie uwagę na patologię, która zdarza się w wielu miejscach, w których ci, co powinni być coachami, są przede wszystkim Coachami – piastują stanowisko (stąd zapis dużą literą) i bronią swojego obszaru wpływu, by jacyś tam szeregowi Scrum Masterzy nie błąkali się po nim. Prawdziwy coach zwalczałby takie zjawisko i pomagał Scrum Masterom, zamiast ich ograniczać.
Nieporozumienie i jego skutki
Wróćmy do przekonania, że Scrum Master powinien zniknąć z Zespołu. Jest szkodliwe z wielu powodów.
Jednym z nich mogą być chybione oczekiwania ze strony przełożonych Scrum Mastera (a może i jego samego), by jak najszybciej stać się zbędnym, skoro to dowodzi, że misja zakończyła się sukcesem. Prowadzi to do świadomego lub podświadomego ignorowania problemów, którymi Scrum Master powinien się zająć, albo wręcz glejtowania pseudo-Scruma jako poprawnego procesu, żeby tylko móc powiedzieć „Zespół już mnie nie potrzebuje”.
Innym może być rosnąca frustracja Scrum Mastera, który ma poczucie, że sobie nie radzi. Miał stawać się zbędny, a tu jakoś ciągle ręce ma pełne roboty. Co prawda rodzaj tej pracy jest cały czas inny, a i problemy bardziej subtelne, ale wciąż trzeba pracę Scrum Mastera wykonywać. „Ani chybi coś robię nie tak” – myśli sobie Scrum Master, a przecież jest dokładnie na odwrót. Po tym, gdy już udało się zrobić to, co proste, widoczne stały się problemy mniej oczywiste, ale równie mocno (albo i bardziej) wymagające pracy od Scrum Mastera.
Kolejny problem pojawia się w firmach, w których Scrum Masterzy nie mają szans przejść do innego Zespołu, a droga awansu jest zamknięta – bo np. trzeba by zostać Agile Coachem (znów dużą literą), to stanowisko zaś aktualnie jest obsadzone. Tacy Scrum Masterzy albo stają się Developerami, albo – jeśli byli jednocześnie Developerem i Scrum Masterem – wracają do developmentu na pełen etat. Misja wykonana, Scrum Master może zniknąć…
Długofalowe skutki przekonania o potrzebie stania się zbędnym są smętne: organizacje dochodzą do wniosku, że faktycznie nie ma sensu inwestować w zatrudnianie i wykształcanie Scrum Masterów, bo w końcu i tak nie będą potrzebni. Niech więc Zespoły jakoś sobie poradzą bez nich.
I te Zespoły sobie radzą, ale pod jednym warunkiem: że odpowiedzialność Scrum Mastera w nich funkcjonuje, czyli że ktoś wziął na siebie obowiązek dbania o skuteczność działania, o proces itd. Nieoficjalnie, bo wiadomo: Scrum Masterzy są zbędni!
Znikanie? Nie, zmiana
W normalnej sytuacji powinno to wyglądać zdecydowanie inaczej. Scrum Master zaczyna coraz więcej pracować poza Zespołem, a jeśli faktycznie sam uzna, że może podjąć się obowiązków Scrum Mastera w kolejnym Zespole, robi to. Wcześniej przekazuje swe obowiązki w kolejne ręce kogoś, kto od teraz będzie Scrum Masterem.
Może też pozostać w Zespole, wciąż jako Scrum Master, a jednocześnie zacząć pracować z Zespołem kolejnym. Ten pierwszy wymagał będzie mniej uwagi i pomocy, więc skupi się nieco bardziej na drugim.
Lub, bo i taka opcja jest możliwa i sensowna, zwłaszcza jeśli Scrum Master jest jednocześnie Developerem, zacznie więcej czasu poświęcać tej drugiej odpowiedzialności. Co nie oznacza, że zaprzestanie być Scrum Masterem – pozostanie nim i wykonywał będzie niezbędną pracę za każdym razem, gdy ujawni się taka potrzeba.
Scrum Master do emerytury?
To, co piszę, może prowokować do pytania: a co, jeśli Scrum Master wyczerpie w jakiejś organizacji wszystkie możliwe obszary swojej działalności i uzna, że za mało jest pracy, jaką miałby wykonywać? Albo, że praca ta już nie daje mu satysfakcji, bo nie pozwala dalej się rozwijać?
Cóż, nie można być Scrum Masterem w nieskończoność, a już na pewno nie w jednej firmie przez lata. Kiedyś trzeba podjąć decyzję, by iść dalej: zająć się zarządzaniem organizacją jako manager, produktem jako Product Owner itd. Albo zostać Agile coachem, ale takim dobrze rozumianym, nie zaś siewcą patologii.
A jeśli ktoś nadal chce być Scrum Masterem, ale nie kosztem blokowania przestrzeni dla rozwoju innych osób (bo chce im ustąpić pola), i nie kosztem zatrzymania rozwoju własnego? Powinien poszukać kolejnej organizacji i powtórzyć w niej od nowa cały proces, począwszy od pracy głównie w Zespołach i z Zespołami, aby znów dojść do pracy przede wszystkim na rzecz Zespołów i z organizacją.
Przy czym w żadnym z opisanych przypadków kolejne decyzje zawodowe Scrum Mastera nie będą wynikać z dążenia do zniknięcia z Zespołu, ale z chęci rozwoju lub odkrycia, że zgromadzony potencjał doświadczeń i umiejętności można wykorzystać w nieco inny sposób, niż do tej pory.
Zadanie domowe dla Scrum Masterów
Jeśli jesteś Scrum Masterem i wierzysz w misję samounicestwienia – zachęcam cię do szybkiej refleksji i przewartościowania stawianych sobie celów. Różne mogą być wnioski, w tym i takie, że „Scrum Master to nie praca dla mnie”. I świetnie, bo ciężko robić z pasją i dobrze coś, co nie daje satysfakcji (jest to jednak możliwe, wszystko jest kwestią dyscypliny i profesjonalizmu).
Warto też upewnić się, że ludzie w organizacji (nie tylko w Zespole, którego jesteś częścią) nie utożsamiają Scrum Mastera po prostu ze stanowiskiem pracy, z którym wiąże się jakiś kanon zdefiniowanych czynności do wykonywania. To, co robi Scrum Master, zależy od poziomu doświadczenia i potrzeb Zespołu, ale też i potrzeb organizacji. Zadbaj, by osoby, z którymi współpracujesz, rozumieli, dlaczego to ważne i jakie daje korzyści.
A jeśli pojawiają się pytania o to, czy na pewno Scrum Master jest potrzebny? Z jednej strony stanowią sygnał, że być może zrozumienia odpowiedzialności Scrum Mastera brak. Z drugiej strony, to może być sygnał, że jako Scrum Master nie tyle udało ci się osiągnąć ów mityczny stan, gdy możesz zniknąć, ile że niewielki z ciebie pożytek…
W tym drugim przypadku pilnie ustal, czy ocena ta nie jest uzasadniona, bo być może faktycznie robisz za mało? Albo niewłaściwe rzeczy? Albo działasz nieskutecznie i nawet o tym nie wiesz?
