Dobry Scrum Master dużo słucha, dużo pyta, mało mówi. Wywiad z Marcinem Grochowiną

Szkoli, konsultuje, rozwija produkty. Marcin Grochowina od ponad dekady pomaga firmom IT w budowaniu zwinnego mindsetu. Co robi, aby się nie wypalić? Jakie cechy według niego powinien posiadać dobry Scrum Master? Odpowiedzi na te i inne pytania znajdziecie w naszej rozmowie.

Cześć Marcin, co u Ciebie? Widziałem, iż ostatnio masz sporo na głowie. Na co poświęcasz najwięcej swojego czasu?

Uszanowanko!

Fakt, nie będę ukrywał, iż 2022 był ciekawym rokiem.

Przede wszystkim-od 9 lat buduję zwinną kulturę organizacyjną FreshMaila. Pełnię tu w tej chwili rolę Scrum Mastera i Agile Coacha, który pracuje z zespołami scrumowymi, gronem liderskim i gronem menadżerskim nad codziennymi wyzwaniami związanymi z rozwojem produktu z segmentu SaaS.

Pracuję również jako konsultant, pomagając firmom w budowaniu zwinnego mindsetu. Szkolę, prowadzę warsztaty i jestem mentorem. Moimi mentees są głównie Scrum Masterzy – ale nie tylko. Opiekuję się też osobami pełniącymi funkcje liderskie, które chcą rozwijać samoorganizację i lepiej zarządzać swoimi zespołami.

W ostatnim kwartale ‘22 miałem również przyjemność zaprojektować i poprowadzić zajęcia z przedmiotu “Organizacja pracy w zwinnym zespole” dla studentów pierwszego roku jednego z kierunków na Wyższej Szkole Europejskiej im. Tischnera w Krakowie. Było to dla mnie super ważne doświadczenie. Dlaczego? Dlatego, iż nasz system edukacji uczy nas raczej pracy indywidualnej. Później wchodząc na rynek pracy, mamy zderzenie z rzeczywistością, w której oczekuje się od nas, iż będziemy wiedzieli, jak dogadać się w zespole, jak podzielić między sobą odpowiedzialności, jak komunikować swoje potrzeby, czy udzielać informacji zwrotnej. Bardzo się starałem, by podstawy z tych obszarów przekazać moim podopiecznym.

Od wielu lat pracujesz z Agile, w ostatnim czasie zacząłeś stawiać także na prywatne konsultacje. W jaki sposób utrzymujesz motywację od ponad dekady? Co sprawiło, iż jeszcze się w tym wszystkim nie wypaliłeś?

Haha! Rzeczywistość wcale nie jest aż tak Instagramowa. Przez te moje 15 lat w branży miałem wzloty i upadki w kontekście motywacji. Łącznie z potężnym wypaleniem zawodowym, z którym mierzyłem się w ciągu ostatnich lat. To, co z pewnością mi pomogło, to zrozumienie moich mocnych stron. Zrozumienie, że… nie muszę być specjalistą od wszystkiego. Zacząłem definiować obszary, w których jestem w stanie wspierać zespoły i organizacje, a także odrzucać te, w których nie czułem, iż jestem w stanie dawać wartość.

Jestem gadułą. I lubię tworzyć kontent. Dlatego z czasem zacząłem dzielić się swoim doświadczeniem (konferencje, meetupy, LinkedIn, Instagram) i okazało się, że… klienci zaczęli pojawiać się w sposób dość organiczny. Nie poszukiwałem aktywnie nowych relacji biznesowych, a mimo to kalendarz zapełniał się sam.

Skupienie się na tym, co lubię najbardziej i w czym tę wartość jestem w stanie dawać pozwoliło mi trochę wyrównać tę moją sinusoidę “wzlotów i upadków”, bardziej to wszystko wypłaszczyć. Mogę powiedzieć, iż w tej chwili budzę się z uśmiechem na gębie, myśląc o wyzwaniach rozpoczynającego się dnia. Często jest to zmęczona gęba (bo śpię mało), ale jednak uśmiechnięta.

Niektórzy twierdzą, iż “agile’owcy” i Scrum Masterzy to zamknięta bańka, która robi sobie “nawzajem dobrze”. Czy faktycznie tak to wygląda z Twojej perspektywy?

Tak.

Do tej sytuacji odniósł się w interesujący sposób Martin Fowler – postać legendarna, związana z takimi tematami jak refaktoring czy wzorce projektowe w obszarze architektury. Jeden z współtwórców The Agile Manifesto.

