Czy Scrum Master musi być techniczny?

Odpowiem krótko: NIE. Scrum Master, żeby dobrze wykonywać swoją pracę, wcale nie musi być osobą techniczną. Co więcej, sam Scrum, nigdzie nie formułuje takiego założenia.

„Techniczność” osoby Scrum Mastera to jest mit, który pokutuje w naszych firmach od początków istnienia Scruma. Wzięło się to po części stąd, że po pierwsze – jest to metoda, która jakby nie było, wywodzi się z branży informatycznej. I, dla wielu firm IT, zatrudnianie roli, która nie mieściłaby się w standardowym słowniku ról projektowych, jest po prostu trudne do ogarnięcia.

I dlatego, po drugie – firmy które decydują się na wdrożenie Scruma, bardzo często łączą rolę Scrum Mastera z inną, już istniejącą rolą w firmie. Takie podejście ma też, w wielu wypadkach – uzasadnienie kosztowe. Do dzisiaj, słyszę od menedżerów argumenty – „po co zatrudniać do pracy osobę nietechniczną, skoro tego co robi nie da się zmierzyć?”.

To, prawda. Wiedzę techniczną dużo łatwiej jest zweryfikować. Natomiast, żeby sprawdzić, czy ktoś dobrze się komunikuje z zespołem, ma odpowiednie umiejętności interpersonalne i społeczne, potrafi się wykazać inteligencją emocjonalną – na to wszystko potrzeba czasu.

Z drugiej strony jest też tak, że umiejętności „miękkie” jest dużo trudniej opanować, niż na przykład nauczyć się programowania. Bo bardzo często wymagają od nas długiej i żmudnej pracy nad sobą – nad naszym ego, nad naszą mentalnością, sposobem rozumienia świata, emocjami. To wszystko jest bardzo trudne do osiągnięcia i zmierzenia.

Warto też dodać, że sama nazwa – „umiejętności miękkie” (ang. soft skills) – jest nieszczególna. Co to w ogóle znaczy „umiejętności miękkie”? Niestety dla wielu firm wciąż są to kompetencje, które jak najbardziej warto mieć, ale wcale nie są one kluczowe.

Podobnie jest z rolą Scrum Mastera. W naszym rozumieniu tej roli, ciągle pokutuje przekonanie, że powinny to być osoby przede wszystkim techniczne, które dodatkowo potrafią dobrze się komunikować i pracować z zespołem. Wiele firm, tak do tego podchodzi. Kompetencje miękkie traktuje trochę jak dodatek, który może być, ale nie musi.

A tymczasem, w przypadku roli Scrum Mastera, to „umiejętności miękkie” właśnie są kluczowe. Nie znajomość programowania obiektowego się liczy, ale umiejętność efektywnej komunikacji. Nie znajomość produktu się liczy, ale umiejętność współpracy z zespołem. Nie znajomość tej czy innej technologii się liczy, ale umiejętność zadawania dobrych pytań.

Tymczasem, w całkiem sporej liczbie firmie – Scrum Master jest jednocześnie programistą, testerem lub inną osobą, z tzw. „zapleczem inżynieryjnym”, która pracuje w zespole deweloperskim.

Oczywiście nie twierdzę, że taki mariaż ról jest z gruntu zły. I jestem bardzo daleki od takiego stwierdzenia. Naprawdę znam wielu Scrum Masterów, którzy mają takie zaplecze i świetnie sobie radzą w pracy z zespołem. W dużej mierze jest to na pewno kwestia pewnych indywidualnych predyspozycji, które się ma lub które trzeba w sobie wykształcić.

Niemniej, w dzisiejszym wpisie, chciałbym jasno powiedzieć:

Scrum Master nie musi być osobą techniczną

Są 3 argumenty, z którymi najczęściej się spotykam, jak poruszam temat „techniczności” roli Scrum Mastera:

Argument 1: „Bo techniczny Scrum Master będzie lepiej rozumiał problemy zespołu”.

