Gdy pierwsze Zespoły eksperymentowały z metodą, która później nazwana została Scrumem, większość tworzących je osób zajmowała się developmentem. A że Scrum narodził się w środowisku wytwórców oprogramowania, znakomita część jego pierwszych użytkowników potrafiła napisać działający kod. Ostatnia dekada XX wieku to były wciąż czasy, gdy do pracy w IT skłaniała ludzi nie chęć zysku, ale zainteresowanie programowaniem i komputerami.

Można zatem powiedzieć, że wszyscy w tych Zespołach byli Developerami. O Scrum Masterach nikt na początku nie myślał – taka odpowiedzialność wyłoniła się z czasem, bo prawie zawsze któryś z Developerów zaczynał większą uwagę zwracać na sposób organizacji pracy, proces używany przez Zespół, ustalanie jasnych reguł współpracy z otoczeniem itd. W końcu stało się jasne, że nie jest to jakaś specyficzna działalność developerska, ale coś innego, development uzupełniającego. Takie osoby stawały się swoistymi opiekunami Scruma w swoich Zespołach, lokalnymi mistrzami w jego stosowaniu. Stąd i nazwa, jaką nadano tej odpowiedzialności.

Warto zauważyć, że pierwsze Zespoły Scrum sięgały po metodę, bo szukały dobrego narzędzia, które pomogłoby im w lepszym radzeniu sobie z tym, co chcieli autentycznie zrobić. I zarządzane były przez ludzi, którzy dążyli do tego samego, a często sami byli częścią takich Zespołów, więc doskonale rozumieli potrzeby Developerów.

W środowisku ludzi zmotywowanych i kompetentnych, do tego mających wystarczającą swobodę, by wykorzystywać kreatywność i potencjał, Scrum dawał świetne rezultaty. Również wtedy, gdy był jeszcze nieco kulawy i miał przed sobą długą ewolucję do postaci, jaką posługujemy się obecnie.

Tu uwaga na boku: dziś też Scrum działa w takich warunkach świetnie. Szkoda, że coraz mniej jest Zespołów, które tworzą ludzie zmotywowani, zarządzani tak, by nie zabić w nich tego zaangażowania, do tego mający do zrobienia coś sensownego…

Wracając do Scrum Masterów: gdy już stało się jasne, że w Zespołach jest taka odpowiedzialność – czyli że ktoś musi zabiegać o stworzenie środowiska sprzyjającego skutecznemu dostarczaniu wartościowych rozwiązań i opiekować się (to dobre słowo) Scrumem – pojawiły się kłopoty.

Jakich kompetencji potrzebują Scrum Masterzy?

Stereotypy nie są czymś, co warto powielać, ale tak, jak w każdej plotce jest odrobina prawdy, tak stereotypy nie biorą się z powietrza. Nie da się ukryć, że Developerzy w czasach, gdy branżę IT zaludniali głównie miłośnicy komputerów, niekoniecznie mieli dobre przygotowanie do zajmowania się tematami takimi jak rozwiązywanie konfliktów, organizowanie produktywnej dyskusji itd.

Na szczęście ci pierwsi Scrum Masterzy wiedzieli, że muszą się tego jakoś nauczyć, choć wychodziło im to różnie. Oczywiście z pomocą ruszyły liczne firmy szkoleniowe i doradcy, dostarczając niezbędnej wiedzy i narzędzi. To skupienie kształcenia i rozwoju Scrum Masterów na tzw. kompetencjach miękkich miało wtedy sens, ale niestety nie zanikło z czasem, czego smutnym efektem jest przekonanie wielu ludzi i dziś, że Scrum Master powinien zajmować się wyłącznie coachingiem, a kompetencji technicznych mieć żadnych nie musi.

Prawdą jest jednak, że Scrum Master pracujący w Zespole zajmującym się technologią ma nikłe szanse, by być przydatnym dla tego Zespołu, jeśli brakować mu będzie przynajmniej podstawowej wiedzy o pracy Developerów. Może nawet nie być w stanie zauważyć, że są jakieś problemy, którymi należałoby się zająć, już nie mówiąc o skutecznym ich usunięciu.

Wśród pierwszych Scrum Masterów zjawisko takie nie występowało, bo – jak już pisałem – byli wszyscy lepszymi lub gorszymi Developerami, a nawet jeśli nie, do IT przygnało ich zainteresowanie technologią. Nie da się czymś interesować i nic o tym nie wiedzieć, nieprawdaż?