W 2018 Martin wystąpił na konferencji Agile Australia z keynotem zatytułowanym “Stan zwinnego programowania w 2018 roku” (The State of Agile Software in 2018). Zadał tam proste pytanie: “Ile z siedzących tu na sali osób jest developerami”. Rękę podniosła garstka. Fowler wskazał to jako jeden z głównych problemów ówczesnego “edżajla”.

Jego konkluzją było, iż w większości konferencji na temat Agile biorą udział osoby związane z Project Managementem i generalnie z obszarem zarządzania, a osoby “wykonujące faktyczną pracę” stanowią mniejszość. To właśnie ta sytuacja, którą ruch Agile’owy miał odmienić. Napisany przez developerów manifest miał zbliżyć do siebie interesariuszy i zespoły wytwarzające.

Temat ten jest wciąż bardzo aktualny. Moim zdaniem dzieje się tak dlatego, iż myśląc “Agile” w wielu organizacjach stawiamy znak równości ze zwinnymi procesami, praktykami i narzędziami. “Jesteśmy zwinni, bo mamy sprinty, backloga i Product Ownera”. Tymczasem zwinność to przede wszystkim styl myślenia. O tym, w jaki sposób się ze sobą komunikujemy. Jak rozmawiamy o priorytetach. Jak planujemy naszą pracę. Jak rozumiemy, nad czym aktualnie pracujemy – i dlaczego. W jaki sposób informujemy się o postępach. I… jak w tym wszystkim jesteśmy ze sobą szczerzy.

Dopóki “agile’owcy” i Scrum Masterzy skupiają się na wprowadzaniu kolejnych procesów i narzędzi, zamiast na definiowaniu faktycznych problemów, z którymi boryka się zespół, dopóty przyklejamy plasterek na otwartą ranę.

Gdybyś miał wymienić trzy rzeczy, które w Twojej działce zmieniły się najbardziej w ciągu ostatnich lat, to co by to było?

Od pewnego czasu obserwuję zdecydowanie bardziej świadome kształtowanie kultury organizacyjnej. Ta zaczyna się już na poziomie procesu rekrutacyjnego. Bardziej świadome organizacje patrzą już nie tylko na umiejętności techniczne, ale również na umiejętności komunikacji czy współpracy. Zwłaszcza że… z mojej perspektywy dużo łatwiej jest rozwijać kompetencje twarde niż te miękkie.

Okrutnie nie lubię tego wyświechtanego frazesu “nie po to studiowałem informatykę, żeby musieć rozmawiać z ludźmi”. Zostawmy z boku temat sztucznej inteligencji, przepowiedni samopiszącego się kodu i tego, iż główną kompetencją przyszłości nie będzie pisanie kodu samo w sobie, ale umiejętność tłumaczenia potrzeb człowieka na język maszyn. Najlepsi specjaliści, z którymi w ciągu piętnastu lat miałem przyjemność współpracować, to Ci, którzy swobodnie komunikowali się z innymi-zarówno wewnątrz zespołu, jak i z interesariuszami czy klientami.

Wracając do początku wypowiedzi, szczęśliwie coraz więcej organizacji orientuje się, iż łatwiej u dobrze komunikującego się i pasującego do kultury firmy kandydata podciągnąć umiejętności techniczne niż sięgać po toksyczną super gwiazdę.

Drugi obszar to praca zespołowa. Coraz częściej spotykam się ze zrozumieniem, iż zespół to nie grupa indywidualistów, tylko żywy organizm, który jest współzależny od tworzących go jednostek. Że od tego, czy uda nam się zrealizować postawione przed nami zadania, czy cele nie zależy tylko poziom naszych kompetencji, ale również to, jak rozumiemy swoje wzajemne słabe i mocne strony. I to, jak potrafimy się wzajemnie uzupełniać.

Numer trzy to “remote”. Trend, który w ostatnich latach nabierał coraz większej popularności nagle w 2020 stał się “nową rzeczywistością”, która niesie ze sobą nowe wyzwania. Zasadniczo… firmy, które na dosyć wczesnym etapie odrobiły powyższe dwie lekcje (czyli świadomie kształtowały kultury organizacyjne i mądrze budowały zespoły) z pewnością na starcie tego “nowego wspaniałego świata” miały łatwiej. Oczywiście ta nowa rzeczywistość wymaga też zmiany swoich przyzwyczajeń, nie tylko po stronie pracowników, ale przede wszystkim osób zarządzających organizacjami.

Miałem tu jeszcze ochotę rozpędzić się i wspomnieć o buzzwordach typu “silent quitting”, stereotypach w stylu “z millenialsami nie da się pracować” i generalnie… boomerskim podejściu kadry menedżerskiej, ale w tym miejscu postawię po prostu kropkę.

W sieci można znaleźć sporo memów, które piją do tego, iż Scrum Master tak naprawdę nic nie robi i jest swego rodzaju “przedzszkolanką” dla programistów. Nie jest Ci w związku z tym przykro?