Czy faktycznie osoba, która umie programować, zna różne frameworki, wzorce projektowe, zna dobrze rozwijane aplikacje – będzie lepiej rozumiała zespół, niż osoba, która tych zdolności nie ma? Czy Scrum Master faktycznie jest potrzebny w zespole po to, żeby rozwiązywać jego techniczne problemy?

Znam mnóstwo sytuacji, że ta „techniczność” Scrum Mastera była, co najwyżej, dodatkową przeszkodą, z którą zespół musiał sobie poradzić w sprincie. Przeszkodą, która miała bardzo negatywny wpływ na jego autonomię i samoorganizację.

Jeżeli komuś brakuje empatii, nie umie się komunikować, nie umie słuchać – to wiedza techniczna, która niby ma być tym „ułatwiaczem” nijak tego nie zmieni.

Kiedyś miałem w swoim życiu tzw. „fazę na Weinberga” 🙂 Do dzisiaj na swoich szkoleniach ze Scruma, polecam wszystkim uczestnikom jedną z jego kultowych książek The Psychology of Computer Programming. Ale Gerald M. Weinberg – psycholog i antropolog programowania – napisał też książkę, która mówi o tym, jak być dobrym konsultantem. Sformułował w niej trzy słynne prawa konsultingu, o których zawsze staram się pamiętać, jak jadę do klienta 🙂 Dzisiaj skupię się tylko na drugim, bo ma największy związek z naszym tematem:

No matter how it looks at first, it’s always a people problem.

Nie ma znaczenia, czy problem jest techniczny czy nie. Źródłem problemu jest zawsze człowiek. Ludzie tworzą problemy i ludzie je rozwiązuję. Nawet jeżeli jakiś problem jest stricte techniczny, to i tak, koniec końców, jest w nim zaszyty czynnik ludzki. I to właśnie na nim Scrum Master powinien skupić całą swoją uwagę, i nad nim pracować z zespołem.

Żeby to zrobić, wcale nie musi być osobą techniczną. Wręcz przeciwnie, „techniczność” może mu w tym tylko przeszkadzać. Bo „techniczny” Scrum Master zawsze będzie miał pokusę „powymądrzania się” i „posterowania” zespołem. Co oczywiście wcale nie musi oznaczać, że robi to w złej wierze. Czasem chce naprawdę pomóc, ale skutek jest zupełnie odwrotny.

Jak pracuję z początkującymi Scrum Masterami, to zawsze wbijam im do głowy – „waszym celem jest być jak najmniej potrzebnym zespołowi”. Bo to oznacza, że zespół będzie w końcu miał szansę sam zarządzać swoją pracą. Zacznie być samosterowny. Inaczej, rola Scrum Master sprowadzi się do bycia taką „Scrum-Mamą”, która przytuli w potrzebie i cały czas będzie trzymać swoje pociechy za rękę. Nie o to w tym chodzi.

Argument 2: „Bo techniczny Scrum Master ma większy autorytet w zespole”

Zgoda, jeżeli uznanie, jakim zespół go obdarza wynika tylko i wyłącznie z doświadczenia technicznego. Ale to tylko oznacza, że Wasz zespół nie do końca rozumie, o co chodzi w tej roli.

Jeżeli autorytet, czyli uznanie jakim zespół obdarza swojego Scrum Mastera, bierze się tylko i wyłącznie z doświadczenia technicznego danej osoby – to znaczy, że ten Scrum Master nie robi tego, co należy do jego obowiązków.

Znam wielu świetnych Scrum Masterów, których autorytet wcale nie wynika z tego, że mają jakąś super wiedzę techniczną. Wręcz przeciwnie, najczęściej są to osoby, które tej wiedzy nie posiadają. I, wcale to nie oznacza, że zespół je lekceważy, pomija w dyskusjach, czy unika rozmów na „trudniejsze” tematy. Nic z tych rzecz nie ma miejsca.