Przewijając kalendarz o kilkanaście lat do przodu, zobaczymy zupełnie inny obrazek: po firmach błąka się cała rzesza Scrum Masterów po różnych kursach coachingowych i facylitacyjnych, kompletnie nierozumiejących charakteru pracy Zespołów, z jakimi współpracują. Mamy też dziś branżę IT, w której bez trudu znajdziemy ludzi bez pojęcia o programowaniu, niezainteresowanych tą dziedziną, a jedynie „pracą w IT”. W tym Developerów… a może powinienem napisać „Developerów”. To jednak temat na osobny artykuł-rant.

W miarę jak rosła popularność Scruma, coraz wyraźniej widać było, że wiele Zespołów nie ma co liczyć na sensownych Scrum Masterów, jeśli chętni do wzięcia na siebie tej odpowiedzialności nie zainwestują w rozwój kompetencji niezbędnych, by sobie z tym poradzić.

„Ile kodu tworzy Scrum Master?”

I tu pojawił się kolejny problem. Developerzy chcący być Scrum Masterami potrzebowali czasu, by się rozwijać w tym zakresie, ale z punktu widzenia ich organizacji nie była to sensowna inwestycja. Im dalej było od tego pierwotnego środowiska ludzi zaangażowanych w robienie czegoś z sensem i szukających dobrego sposobu działania, tym trudniej było przekonać kierownictwo, by Scrum Masterzy w Zespołach byli w ogóle i żeby mieli prawo poświęcać czas na cokolwiek innego niż development.

Pojawiały się pytania o to, jaka jest wartość pracy Scrum Mastera, który przecież kodu nie pisze (bo jeśli to robi, to jako Developer, a nie Scrum Master). Standardem zaczęło być uznawanie odpowiedzialności Scrum Mastera za dodatek do bycia Developerem, z prawem przeznaczenia na to kilkunastu procent czasu pracy.

Ktoś może powiedzieć, że przecież w pierwszych Zespołach Scrum też tak było, wiec czemu nagle miałoby to stanowić problem? Cóż, te historyczne Zespoły, które odkryły istnienie odpowiedzialności Scrum Mastera, doceniały jej wartość i rozumiały świetnie, że nie da się z góry określić czasu, jaki będzie niezbędny na wywiązanie się z niej. Jednego dnia wystarczy kilka minut, innego dnia zrobi się z tego zajęcie na pełen etat. Inaczej mówiąc, przez ludzi w tych Zespołach odpowiedzialności Scrum Mastera i Developera były traktowane jako równie ważne.

Wiele lat później o tym, kto w Zespole będzie Scrum Masterem, coraz częściej decydowali już nie Developerzy (bo od nich oczekiwano skupienia w 100% na wytwarzaniu produktu, skoro „za to biorą pieniądze!”), tylko kierownicy. Dodajmy, że nierzadko przekonani, iż praca Scrum Mastera to marnowanie czasu Developerów, który mógłby spożytkowany być na prawdziwą robotę. Ciężko dziwić się, że Developerzy nie garnęli się do bycia Scrum Masterami, a jeśli już podejmowali się tego obowiązku, to traktowali go zwykle po macoszemu, ograniczając się do organizowania spotkań i obsługą narzędzi takich jak Jira.

To wszystko bardzo ograniczało możliwości działania tych Scrum Masterów, którzy traktowali serio swą odpowiedzialność. Musieli skupiać się na developmencie nawet wtedy, gdy akurat powinni przede wszystkim zadbać o proces lub usuwanie utrudnień blokujących Zespół. W ramach wsparcia w rozwoju najczęściej wysyłano takiego człowieka na jeden kurs, po którym miał przynieść certyfikat potwierdzający, że nauczył się wszystkiego i… tyle. Jeśli Scrum Master chciał się dalej rozwijać, to musiał to robić we własnym zakresie po pracy. Na szczęście wielu ludzi chciało, były też firmy, w których ta przestrzeń do rozwoju została zapewniona.

Konsekwencją takiego stanu spraw musiała być rosnąca niechęć Developerów do brania na siebie obowiązków Scrum Mastera. W samym IT, czyli świecie, w którym Scrum się narodził, działo się to równolegle z innym zjawiskiem: nasiąkania branży ludźmi, których przyciągały przede wszystkim pieniądze, a nie wytwarzanie oprogramowania. Coraz szybciej rosła liczba Zespołów, w których nikomu nie zależało na tym, jakim procesem się posługują – ważne, by była za to odpowiednia pensja.

