Pomysł na niniejszy artykuł pojawił się po raz pierwszy podczas przeglądu doskonałego artykułu Macieja „Skifa z coachingiem”. Nasza dyskusja, z wykorzystaniem google docs, dotyczyła następującego fragmentu:
W mediach społecznościowych można regularnie natknąć się na dyskusje praktyków zwinności, w których spierają się, czy scrum master powinien być, jak to się mówi, techniczny. Pomijając tę niezręczność, że techniczny to może być Terminator, a nie organizm żywy złożony w siedemdziesięciu procentach z wody, to znajomość chociażby cyklu wytwarzania oprogramowania wydaje mi się w pracy scrum mastera o wiele ważniejsza od znajomości klasycznego coachingu.
Przyznałem się wtedy, że ja czuję się takim scrum masterem… technicznym. A może poprawniej jest napisać… „technicznym”? A może jedno i drugie stwierdzenie jest… złe, niedobre, niepoprawne? Zaczęło mnie to nurtować i stąd powstał niniejszy artykuł.
Swoje poszukiwania rozpocząłem od przeglądarki google i hasła „techniczny scrum master”. Wiadomo przecież, że jak czegoś nie ma u wujka google’a, to nie istnieje. Jest pierwszy fakt – scrum master techniczny (pisany bez cudzysłowów i z nimi) istnieje, przynajmniej w sieci. Często też mówi się o „techniczności” scrum mastera, a w zasadzie o tym, że żeby być dobrym scrum masterem, nie trzeba być „technicznym” (będę dalej korzystał z cudzysłowów, które ja lubię nazywać „ciapkami”, zatem „techniczny” będzie dalej w „ciapkach”). Zgadzam się z powyższym stwierdzeniem w całej rozciągłości, znam bardzo dużo doskonałych agile coachów i scrum masterów, którzy nie odebrali technicznego wykształcenia, a bardzo dobrze robią swoją robotę. Zauważam jednak taką prawidłowość, że owi „nietechniczni” scrum masterzy prędzej czy później dążą do tego, żeby słabiej lub mocniej „spróbować” technikaliów. Dlaczego? Bo w końcu okazuje się, że te kompetencje są im potrzebne w pracy, po prostu niektóre zespoły tego oczekują. Dzieje się nawet tak, że osoby bez technicznego tzw. background-u stają się z czasem wręcz doskonałymi… „technicznymi” scrum masterami.
Wiadomo nie od dziś, że najlepiej żegluje się po wodach, które się najlepiej zna. Dlatego „psychologiczni” scrum masterzy, może poprawniej byłoby napisać: scrum masterzy z mocnymi kompetencjami w obszarze psychologii, będą mocno wykorzystywać ten atut, a ci „techniczni” wykorzystają swój techniczny potencjał. Przy kolejnych zespołach stosuję pewien „patent”, który się całkiem dobrze sprawdza. Nawet jest tak, że im zespół jest bardziej sceptyczny wobec koncepcji zwinności jako takiej, to sprawdza się on nawet lepiej. Przypatruję się zespołowi i tam, gdzie dostrzegam swoją szansę jako „techniczny”, wchodzę w tę lukę i zaspokajam tą potrzebę zespołu. To może być konkretna pomoc przy jira, conflunence, procesie wytwarzania oprogramowania lub automatyzacji testów. Jest to zawsze doskonały punkt zaczepienia, szczególnie w zespole, nazwijmy to, sceptycznym. Poza tym pamiętajmy, że dla osób technicznych (programistów, testerów) szacunek wzbudza druga osoba… techniczna (tak mają DISC-wi niebiescy – czy nam się to podoba, czy nie – piszę o tym tutaj). Nie chcę bynajmniej powiedzieć, że jest to jedyna i najlepsza droga. Przeciwnie, jeżeli ktoś czuje się mocny w innym obszarze np. coachingowym i ma swój wypracowany sposób na dotarcie do zespołu tą drogą, to super. Każdy kto posiada “kompetencyjny potencjał” w danym obszarze, niech z niego korzysta pełnymi garściami. Chcę tylko podzielić się swoim doświadczeniem – w moim przypadku takie podejście w zdecydowanej większości przypadków się sprawdza. Po takim wsparciu technicznym (tu bez „ciapek”) np. w jirze, jestem już prawie „swój chłop”, który może i dziwne rzeczy mówi o jakichś wartościach z Agile Manifesto i czasami biega z karteczkami, ale na czymś się jednak zna.
Trudno pisać artykuł w tych czasach i nie nawiązać do obecnej sytuacji, a jest ona dynamiczna nieprawdopodobnie. Kolejnych pozycji o narzędziach zdalnych nikt już nie chce czytać, powstało tego tyle, że chyba się „przejadło”. Co więcej, jak sobie pomyślę, że jeszcze niedawno myślałem o tym, żeby przygotować sobie (i innym) spis lektur do przeczytania, bo czasu będzie przecież więcej, to chce mi się siebie… „kopnąć” w to coś, żeby bolało. Na szczęście nie jestem aż tak bardzo elastyczny, żeby to wykonać :). Dla jasności, nie uważam, że sam pomysł ze spisem lektur jest zły z gruntu. Dobry jest zapewne dla wielu, ale na mnie “nie działa”. Po ponad miesiącu “odsiadki” w domu czasu wolnego wcale nie mam więcej, a wręcz czuję, że jest go nawet… mniej. Mam także nieodparte przeświadczenie, że Świat na nowo słucha bardziej uważnie ludzi kompetentnych. Politycy, nawet najwięksi bigoci tego Świata, oddają pole lekarzom, wirusologom, generalnie naukowcom. Antyoświeceniowe podejście forsowane mocno przez populistów przyczaiło się w koncie i czeka na swoje kolejne 5 minut. Nie mam jednak wątpliwości, że ta hydra podniesie jeszcze głowę. Początki tego procesu obserwujemy już teraz pomimo tego, że po ogólnym przerażeniu na pierwszy plan wysunęła się nauka i konkretna wiedza. Natomiast ci, którzy otwarcie buntowali się przeciw wiedzy (np. antyszczepionkowcy, gdzie jesteście?) siedzą szczęśliwie cicho. Okazuje się nagle, że Świat nie oczekuje już nowego modelu myśliwca, tylko wszyscy czekają na… szczepionkę.
OK – tylko co ten pseudofilozoficzny wywód ma wspólnego z dzisiejszym tematem? Ano w moim odczuciu ma sporo. Drodzy moi, żeby była jasność, w żaden sposób nie uważam, że te czy inne kompetencje w pracy scrum mastera są ważniejsze, a inne mniej ważne. Sam wykorzystuję te techniczne, bo w nich dobrze się czuję. Chylę jednak czoła przed tymi z nas, którzy wykorzystują te umiejetności, w których czują się najlepiej, coachingowych czy innych. Moim zdaniem jest tak, że praca zdalna pewne kwestie hiperobolizuje i mocno stymuluje nasze kompetencje. Tak uważam po ponad miesiącu pracy zdalnej. Jest trudniej przygotować dobrą retrospektywę, planownie, podsumowie sprintu czy product show. Ktoś może powiedzieć: “też mi coś – zespoły zdalne rozsiane po całym Świecie to teraz norma.” Dla niektórych pewnie tak jest, ale dla mnie, i myślę, że wielu z Nas, to nowe, ciekawe, ale jednak trudne, doświadczenie. A do tego trzeba uważać, żeby pracując w domu… nie oszaleć (co dobrze opisał w swoim artykule Robert tutaj).
A co z konceptem “technicznego” scrum mastera? Jest taki, czy go jednak nie ma? Czy to tylko opis kompetencji? Tak bym do tego podszedł i na tym temat zakończył, a czy leksylanie to sformułownie jest poprawne, tego to ja już nie wiem – przecież jestem tylko prostym, “technicznym” scrum masterem :).
Już na koniec mam prośbę – sam podzieliłem się pewnym swoim “technicznym patentem”, który wykorzystuję na początku współpracy z nowym zespołem. Z przyjemnością przeczytałbym o Waszych “patentach” w komentarzach do niniejszego artykułu. Jestem przekonany, że dysponujecie wachlarzem takich “patentów” – podzielcie się nimi proszę :).