Owszem, gotuję się na widok tych powielanych stereotypów, ale… tylko gdy widzę, iż ten stereotyp pogłębiają firmy szkolące ze Scruma. A mieliśmy taki przypadek w 2022 roku.

Cóż mogę powiedzieć. Różne emocje odpalają mi się, gdy widzę takie komentarze, ale z pewnością nie jest to przykrość.

Z jednej strony mam sporo empatii, jeżeli osoba wypowiadająca się w ten sposób ma za sobą doświadczenia pracy w zespole scrumowym. Bo najprawdopodobniej nie są do dobre doświadczenia czy wspomnienia. I z dużą pewnością Scrum Master w tym zespole nie wykonywał swojej “roboty” we adekwatny sposób. jeżeli przekazywałby na odpowiednim poziomie wiedzę dotyczącą reguł gry w Scruma wewnątrz zespołu czy na poziomie całej organizacji, jeżeli pomagałby w prowadzeniu spotkań (facylitował je) w taki sposób, by były efektywne i by zespół realizował cele danego spotkania, jeżeli pomagałby w rozwiązywaniu problemów, z którymi borykają się członkowie zespołu…

Mając doświadczenia pracy z takimi Scrum Masterami raczej nie neguje się wartości Scruma czy nie podważa się zasadności roli SMa.

Jeśli Scrum Master jest przedszkolanką, “scrumową mamą”, policjantem czy zamawiaczem obiadów albo zaparzaczem kawy, to sam ów Scrum Master nie do końca rozumie swoją odpowiedzialność. Z chęcią pomogę. Zapraszam na konsultacje! (śmiech).

Jakie cechy powinien posiadać według Ciebie dobry Scrum Master? Na co najlepiej położyć nacisk na początku swojej drogi?

Dobry Scrum Master dużo słucha, dużo pyta, mało mówi, ale przede wszystkim… ma solidne podstawy Scruma i rozumienia zwinności.

Trzy najlepsze rady, które dostałem po drodze w trakcie kształtowania swojego zwinnego mindsetu brzmiały: “ a co mówi o tym Scrum Guide?”, “zapytaj zespołu” oraz “nie bądź zawsze osobą, która zabiera głos jako pierwsza”.

Scrum Guide, czyli przewodnik opisujący scrumowe zasady gry na serio zawiera mnóstwo odpowiedzi na problemy scrumowego życia codziennego. Stawiając pierwsze kroki i mierząc się z wyzwaniami związanymi z planowaniem pracy czy tym, jak rozkładają się odpowiedzialności w zespole, wielokrotnie zaglądałem do tego króciutkiego dokumentu i byłem zaskoczony, że… choćby jeżeli nie znajdowałem tam dokładnego rozwiązania mojego problemu, to lektura kilku “regułek” na dany temat uruchamiała proces myślowy nakierowujący mnie na rozwiązanie.

Jako lider służebny (servant leader) warto wyrabiać w sobie nawyk zadawania pytań. I wspólnego rozwiązywania problemów wraz z zespołem. Nie podawania wszystkich rozwiązań na tacy, ale dawania przestrzeni na wypowiedź każdej osoby zainteresowanej rozwiązaniem danego problemu. Tak by ostatecznie rozwiązanie nie było narzucone przez jedną osobę, ale było wspólnie wypracowane. Dlaczego? Bo to buduje współodpowiedzialność za dbanie o to ustalenie. jeżeli brałem czynny udział w stworzeniu rozwiązania, miałem przestrzeń do wypowiedzenia swoich opinii, potrzeb i oczekiwań i ten głos został uwzględniony w tym, co stworzyliśmy na koniec, to w dużo większym stopniu będę dbał o stosowanie się do tych ustaleń. Bo są one “moje”.

Trzecia rada związana jest bezpośrednio z tą drugą. Zadawanie pytań ma na celu usłyszenie zdania innych osób. jeżeli zaraz po pytaniu, czy po zdefiniowaniu jakiegoś problemu, który chcemy rozwiązać od razu, podajemy propozycję rozwiązania, to ciężko tu mówić o próbie wsłuchania się w potrzeby innych osób.

Właśnie na te trzy aspekty-zrozumienie SG i częste do niego wracanie po odpowiedzi, otwartość na potrzeby i opinie innych dzięki zadawania pytań oraz aktywne słuchanie położyłbym nacisk na początku drogi.

Oczywiście idąc na dwudniowe szkolenie, po którym możemy zdobyć certyfikat, powyższych porad nie usłyszycie. Na szkolenia chodzi wielu. A te trzy zagadnienia w rzeczywistości praktykują naprawdę nieliczni.