Bo autorytet roli Scrum Mastera wynika z czegoś zupełnie innego. To jest autorytet lidera, który cały czas „jest na służbie” – zespołowi. To jest zupełnie inny model przywództwa, niż ten, z którym mieliśmy do czynienia dotychczas. Scrum Master to „przywódca poziomu 5”.

Scrum Master to „przwódca poziomu 5.

Termin „poziom 5”, po raz pierwszy wprowadził do obiegu Jim Collins, który razem ze swoim zespołem badał różnice między wielkimi i zupełnie przeciętnymi przedsiębiorstwami. Otóż, po przebadaniu setek firm, każda z nich, która przeszła taką transformację, miała na swoim pokładzie przywódców poziomu 5.

Poziom 5. to nic innego, jak najwyższy poziom w hierarchii kompetencji menedżerskich (wiem, że w przypadku Scrum Mastera używanie słowa „menedżer” jest trochę nie na miejscu, ale Collins nadała mu trochę inne znaczenie).

Scrum Master, który jest liderem 5. poziomu:

Ma w sobie mieszankę osobistej skromności i siły, która wynika z jego wnętrza (wartości)
Jest ambitny, ale cały swój wysiłek kieruje na rozwój zespołu, a nie na osiągnięcie swoich własnych korzyści
Jest skromny (ci którzy mieli okazję ze mną pracować, wiedzą, że przywiązuję do tego ogromną wagę), za wszelką cenę stoi w cieniu zespołu
Zrobi wszystko, żeby tylko zespół się rozwijał i dojrzewał
Jest pracowity, ciągle się rozwija

Co ciekawe, zawsze jak mówię Scrum Masterom, że są właśnie takimi liderami, to bardzo często słyszę od nich: – „Hahaha… Ja, lider? Daj spokój” 🙂

I to jest coś, co najlepiej oddaje prawdziwych Scrum Masterów. Oni nigdy nie uważają siebie za takich liderów. Są skromni i zawsze kierują rozmowę na zespół.

Tak więc, autorytet takich Scrum Masterów wynika z posiadania przez nich określonych cech przywódczych. Co, ciekawe charyzma nie ma tutaj aż takiego znaczenia. Jak odkrył to Jim Collins – przywódcy poziomu 5. osiągają często długoterminowe rezultaty mimo charyzmy, a nie dzięki niej.

Argument 3: „Bo techniczny Scrum Master czuje się bardziej komfortowo w zespole”.

Jeżeli jakikolwiek Scrum Master czuje się komfortowo w zespole, to znaczy, że powinien dać sobie spokój i zająć się czymś innym. Bo jeżeli Scrum Master dobrze wykonuje swoją pracę, to coś takiego jak „komfort” w pracy z zespołem nie istnieje.

Dobry Scrum Master cały czas narusza strefę komfortu – swoją i zespołu. Bo wtedy tak naprawdę, jedna i druga strona się rozwija.

Czy pracodawcy szukają „technicznych” Scrum Masterów?

Do niedawna, na pewno tak było. Pracodawcy sami wygenerowali potrzebę zatrudniania „technicznych” Scrum Masterów. Tak jak już wspominałem na początku, menedżerom trochę nie mieściło się w głowach, że w firmie może pracować ktoś, kto nie umie wykonywać zadań technicznych. Ktoś, kogo praca jest bardzo niemierzalna.

Teraz, na szczęście, to się bardzo zmienia. W trakcie pisania tego artykułu, odwiedziłem kilka portali, gdzie pracodawcy umieszczają swoje ogłoszenia o pracę, i jeśli chodzi o rolę Scrum Mastera, to większość z nich, nigdzie nie zawierała wzmianki o wymogu „techniczności” tej roli.

Zamiast tego natomiast, pojawiały się takie wymagania jak:

Umiejętność nawiązywania i budowania trwałych relacji interpersonalnych
Umiejętności komunikacyjne i interpersonalne
Znajomość metody Scrum (mile widziany certyfikat)
Wspieranie Zespołu i Product Ownera
Krzewienie wiedzy scrumowej w firmie
Rozwijanie zespołów w kierunku samodzielności
Usuwanie przeszkód występujących w codziennej pracy zespołu
Budowanie społeczności scrumowej w firmie

To jest bardzo dobry znak. Bo to oznacza, że świadomość w zakresie rozumienia tej roli się zmienia. Także w zakresie samego Scruma.

Ale w ślad za tym, idzie dużo głębsza zmiana. Tutaj nie chodzi o zmianę rozumienia roli Scrum Mastera, czy znajomość Scruma. Za tym kryje się głębsza zmiana całego paradygmatu zarządzania. Zauważcie, że obecnie, na rynku pracy, kompetencje miękkie u pracowników, zaczynają odgrywać coraz większą rolę. To, w dużej mierze wynika z faktu, że przed współczesnymi liderami i menedżerami stoją zupełnie inne wyzwania. W naszych firmach pojawiło się nowe pokolenie pracowników, którzy wymagają innego podejścia. Zmienia się podejście do motywowania pracowników, ludzie mają większą samoświadomość, chcą się rozwijać.

Narzędzia i praktyki, które były skuteczne jeszcze 10 lat temu, dzisiaj już przestały się sprawdzać. Poświęciłem temu tematowi cały odcinek podcastu Zarządzanie znalazło się w kryzysie… Co dalej? Jeżeli macie czas, to zachęcam do posłuchania.

Na koniec, chciałem Was zaprosić do przeczytania czegoś naprawdę wyjątkowego. Ewa Wiktorowska, która bierze udział w moim kursie internetowym „Scrum Assistance”, zgodziła się przygotować krótkie case study, które opisuje jej doświadczenia w pracy Scrum Mastera.

Ewa pracuje w tej roli zaledwie od roku. Wcześniej robiła coś zupełnie innego. Posłuchajcie jej historii.

Ewa Wiktorowska – Scrum Master [Case Study]

Cześć! Jestem Ewa. Mieszkam w Poznaniu i pracuję jako Scrum Master zaledwie od roku – wcześniej byłam lektorką języka francuskiego. Mam wykształcenie filologiczne i artystyczne. Po godzinach piszę jeszcze doktorat z literatury.

Pracuję w firmie IT tworzącej rozwiązania dla klienta wewnętrznego, i jest to moje pierwsze miejsce pracy na tym stanowisku. Jestem tu jedynym Scrum Masterem. Pracuję z dwoma, w porywach z trzema, zespołami.

Cieszę się, że miałam szansę się przebranżowić i znaleźć w tej ciekawej dla mnie roli. Świat zarządzania zwinnego, nie tylko Scruma, ale zarządzania w ogóle, bardzo mnie zainteresował i chcę się w tym obszarze dalej rozwijać.

Brak technicznego doświadczenia był moim mentalnym blokerem

Nie ukrywam, że brak technicznego doświadczenia był na początku moim wielkim mentalnym blokerem. I chyba bardziej przeszkadzał mnie samej, niż moim zespołom.

Przez pierwsze tygodnie głowa bolała mnie od wysiłku, który wynikał z próby zrozumienia technicznego żargonu, który zewsząd mnie otaczał – te wszystkie „dokery”, „merdże”, „rylisy”, „brancze”, „rabity”, „debagery” 🙂 Ale w końcu się oswoiłam, nauczyłam nowego słownictwa i opanowałam do perfekcji wyłapywanie z otoczenia tego, co ewidentnie jest dla mnie niezbędne. Resztą nie zaprzątałam sobie głowy.

Plusy mojej „nietechniczności”

Po pewnym czasie zaczęłam zauważać wiele plusów mojej „nietechniczności”. Poniżej zrobiłam krótką listę tych, które są dla mnie najważniejsze:

„Głupie pytania”. Jako Scrum Master „nietechniczny” – mogę je spokojnie zadawać. Pod pozorem mojej niewiedzy, prowokuję do zapauzowania dyskusji i podsumowania jej w kilku prostych słowach przez któregoś z uczestników. To, pomaga nam upewnić się, że wszyscy są „on the same page”. Co ciekawe, bardzo często okazuje się, że wiele osób zupełnie inaczej rozumiało to, co ktoś próbował mi wytłumaczyć. Myślę, że jako osobie nietechnicznej, jest mi po prostu łatwiej zadawać takie pozornie banalne pytania. Osoby, które mają wiedzę techniczną bardzo często wstydzą się zapytać. Tymczasem, zadawanie „banalnych” pytań bardzo strukturyzuje spotkania i wyrównuje wiedzę w zespole (podsumowanie danego etapu dyskusji).
„Łatwiej pozostać na meta-poziomie”. Nie angażuję się w samą treść dyskusji, więc łatwiej jest mi zaobserwować jej przebieg. To, czy ktoś dominuje lub jest „cichą myszką”, czy zbacza z tematu, czy nie odpowiada na pytania. Myślę, że łatwiej jest mi obserwować dynamikę grupy i przebieg dyskusji.
Łatwiej wspierać samoorganizację zespołu. Bo nie korci mnie, żeby mieć na wszystko gotową odpowiedź i sterować zespołem, wyręczając go z samodzielnego stawiania czoła problemom. Co nie znaczy oczywiście, że techniczny SM z definicji tak robi.
Siłą rzeczy skupiam się na miękkich aspektach procesu i zespołu. I pewnie będzie to moja specjalizacja: dynamika grupy, emocje zespołu, komunikacja, zaufanie. Ale znowu, to nie znaczy, że techniczny SM ma z tym problem.

Z czym jest mi trudniej?

Jest też kilka rzeczy, z którymi mnie jako osobie nietechnicznej jest trudniej:

Proponować i omawiać zwinne techniki programowania. Git flow, CI, automatyzacja testów – to dla mnie pojęcia znane tylko z teorii.
Moderować techniczne dyskusje, bo nie zawsze wiem, gdzie kończy się „na temat”, a zaczyna dygresja lub rozszerzanie tematu poza potrzebne aktualnie ramy.
Zrozumieć powagę pewnych problemów zespołu.
Zdobyć autorytet i pozycję wśród „scrumowych sceptyków”.

Wcześniejsze, nietypowe doświadczenie w wielu sytuacjach pomaga, bardzo mi pomaga. Nie jest dla mnie problemem występowanie przed grupą, prowadzenie spotkań, zapamiętywanie wątków w dyskusji i wracanie do nich, pilnowanie czasu, proponowanie różnych aktywności.

Nie czuję się skrępowana lub nie na miejscu podczas rozmów „jeden na jeden” i bardzo łatwo akceptuję różne typy osobowościowe, dostosowując się do ich stylu komunikacji i różnych kognitywnych potrzeb.

Jako ex-nauczyciel, staram się wprowadzać różne elementy Scruma stopniowo. Zależy mi na tym, żeby ludzie rozumieli sens i wartość wynikającą z różnych praktyk i bronię się jak mogę przed dogmatyzmem – „bo Scrum guide uczy nas, że tak trzeba”.

Staram się znajdować różne angażujące aktywności zamiast robić ludziom wykłady ze „scrumowych mądrości”. Jakaś wrażliwość na ton głosu, dobór słów, gesty, to chyba też zostało.

Jakie jest oficjalne stanowisko community?

Zauważyłam, że istnieje pewien typ programistów, którzy bardzo oczekują jasnego określenia jaki powinien być SM, techniczny czy nie. Chcą koniecznie wiedzieć, co na ten temat mówi „Scrum Guide”, i jakie jest oficjalne stanowisko community 😉 Często o tym z nimi rozmawiam i zdania są bardzo podzielone. Póki co, większości nie przeszkadza mój brak technicznego backgroundu, ale widzą postępy i chętnie dzielą się swoją wiedzą. Jednocześnie doceniają komunikatywność, organizację, umiejętność szybkiego załatwiania różnych spraw i prowadzenia spotkań.