Oczywiście nie zniknęli ludzie, którzy chcieli budować dobry software. Tyle że w zderzeniu z otaczającym ich powolnym obumieraniem zaangażowania i powolnej erozji standardów inżynierskich (to kolejny temat na artykuł-rant), ludzie ci zamykali się często w skorupie tematów technologicznych, bo one dawały im jakąś radość z pracy.

Pełnoetatowy Scrum Master

Aby pomóc tym, którzy chcieli w Scrumie działać z sensem, wielu propagatorów metody zaczęło promować ideę Scrum Mastera pracującego na pełny etat. Często bowiem lepiej było, aby pełnoetatowy Scrum Master, mający czas na samorozwój i zrobienie czegoś sensownego, zajmował się kilkoma Zespołami, niż by każdy z tych Zespołów miał Scrum Mastera, od którego oczekuje się przede wszystkim bycia Developerem.

Czy miało to sens? W wielu miejscach tak – przynajmniej przez jakiś czas. Pozwalało zbudować lepsze zrozumienie w organizacji, że ktoś taki jak Scrum Master, jeśli ma kompetencje i czas na działanie, przynosi sporo wartości. Przy czym, co ważne, cały czas spełniony był warunek, że wszyscy ci Scrum Masterzy mieli przynajmniej podstawową wiedzę o developmencie, jaki wykonują Zespoły, z którymi pracują. Inaczej mówiąc, że nie byli to ludzie wyłącznie od „robienia, by było miło”, ale mają zdolność zauważenia problemów również w obszarze pracy Developerów i doprowadzenia do tego, by zostały one rozwiązane.

Można powiedzieć, że operacja się udała, ale pacjent zmarł. Organizacje dały się w końcu przekonać, że Scrum Masterzy są potrzebni, bo tam, gdzie byli, Scrum działał lepiej. Efekt? Rosnące zapotrzebowanie na takich ludzi na rynku. A popyt generuje podaż, więc pojawiły się oferty typu „z nami dostaniesz robotę Scrum Mastera w IT”.

I ruszyli szeroką ławą do Zespołów, aby im pomagać, ludzie, którym często brakowało podstawowych kompetencji. Absolwenci np. religioznawstwa lub psychologii zabrali się za dbanie o efektywność Developerów budujących oprogramowanie – czy to mogło się udać? Czasem tak, gdy trafiło na utalentowanego człowieka gotowego do szybkiego nauczenia się, jak tworzony jest software. Częściej jednak nie, więc efekty były opłakane. A w ujęciu globalnym skutek jest następujący: dziś przez wielu Developerów Scrum Masterzy uważani są za oderwanych od rzeczywistości osobników marnujących ich czas i niemających wiele do zaoferowania. Przykre to, ale nie ma co obrażać się na rzeczywistość.

„Zrobimy wam Scruma!”

Na tym problemów nie dość. Popularność Scruma rosła, bo ta metoda naprawdę daje dobre efekty nawet w mało sprzyjającym środowisku. Póki jest tam minimum kompetencji i chęci do ich użycia, to zastosowanie empiryzmu, nawet w ułomny sposób, pozwala sobie radzić lepiej, niż bez niego.

Przybywało więc Zespołów, które pracowały w Scrumie. Niestety, gdzieś po drodze doszło do zmiany powodów, dla których ktokolwiek po tę metodę sięgał.  Najpierw, jak pisałem, była to autentyczna chęć zrobienia czegoś lepiej. Potem dołączyły do nich Zespoły, które wzorowały się na tych pierwszych – bo też im zależało, ale niekoniecznie chciały same wymyślać nowy sposób pracy. A że nadal dawało to świetne rezultaty, kolejne grupy ludzi sięgały po Scrum, licząc na to, że sporo na tym zyska. I zyskiwali, choć już niekoniecznie spektakularnie dużo.

Korzyści były jednak na tyle istotne, że Scrum zaczął być postrzegany przez management jako magiczna różdżka, która nędznej organizacji, zajmującej się mało wartościowymi rzeczami, pozwoli tych rzeczy zrobić więcej za te same pieniądze. Pojawiać się zaczęły Zespoły, którym ktoś kazał użyć Scruma w tej właśnie nadziei, mimo że nikt tego nie chciał, a często nawet nie rozumiał, o co chodzi w tej metodzie.

Ba, normą w wielu branżach stało się to, że już nie Zespoły sięgały po Scrum, ale przysyłano do nich obłożonego stosownymi certyfikatami coacha, aby „zrobił w Zespole Scrum”. I jak umiał, tak robił. Pseudo-Scrum czy Scrum-zombie, jakiego doświadczyć można w wielu miejscach, tak właśnie się rodził. Wtedy też wykluły się z plugawych skorup rozliczne mity i nieporozumienia, o które dziś co rusz potyka się każdy, kto zaczyna pracę w Scrumie i szuka wiedzy, jak użyć go dobrze.