To krótko o tym, jak w ogóle trafiłam tu gdzie jestem. Jako lektorka francuskiego prowadziłam m.in. kursy języka biznesowego w firmach, w tym w dwóch firmach IT, gdzie na zajęciach grupowych i indywidualnych miałam programistów, informatyków, PO, PM, QA…

Lubię prowadzić zajęcia w formie konwersacji i rozmawiać o tematach bliskich moim kursantom. Podczas tych zajęć duuużo dowiedziałam się o realiach i charakterze ich pracy, spotkaniach, problemach, tłumaczyli mi różne pojęcia itd. A jak czegoś nie rozumiałam albo szukałam ciekawych tematów do burzliwych konwersacji, z pomocą przychodził mi mój mąż, też programista, podsuwając hasła typu „wyższość .NET nad PHP-em” 😉

Kiedy zaczęłam myśleć o zmianie pracy na etatową, w pewnej firmie akurat zwalniało się stanowisko Scrum Mastera. Jeden z moich kursantów stwierdził, że może powinnam spróbować, bo według niego sprawdziłabym się w tej roli.

Trochę się pośmiałam, pomarudziłam, że przecież nie jestem techniczna i nie mam doświadczenia. A potem stwierdziłam, że przecież nie szkodzi spróbować. Pouczyłam się i dostałam swoją szansę.

Uczyłam się czytając oczywiście Scrum Guide, ale też wszystko co wpadło mi w ręce. Robiłam sobie testy na egzamin Professional Scrum Master 1, dopytywałam znajomych programistów z różnych firm, jak to u nich wygląda. Przegadywałam różne case’y, gdzie mogłam i próbowałam uchwycić całą filozofię, która za tym stoi tak, żeby móc nieznane mi sytuacje rozpatrywać zgodnie z agilowym mindsetem.

No i od początku miałam do tego spore przekonanie. Taka praca wydawała mi się wielkim wyzwaniem i mega ciekawym oraz rozwijającym obszarem. Ale prawdą jest też, że miałam po prostu dużo szczęścia. Znalazłam się w odpowiednim miejscu i czasie 😉

Jakie były moje największe wyzwania?

Wyzwania początkującej Scrum Masterki bez technicznego backgroundu:

Wiedza o specyfice pracy programisty. To wyzwanie, nie do końca wiąże się z brakiem doświadczenia technicznego. Myślę, że jest to wyzwanie każdego Scrum Mastera, który dopiero zaczyna. Po prostu, trzeba wykonać dodatkową pracę, związaną z wchłonięciem pewnej wiedzy na początku.
Pokonanie niepewności, kompleksów z racji braku doświadczenia i wiedzy technicznej. To taka prywatna praca nad sobą i przekuwanie słabości w atuty.
Brak pewności w proponowaniu rozwiązań. Brak argumentów w dyskusji, strach, że powiem coś głupiego.
Próba zaradzenia wszystkim bolączkom sama. Chęć bycia lubianą, przez wszystkich, bycia przydatną – czyli taki syndrom „Scrum-Mamy”.
Samodzielność. Nikt nie mówi mi, co mam robić. Sama muszę zebrać potrzeby i problemy, znaleźć rozwiązania lub doprowadzić do ich znalezienia. Wymyślić jak pracować z zespołem, co na nich działa a co nie, wyznaczać sobie plan swojego osobistego rozwoju i rozwoju zespołów, wyznaczania sobie KPI, „milestonów”, szukanie feedbacku u innych, bycie „busy” w sensowny sposób, a nie tylko, żeby nie wydawało się wszystkim, że po codziennym scrumie całymi dniami czytam blogi. Zresztą, danie sobie wewnętrznego przyzwolenia na czas na rozwój też było jednym z pierwszych etapów mojej pracy.
Scrumowi sceptycy i wielbiciele ancien regime chętnie prowokowali do dyskusji i podważali pewne kwestie. Z drugiej strony, dzięki temu, zmuszali mnie do szukania argumentów, do patrzenia na Scruma bardziej realistycznie i krytycznie. Przyzwyczajali mnie do tłumaczenia filozofii agile na różne możliwe sposoby i docierania do zróżnicowanych odbiorców.
Ustalanie priorytetów i ocena tego, co naprawdę jest problemem Jak pilnym, co jest zachcianką, a co jest problemem tylko z mojego punktu widzenia itp.
Organizacja – samej SIEBIE. Kalendarz, notatki, dzielone notatki, bieżące sprawy, długoterminowe sprawy, maile… przez długi czas na początku tonęłam w chaosie, szukałam swoich narzędzi i wypracowywałam flow (co właściwie wciąż jest w trakcie realizacji)
Budowanie relacji i pozycji w zespole oraz organizacji To jest może trochę trudniejsze w przypadku, kiedy muszę tłumaczyć skąd się wzięłam i udowadniać, że jednak coś wiem.
Overthinking Próbowałam swoje poczynania i różne rzeczy zespołowe rozkminić ze wszystkich możliwych stron, przeanalizować, zaplanować i przewidzieć zanim się do nich zabrałam. W efekcie, przede wszystkim bardzo długo trwało, zanim zaczęłam działać, często było już wtedy po temacie, a jeszcze częściej rzeczywistość okazywała się inna, zazwyczaj dużo prostsza, niż sobie to wyobrażałam. Po wielu takich akcjach dotarło do mnie, że wystarczy podejście „start simple”, że trzeba spróbować i potem adaptować, i że próba przewidzenia każdej możliwej reakcji zespołu jest jednak trochę naiwna. Ale, z mojej strony wymagało to pokonania ogromnego strachu przed zrobieniem czegoś głupiego oraz bycia potem trwale ocenianą przez pryzmat jakiejś nieudanej inicjatywy.
Stres, podczas moderowania spotkań. Bałam się, że przerwę w złym momencie, że zadam głupie pytanie. I wielokrotnie się to zdarzało, ale dzięki temu nauczyłam się lepiej wyczuwać dynamikę dyskusji oraz formułować lepsze pytania. To na pewno jest coś, co bardzo się we mnie zmieniło – z rozgadanego filologa, ze zdań wielokrotnie złożonych, przechodzę mocno w stronę przemyślanych, konkretnych i wyizolowanych (tzn. nie 3 różne kwestie naraz) komunikatów. Powtarzanych uparcie aż to otrzymania odpowiedzi lub potwierdzenia odbioru 😉

Wiele z tych problemów rodziło się tylko w mojej głowie i jak najbardziej było do przepracowania, w trakcie stopniowego budowania mojej dojrzałości jako Scrum Mastera.

Czy zespół potrzebuje „technicznego” Scrum Mastera”? (sonda)

Popytałam wśród moich programistów o tę nietechniczność roli Scrum Mastera. Zadałam im na Slacku 3 pytania:

Czy są jakiekolwiek, a jeśli tak to jakie plusy tego, że nie jestem techniczna?
Czy widzicie jakiś wpływ moich wcześniejszych doświadczeń (akademickie i nauczycielskie) na moją pracę jako Scrum Mastera?
Czy są jakiekolwiek plusy tego, że wcześniej nie pracowałam w obszarze IT?

Wynika z nich, że sporo z moich przemyśleń znajduje potwierdzenie w odczuciach programistów:

Programista nr 1

Ad 1.
Sądzę że prowadzenie wszelkich dyskusji przez Ciebie w momencie podsumowania wymaga uproszczenia do zrozumiałej formy dla każdego bez względu na poziom techniczny. Ogółem, często zmuszeni jesteśmy do sprowadzania podsumowań do prostej formy językowej. Oprócz tego, masz większe wyczulenie na problemy poza techniczne np. wewnątrz zespołowe.