Poza tym, skoro Scrum stał się popularny, obrodziło firmami doradczymi, szkoleniowymi, różnej maści ekspertami, którzy rzucili się „pomagać” w użyciu Scruma. Była niezła kasa do wyjęcia z rynku, grzech z niej nie skorzystać, prawda? Skutki takiego „pomagania” były opłakane, bo w interesie uprawiających ów mało etyczny proceder nie było wyjaśnianie, kiedy Scrum ma sens. Ci, którzy zajmowali się tą metodą od dawna, zepchnięci zostali w cień, bo byli „za mało elastyczni”, stawiali „za duże wymagania” Zespołom i organizacjom, „brakowało im pragmatyzmu” itd. Więc wzrost popularności Scruma stał się w pewnym momencie bańką opartą o pobożne życzenia.

Pufff!

Każdy balon ma określoną pojemność i pompowany nieustannie pęknie, flaczejąc malowniczo. A pompowanie bańki źle stosowanego Scruma szło w parze z pompowaniem gospodarki, w ramach którego firmy szaleńczo ścigały się w budowaniu rzeczy, których prawdopodobnie nikt nie potrzebował.

Wcześniej czy później musiało dojść do urealnienia stanu spraw – i doszło. Wydawało się, że czymś takim będzie pandemia z 2020, ale ona tylko nakręciła tempo pompowania balona w niektórych branżach. Kryzys gospodarczy jednak w końcu nadszedł i aktualnie jesteśmy na etapie flaczenia rozerwanego balonu, choć niektórzy próbują jakiś jego fragment na nowo nadmuchać (pozdrawiamy pasjonatów tzw. sztucznej inteligencji).

Co się dzieje, gdy następuje załamanie gospodarcze? Cięcie kosztów. Często bezmyślne i przynoszące więcej strat niż korzyści. A potem próba uporządkowania chaosu, jaki to spowodowało. I odbudowy tego, co w szale pokazywania inwestorom, że „uzdrawiamy firmę!” zostało okaleczone.

Na fali tych działań pojawiły się nieuchronne pytania o to, po co komu taki kulawy pseudo-Scrum, który nic nie daje. A jeśli nawet daje, to po co komu Scrum Masterzy? Co oni właściwie robią? Przecież np. taki Scrum Master w IT ani linijki kodu zapewne nie napisze, więc po cóż nam on?

Zatoczyliśmy w ten sposób koło, ale chętnych do wyciągnięcia wniosków widać niewielu. Za to dużo pisze się o „śmierci Agile” i „śmierci Scruma” (oba mają się świetnie, bo nie widać nic, co mogłoby zastąpić empiryzm w radzeniu sobie z niestabilną złożonością). Niektórzy (ci od tzw. AI) wieszczą, że za chwilę i tak w ogóle ani Developerów, ani Zespołów nie będzie potrzeba. Ciekawe tylko, kto kupi te wszystkie wspaniałe produkty, które wedle tej wizji będą powstawać w ogromnych ilościach z prędkością światła niemal za darmo, kiedy już ludzie stracą robotę i nie będzie ich stać na zaspokojenie podstawowych potrzeb… Cóż, zobaczymy, kiedy ten kolejny balon strzeli. Wróćmy do Scruma.

„Dobre rady”

Znaleźliśmy się zatem w punkcie wyjścia, jakim jest przekonanie licznych firm, że Scrum Masterzy są zbędni, bo nie przynoszą żadnej wartości. Pewnie w wielu przypadkach faktycznie tak jest, ale – uwaga! – to nie znaczy, że wszyscy Scrum Masterzy wszędzie są bezwartościowi. To ci konkretni ludzie w tych konkretnych firmach tacy się okazali, a co ciekawsze, nierzadko byli oni zatrudniani przez dokładnie tych samych managerów, którzy teraz oceniają negatywnie skutki tej swojej decyzji.

Pojawiły się oczywiście podpowiedzi dla firm i samych Scrum Masterów, co zrobić. Firmom doradza się, by porzucić Scruma i sięgnąć po cokolwiek, co akurat doradzający mają do zaoferowania. A Scrum Masterzy słyszą: zabierzcie się za development, żeby wykazać swoją wartość, w przeciwnym razie wylecicie z roboty.

I to ostatnie wydaje mi się szczególnie przewrotne. Bo jest w istocie przyznaniem się do braku wiary, że Scrum Master jest wartościowy, skoro jedynym sposobem na wykazanie, że opłaca się go zatrudniać, ma być zajęcie się czymś, co nie jest pracą Scrum Mastera.

Przy czym zdarzyło mi się natrafić na sugestie, że development to część pracy Scrum Mastera, co jest kompletnym nieporozumieniem. Jeśli Scrum Master zabiera się za development, robi to już nie jako Scrum Master, ale jako Developer. Zacierając granicę między tymi dwoma uzupełniającymi się odpowiedzialnościami, cofamy się do samych początków Scruma, kiedy Scrum Masterów nie było w ogóle.

Ile zatem wart jest Scrum Master?

Tyle, ile warte są Zespoły, jakie pomoże organizacji zbudować. Tak po prostu. Jeśli skupi się na facylitowaniu spotkań i okazjonalnym coachingu, to prawdopodobnie wart jest niewiele. Jeśli potrafi doprowadzić do zmiany (poprawy) środowiska, w jakim funkcjonują Zespoły, jeśli potrafi wykrzesać w ludziach intencję poprawnego użycia Scruma poprzez uświadomienie im korzyści, jakie to daje – jest wart bardzo dużo. I nie ma przy tym znaczenia, czy będzie jednocześnie Developerem. Natomiast w mojej ocenie ma kluczowe znaczenie, czy rozumie pracę Developerów, jakim ma pomagać – bo bez tego… cóż, niewiele zdziała.

Jeśli natomiast Scrum Master właśnie drży o to, czy nie zwolnią go z pracy, bo firma ostrzy kosę na Scrum Masterów jako „darmozjadów”, ja nie będę mu sugerował, by zabierał się za development tylko po to, żeby przetrwać. Mam za to trzy inne rady.

Pierwsza: jeśli wierzysz w sens tego, co robisz i masz przekonanie, że to ma wymierną wartość, uświadom ją decydentom. Jeśli nie potrafisz, to może faktycznie nie nadajesz się do tej roboty? O ile to, co robisz, jest rzeczywiście wartościowe, a nie wynika z zawyżonej samooceny własnych działań. Jeśli w istocie są cenne, bron tego, co robisz i sposobu, w jaki działasz. Być może mimo to organizacja zdecyduje się zakończyć współpracę – wtedy z wyjątkiem krytycznych sytuacji, gdy nie możesz sobie pozwolić sobie na utratę zatrudnienia na jakiś czas, lepiej odejść niż tkwić w toksycznym miejscu.

Druga rada: jeśli uczciwa samoocena działalności jako Scrum Mastera kończy się przekonaniem, że to nie jest robota dla ciebie, poszukaj takiej, w której się sprawdzisz. Być może będzie to właśnie development. Przy czym wtedy podjęcie się obowiązków Developera wynikać nie będzie z próby ocalenia zatrudnienia jako pseudo-Scrum Master, tylko z racjonalnej oceny własnych zdolności.

Rada trzecia: o twojej wartości Scrum Mastera nie świadczy to, czy pracujesz na pełen etat, czy jesteś jednocześnie Developerem. Jeśli potrafisz, łącz te odpowiedzialności, ale upewnij się, że kiedy będzie taka potrzeba, możesz i 100% czasu poświęcić na bycie Scrum Masterem. Pamiętaj też, by w sytuacji konieczności wyboru, gdy wydaje się, że musisz zrobić coś zarówno jako Developer, jak i jako Scrum Master, zawsze wybrać to drugie – bo tylko ty jesteś Scrum Masterem i abdykując z tej odpowiedzialności, spowodujesz jej całkowitą atrofię w Zespole. Piszę o tym, bo pokusa, by zająć się przede wszystkim developmentem, będzie silna – Developerów chwalą za zbawianie świata, Scrum Masterów jedynie z rzadka, o ile w ogóle…

A jeśli ktoś chce się dowiedzieć, co powinien robić Scrum Master i jak z sensem używać Scruma, zapraszam na szkolenia. Nie zamierzam wycofywać się z propagowania tej metody, nawet jeśli chwilowo sporo osób wiesza na niej psy i wieszczy jej koniec. Pragmatycy, a za takiego się uważam (mam nadzieje, że słusznie) ani nie sięgają po różne narzędzia pod wpływem mody, ani nie porzucają ich bezrefleksyjnie – po prostu używają ich zgodnie z przeznaczeniem, dzięki czemu one działają.