Ad 2.
Jasne, swobodne prowadzenie dyskusji, rozumienie różnorodności każdego z nas, próby sprawiedliwego rozdzielenia głosu, umiejętne podsumowania, wyczucie kiedy dyskusja zmierza w złą stronę.

Ad 3. Tak. Wyglądasz całkiem normalnie i potrafisz się komunikować 🙂

Programista nr 2

Ad 1.
Dzięki temu, że nie patrzysz przez pryzmat techniczny:

dajesz się wypowiadać każdemu, chcesz by na spotkaniach wszyscy przedstawiali w sposób nieskrępowany swoje tezy opinie, dzięki temu dopytujesz o rzeczy, których sama do końca nie zawsze rozumiesz, dzięki czemu dyskusja/spotkania są bardziej owocne, panuje lepsze zrozumienie tematu (my mamy z reguły jakieś wyobrażenie danego zagadnienia i jeśli padają jakieś słowa klucze, to się zbytnio nad nimi nie zastanawiamy, a to nieraz błąd, ponieważ przeważnie każdy z nas ma trochę inne pojęcie o tym, o czym mowa, a pytanie wielokrotnie wyjaśnia i uspójnia nasze myślenie)
czuwasz nad tym, nad czym Scrum Master czuwać powinien, skupiasz się na organizacji, rozwiązywaniu problemów natury nie technicznej, bo te techniczne według mnie należą wyłącznie do zespołu, przez to również jest z tobą jako człowiekiem, dobry kontakt i ogólnie dobre relacje (wiem co mówię – piszę, pomny doświadczeniem)

Ad 2.
Tak. Masz podejście nauczycielki, co jest na plus, spisujesz zawsze wszystko na tablicy, sporządzasz podsumowania, no i wymagasz też uwagi od nas na spotkaniach, choć to czasem nieraz może kogoś wkurzać, to jednak uważam, że jest to potrzebne;

Ad 3. Tak. Patrz to, co powyżej 😉

Programista nr 3

Ad 1.
Oczywiście, że są. Da się z Tobą porozmawiać 🙂 Rozluźniasz atmosferę; nie wtrącasz się w techniczne rozmowy udając, że wiesz lepiej – to jest podobno najtrudniejsze wyzwanie dla technicznego SM-a, żeby się odczepić od technikaliów. Czasami czujemy się „zobowiązani” wyjaśnić Ci coś mniej technicznie – co nam też nieraz pomaga.

Ad 2.
Tak. Zdolność wyłuskiwania istotnych rzeczy na spotkaniach i ich notowania. Cierpliwość do magistrów. Pilnujesz na spotkaniach, żeby wszyscy byli na podobnym poziomie zrozumienia omawianego tematu (zadajesz pytania kontrolne itp.)

Ad 3.
Tak. Umiesz pisać odręcznie. Sugerujesz czasem, że analogowe rozwiązania mogą być skuteczniejsze, niż cyfrowe. Myślisz szerzej – o całej firmie/ biznesie, a nie tylko samym IT.

***

Bardzo się cieszę, że Ewa zgodziła się udostępnić ten wpis na łamach mojego bloga. Myślę, że jej „świadectwo” pomoże wielu osobom „nietechnicznym” właśnie, którym marzy się praca Scrum Mastera, ale mają obawy, że nie sprostają technicznym wymaganiom, które się z nią wiążą.

Dla wszystkich, którzy mają takie wątpliwości, mam jedną radę – NIE TRAĆCIE DŁUŻEJ CZASU I APLIKUJCIE! Idealny moment nie nadejdzie nigdy!

A do Scrum Masterów technicznych, zwracam się z prośbą – dbajcie i rozwijajcie w sobie umiejętności, które podobno są mało przydatne, utrudniają zdobywanie autorytetu i rodzą dyskomfort w Waszej pracy z zespołem. Bo tylko dzięki nim macie szansę stać się naprawdę świetnymi Scrum Masterami!