Kto to jest Scrum Master i czym się zajmuje?

Przedstawiamy rolę Scrum Mastera. Definiujemy kim jest Scrum Master. Opowiadamy jak wygląda dzień pracy Scrum Mastera. Podpowiadamy kilka najważniejszych kroków jak Scrum Master może się rozwijać, by stać się lepszym w swoim fachu.

Za sukces zespołów scrumowych w dużej mierze odpowiada Scrum Master. Z tego artykułu dowiesz się:

Kto to jest Scrum Master?

Scrum Master to prawdziwy lider zespołu, korzystający z przywództwa służebnego. Jest to osoba odpowiedzialna za efektywność zespołu korzystającego ze Scruma i pomagająca usuwać wszelkie przeszkody, na które może natrafić zespół.

Bardzo często funkcja Scrum Mastera niepoprawnie kojarzona jest tylko z moderowaniem spotkań, co mocno umniejsza jego roli. Często prowadzi do stwierdzenia, że może nim zostać każdy w ramach dodatkowych obowiązków. Zdarza się też tak, że SM kojarzony jest z osobą, która pilnuje, aby „rzeczy się działy”. W takiej sytuacji jego rola przypomina Project Managera, co jest również błędnym przekonaniem.

Scrum Master to osoba, która powoduje, że zaczynają zachodzić widoczne zmiany dzięki wykorzystaniu zwinnego frameworka Scrum. Zmiany te mają miejsce zarówno na poziomie zespołu, jak i na poziomie firmy. Innymi słowy, SM to “uruchamiacz zmian”. Jest to szczególnie widoczne w firmach, gdzie próbuje się korzystać z metody scrumowej, ale nie ma roli Scrum Mastera. Zespoły często stoją w miejscu i nie realizują żadnych usprawnień. Przez to te same błędy procesowe powielane są przez miesiące czy lata.

Na czym polega praca Scrum Mastera?

3 tryby pracy Scrum Mastera: nauczyciel, konsultant, coach

Na początku funkcjonowania w danym zespole Scrum Master pomaga zrozumieć na czym polega Scruma. Wyjaśnia jak działać w zwinnym podejściu i zgodnie z frameworkiem Scruma. Potem, po wdrożeniu podstawowych ram, SM uruchamia procesy samodzielności w zespole. Przechodzi z trybu nauczyciela w tryb konsultanta, który podpowiada pewne rozwiązania, ale otwiera już przestrzeń do kreowania procesu przez Zespół. Ostatecznie wchodzi w tryb pracy coacha, który sprawia, że zespół samodzielnie wpada na potrzebne usprawnienia i steruje swoim procesem. Podobny mechanizm budowania samodzielności i rosnącej świadomości może odbywać się też na poziomie całej organizacji.

Nie jest to proste zadanie, gdyż każdy z tych trybów jest skomplikowany i wymaga doświadczenia. Nie jest też tak, że tylko jeden tryb jest właściwy w danym momencie. Ten sam zespół może czasem potrzebować porady a czasem zadania mu pytania coachingowego. Ważna jest więc umiejętność płynnego poruszania się pomiędzy odpowiednimi postawami.

Scrum Master działa w 3 obszarach: Developerzy, PO i organizacja

Wyróżnić można też 3 obszary, w których pracuje Scrum Master: Developerzy, Product Owner i organizacja. Proporcje pracy między tymi 3 obszarami różnią się w zależności od firmy. W firmie, w której produkt jest dobrze zarządzany, ale zespoły borykają się z od lat nierozwiązanymi problemami na poziomie procesów wytwórczych, skupienie Scrum Mastera będzie na pracy na poziomie organizacji i współdziałaniu z managementem i ekspertami procesowymi. A w innym przypadku może się zdarzyć, że najistotniejszy problem leży na poziomie współpracy profesjonalistów wchodzących w skład zespołu. W takiej sytuacji Scrum Master poświęci większość swojego czasu, by usprawnić interakcje pomiędzy Developerami.

Zasady w pracy Scrum Mastera

Scrum Master działa w przejrzysty sposób

Ważną cechą sposobu działania Scrum Mastera jest to, by był wzorem przejrzystości wszystkich podejmowanych przez siebie działań i pomysłów. Dzięki temu zespół będzie wiedział czym Scrum Master się zajmuje i o jakie efekty się stara. Może to uzyskać np. poprzez opowiedzenie po codziennym Scrumie, nad czym obecnie pracuje a co może zainteresować Developerów.

Jawne przedstawianie swoich intencji ułatwi Scrum Masterowi pracę. Chcąc wprowadzić do zespołu nowe rozwiązania czy konkretne praktyki, będzie mu łatwiej to zrobić, przedstawiając powody zaproponowanych zmian. Nie będzie musiał tego robić “na siłę”. Zrozumienie przez zespół powodów jego działań może dodatkowo zostać nagrodzone wsparciem i otwartością na dyskusje wewnątrz zespołu.

Scrum Master pomaga zespołowi w samodzielności

Warto podkreślić też, że Scrum Master nie musi sam zastanawiać się jak rozwiązać konkretne problemy w zespole. Dobrą zasadą jest zasada z książki „Coaching Agile Teams” Lyssy Adkins brzmiąca “Take it to the team”. Oznacza ona to, że SM powinien unikać próby samodzielnego decydowania za zespół jakie działania będą dla nich najlepsze. Zamiast tego Scrum Master powinien umieć nazwać dany problem i jasno przedstawić go w zespole. Ale samo skuteczne rozwiązania wynikają z tego co zespół zdecyduje. Scrum Master musi umieć poprowadzić dyskusję, aby na końcu spotkania Zespół uzyskał plan na konkretne kroki do wykonania.

Ponadto, z naszego doświadczenia wynika, że im bardziej zespół będzie zaangażowany w generowanie tych rozwiązań, tym lepiej. Większa jest szansa, że te rzeczy faktycznie zostaną skutecznie zaimplementowane. Członkowie zespołu będą mieli poczucie sprawczości i większej odpowiedzialności za sprawy, które wprowadzają w życie.

SM zakłada, że „zespół ma rację”

Trzecią dobrą zasadą w pracy Scrum Mastera, którą warto rozważyć, jest zasada „zespół ma rację”. W myśl tej idei pozwalaj zespołowi testować własne pomysły. Nawet jeśli masz przeczucie, że są one z góry skazane na niepowodzenia.

Przykładowo, jeśli zespół stwierdza, że nie chce robić codziennego Scruma, to pozwól im na to. Zrób zespołowy eksperyment w ramach jednego Sprintu i zadbaj o to, aby wyciągnąć potem odpowiednie wnioski. Rolą Scrum Mastera jest w tej sytuacji dbanie o to, aby zespół ciągle szukał usprawnień. Dąży do tego, aby zespół był zaangażowany, w to jak pracuje, a nie pilnował sztywnych reguł i podstaw teoretycznych.

Po takim eksperymencie zespół zrozumie, po co są codzienne spotkania i będzie w nich bardziej świadomie uczestniczył. To może być trudne do uzyskania, jeśli Scrum Master zabroni eksperymentu i będzie zmuszał do konkretnych rozwiązań.

Jak wygląda dzień Scrum Mastera w pracy?

Zazwyczaj trudno wskazać stałą czy powtarzalną strukturę dnia. Część czasu Scrum Mastera zabierają wydarzenia w Scrumie. Zajmuje one łącznie nawet 1 dzień w tygodniu na 1 zespół. Część czasu upływa z kolei na spotkaniach z Product Ownerem/ką. Przede wszystkim to z nim/nią przed wydarzeniami Scrumowymi ustalany jest ogólny plan tego, jakie efekty są potrzebne. Natomiast już po wydarzeniach należy omówić, co się wydarzyło, co można zrobić lepiej następnym razem. Oczywiście każde z tych wydarzeń generuje zwykle akcje do wykonania przez Scrum Mastera.

Pracę, jaką wykonuje Scrum Master i wynikający z tego układ dnia roboczego, porównać można do pracy menadżera. Obie te funkcje biorą udział w spotkaniach i warsztatach. Pomagają rozwiązywać problemy i wspierają swój zespół, jeśli ten tego wsparcia potrzebuje. Czasem też praca Scrum Mastera może polegać na konkretnej pomocy przy procesach i narzędziach. Mogą to być przykładowo działania związane z konfiguracji narzędzia online w którym pracuje zespół, albo przy kwestiach organizacyjnych.

Bywa tak, że na koniec dnia Scrum Master ma wrażenie, że tak naprawdę niewiele zrobił. Dużo się działo, ale dzień jakby „przeleciał przez palce”. Z tego powodu dobrze, by każdy SM miał konkretny plan tego, co chce osiągnąć i priorytetyzował swoje działania. Częscią tej priorytetyzacji jest rezygnacja z mniej efektywnych czynności i skupienie na tym, co ma być rezultatem, jaki jest oczekiwany.

W kalendarzu Scrum Mastera warto też zadbać o wolne przestrzenie na luźne i spontaniczne rozmowy. Każda z nich może uruchomić ciekawe interakcje i wygenerować nowe, niespodziewane pomysły.

Gdzie szukać Scrum Masterów?

Skąd wziąć doświadczonych Scrum Masterów? Wiele organizacji marzy o tym, by posiadać wyłącznie bardzo profesjonalnych SMów i unika osób początkujących w tym zawodzie. Naszym zdaniem często wystarczy, aby Scrum Master był tylko nieco bardziej zaawansowany w stosowaniu Scruma niż jego zespół. Kluczowe jest to, aby umiał wytłumaczyć innym, na czym Scrum polega, a jednocześnie ciągle się rozwijał. Scrum Master ciągle szuka wiedzy, wciąż wyprzedzając swój zespół w awansowaniu na kolejne poziomy profesji.

Już nawet początkujący Scrum Master może w zespole robić pozytywną różnicę, zwłaszcza jeśli ma dobrą intuicję i umiejętności organizacyjne. Droga rozwoju Scrum Mastera jest bardzo długa. Satysfakcjonujący poziom realizacji tego zawodu osiągnie się często dopiero przy drugim albo trzecim zespole z kolei.

Pełniąc funkcję Scrum Mastera, trzeba wciąż się rozwijać, ponieważ jego praca nie ogranicza się tylko do moderowania spotkań. Trzeba też między innymi zadbać o to, aby zespół co Sprint dostarczał Przyrost produktu. Ponadto musi mieć umiejętność rozmowy z managementem w atmosferze partnerstwa i współpracy. Wciąż też pojawiają się nowe wyzwania i pola do usprawnień jak np. robienie lepszych Refinementów czy skracanie cykli iteracji.

Scrum Master techniczny czy miękki?

Gdy organizacja szuka Scrum Mastera, może pomyśleć o rozwoju jednego z członków zespołu w kierunku roli Scrum Mastera. Z drugiej strony, możliwe jest zatrudnienie nowej osoby spoza organizacji, ale już z doświadczeniem. Biorąc doświadczonego Scrum Mastera z zewnątrz istnieje ryzyko, że taka osoba na początku będzie trochę wyalienowana od zespołu. Takie osobie, nowej w firmie, zauważalną chwilę zajmie zrozumienie, na czym polega praca poszczególnych członków zespołu i kontekstu produktu.

Kolejny aspekt przy szukaniu Scrum Mastera, to kwestia umiejętności i doświadczeń technicznych. Wiele firm stoi w obliczu decyzji, czy idealny SM to osoba bardziej techniczna, czy z bardziej rozwiniętymi umiejętnościami miękkimi. W większych firmach dobrze się sprawdza posiadanie obu typów Scrum Masterów jednocześnie. Z kolei z perspektywy pojedynczej osoby, która chce zostać Scrum Masterem to dobrze zadać sobie pytanie “w czym jestem lepszy/a? jakie są moje silne strony?” i w tym kierunku się rozwijać dalej.

Nie mamy jednoznacznej odpowiedzi czy Scrum Master techniczny jest lepszy od tego nietechnicznego. W jednym zespole bardziej się sprawdzi Scrum Master, który będzie skupiał się na aspekcie procesowym pracy, czy automatyzowaniu testów. W innym zespole SM bez backgroundu technicznego, dzięki wprowadzeniu zasad komunikacji sprawi, że grupa osób stworzy zespół.

Jeśli chcesz spróbować swoich sił jako Scrum Master to sprawdź ten materiał: „Jak zostać Scrum Masterem„. Ważną propozycją dla rozwijającego się Scrum Mastera może być również książka autorstwa Jacka Wieczorka „Labirynty Scruma„. W praktyczny sposób wskazuje najpopularniejsze pułapki stosowania Scruma i sposoby, by sobie z nimi poradzić.

Transkrypcja podcastu „Kto to jest Scrum Master i czym się zajmuje?”

Kuba: Chcemy Ci opowiedzieć o tym, jaka jest rola Scrum Mastera? Opowiedzieć trochę o tym, kim Scrum Master w ogóle jest, co robi, czego też nie robi? Skąd w ogóle brać Scrum Masterów i jak mogą osoby w roli Scrum Mastera się rozwijać.

Jacek: Tak. Czyli zacznijmy od początku, kto to jest Scrum Master?

Kuba: Można zacząć od bardzo definicyjnych takich wątków. Przewodnik po Scrumie mówi o tym, że Scrum Master to jest lider służebny. Że jest to rola w Scrumie odpowiedzialna za to, żeby być osobą, która pomaga zespołowi w nieprzerwanej pracy. Usuwa przeszkody dla zespołu. Natomiast to jest taka częsta teoria.

Jacek: Zgadza się. I bardzo często to, z czym się spotykam, to takie stwierdzenie, że no dobrze, ale czym tak naprawdę ta osoba się zajmuje? Czyli moja hipoteza jest taka, że to wytłumaczenie scrum Guidowe niekoniecznie dobrze przedstawia tą rolę. Tak żeby osoba, która jej nie zna, mogła sobie wyobrazić, jak wygląda dzień Scrum Mastera.

Kuba: No to i tam w Scrum Guidzie ten opis roli Scrum Mastera w ostatniej aktualizacji został całkiem mocno przebudowany. Co nie zmienia faktu, że czy stara wersja o tym, że Scrum Master jest takim strażnikiem tego, jak Scrum jest stosowany, jak i to aktualne rozpisanie bardziej opisowo nadal tego takiego kalendarza Scrum Mastera z dnia na dzień nie opisuje. A często też kojarzona jest ta rola z takim powiedzmy najbardziej powierzchownym objawem roli Scrum Mastera, czyli moderowanie spotkań.

To znowu bardzo prosto prowadzi do takiego stwierdzenia, że po pierwsze, moderować spotkanie to prawie każdy może. A po drugie, poza spotkaniami ten Scrum Master nie jest potrzebny, czyli jest to rola, którą można pełnić albo w wielu zespołach, trzech, pięciu, jednocześnie. Albo jest to rola, którą po prostu ktokolwiek może wziąć na siebie jako jeden z dodatkowych obowiązków, skoro i tak już na tym spotkaniu zespołu scrumowego jest.

Jacek: Nie, no to, co mówisz, to jest bardzo popularną i lubianą patologią, gdzie Scrum Master jest sprowadzany do roli, no chyba najczęściej takiego moderatora. A w gorszym wydaniu kogoś, kto stoi z kijem i powoduje, że rzeczy się dzieją. I jakby w tym ujęciu ta rola bardziej przypomina project menadżera. I no moim zdaniem nie ma zbyt wiele wspólnego z takim prawdziwym Scrum Masterem. Ani z postawą, której bym się spodziewał.

Kuba: Rozumiem. To jakbyś wytłumaczył tego Scrum Mastera? Bo na razie się zgadzamy, że teoria teorią i patologiczne, typowe zastosowania to nie jest to, co nas satysfakcjonuje.

Jacek: No to tak, tak zupełnie nie siląc się na jakąkolwiek teorię, to ja bym powiedział, że Scrum Master to jest osoba, która powoduje, że zarówno na poziomie zespołu, jak i na poziomie firmy zaczynają się dziać widoczne zmiany. Czyli powiedziałbym, że to jest taki uruchamiacz zmian. I mówię o tym, dlatego że bardzo często się spotykam z sytuacją, gdzie w firmie w ogóle nie ma roli Scrum Mastera. I widać, że te zespoły stoją w miejscu, widać, że nie ma usprawnień. Te same błędy, te same problemy od miesięcy i nagle…

Kuba: Albo lat.

Jacek: Albo lat, w gorszym wydaniu. I nagle pojawia się Scrum Master i powoduje, że ludzie zaczynają mieć refleksje nad tym, jak pracują. Problemy zaczynają być rozwiązywane. To chyba te dwie rzeczy tak w głównym… jakby trzymając się tego wątku, że to jest ta osoba, która jakby uruchamia proces zmiany.

Kuba: No to pasowałoby do mojej definicji. Jak ja przytaczam definicję Scrum Mastera, często poruszam wątek „Scrum Mastera w czasie”. Scrum Master na początku będzie raczej takim kimś, kto wszystkim wytłumaczy, na czym tak naprawdę ta praca w sposób zwinny. I konkretnie praca w sposób zgodny z frameworkiem Scruma polega. A od jakiegoś momentu, po uruchomieniu tych takich podstawowych ram, uruchamia te procesy takiej samodzielności w zespole. Czyli przechodzi z takiego trybu nauczyciela przez tryb, ja bym to powiedział konsultanta, czyli osoby, która jeszcze podpowiada pewne rozwiązania, ale często już mocno współpracuje. Aż po wejście w taki tryb pewnie długofalowo, kilka miesięcy co najmniej mi się wydaje, w takim trybie pracy coacha. Że to już jest raczej osoba, która sprawia, że sam zespół samodzielnie pewne rzeczy robi. Czy product owner, czy w ogóle organizacja jako taka uruchamia pewne działania zaszyte w Scrumie, czyli jakby pod spodem Scruma widoczne, chociaż niekoniecznie na pierwszy rzut oka. Bo tu nie chodzi tylko o to, żeby zespół się w pewien sposób spotykał czy żeby te spotkania były efektywne. Ale żeby też następowały takie rzeczy, jak przyrostowość. Takie rzeczy, jak usprawnianie się co sprint. Takie rzeczy, jak też adaptowanie się do planu, czy to codziennej pracy, czy planu pomiędzy sprintami. Czy nawet jakichś bardziej długofalowych.

Jacek: No to, co powiedziałeś, to pokazuje pewien wycinek. Ale sama praca w tych trybach już jest wyzwaniem. Trudno oczekiwać, że nałożymy komuś czapkę Scrum Mastera i, tak jak powiedziałeś, on płynnie będzie przechodził z trybu mentora czy z trybu nauczyciela, konsultanta, w rolę coacha. W sensie myślę, że każdy z tych trybów jest skomplikowany i wymaga doświadczenia sam w sobie. A co dopiero jakby płynnie poruszać się w tych trybach.

Kuba: No tak, tylko to automatycznie prowadzi do problemu jajka i kury, że skąd brać doświadczonych Scrum Masterów. To jest taka najprostsza… najprościej definiować doświadczonego Scrum Mastera, a jednocześnie najtrudniej go skądkolwiek wziąć. Ja czasem tak mówię, że mi wystarczy, żeby Scrum Master był te pół roku przed zespołem. Czyli spośród całego zespołu, nawet jeśli jest początkującym Scrum Masterem, to najbardziej, najszybciej łapie, na czym Scrum polega. Żeby móc innym go trochę lepiej tłumaczyć niż, no osoby, które kompletnie go nie czują. No i tak samo prawdopodobnie Scrum Master początkujący, ważne, żeby po prostu ciągle się rozwijał i wyprzedzał swój zespół. Ciągle szukał tej wiedzy i się doskonalił, a no nie musi być na starcie idealny. Fajnie, żeby zdawał sobie sprawę, że po prostu czeka go bardzo długa droga. I w każdym z tych trybów, o którym do tej pory wspomnieliśmy, musi poawansować na wyższe poziomy zaawansowania. Możliwe, że nawet w obrębie pojedynczego zespołu nigdy mu się tego nie uda. W tym sensie, że prawdopodobnie przy drugim, trzecim zespole dany Scrum Master zacznie nabierać tej takiej dużej wprawy. Już początkujący Scrum Master może w zespole robić różnicę. Wtedy pewnie dojdzie taka część, może jeszcze nie mam doświadczenia, ale za to mam super intuicję. Mam jakieś takie naturalne, wrodzone albo talenty, albo jeśli chodzi o umiejętności miękkie, ale też takie intuicje organizacyjne. Bardzo zawsze do mnie trafia to, co Ty mówisz o tym, że jak widzisz kogoś w roli Scrum Mastera, no to dobrego od słabego odróżnia to, czy on po prostu ma nastawienie na robienie rzeczy.

Jacek: Tak. To, co powiedziałeś o tej ścieżce rozwoju, to też pokazuje, że… nie wiem, czy to moje już jakieś tam spaczenie zawodowe, ale wydaje mi się, że jest to rola, w której nie ma przestrzeni na nierozwijanie się. Bardzo łatwo jest zmoderować spotkanie powiedzmy. Ale już o wiele trudniej jest zadbać o to, żeby zespół co sprint dostarczał przyrost produktu. Czy o wiele większym wyzwaniem niż prosta moderacja jest umiejętność rozmawiania z managementem. I to nie tylko z takiej postawy na zasadzie jesteście źli, nie pomagacie, gdybyśmy tylko mogli, to byśmy zawojowali świat jako zespół. Raczej rozmowa taka na zasadzie partnerstwa i współpracy.

Kuba: No i też jest coś takiego, że z każdym kolejnym osiągnięciem w takim powiedzmy poziomie zaawansowania zespołu pojawiają się nowe, nie? Czyli pewnie startujący zespół ze startującym Scrum Masterem będzie zadowolony, że w ogóle się zmieścili w time box’ie. Co czasami znowu jest jednym z takich typowych patologicznych sposobów na postrzeganie roli Scrum Mastera, że odlicza czas do końca piętnastu minut Daily Scruma. No, ale jak już się mieszczą w timebox’ie, to może pora na wartość z tych spotkań. Jak już jest wartość ze spotkań, może w ogóle podnieśmy nie wiem, zaangażowanie interesariuszy na sprint review. Róbmy lepsze refinementy, róbmy je zupełnie inaczej. Może róbmy mniej analizy w postaci product backlogu, jak to w wielu zespołach się dzieje, tylko na przykład o wiele więcej produktów wewnątrz sprintu niech powstaje. I jakby każde dokopanie się do jakiegoś poziomu satysfakcjonującego przez danego Scrum Mastera naprawdę jest tylko punktem wyjścia do kolejnego poziomu. Do kolejnych ulepszeń, usprawnień. Zwłaszcza, że też w ogóle domena software developmentu się rozwija. Obaj raptem w parę lat widzimy wzrost znaczenia UX, wzrost znaczenia technologii mobilnych, wzrost też takiego powiedzmy znaczenia związanego z powiedzmy nurtem devops i takim ciągłym dostarczaniem. To wszystko powoduje, że to, co było jeszcze OK parę lat temu, gdzie nie wiem, w czasie studiów się można było o tym uczyć, no to teraz raptem na naszych oczach już przestaje być takie satysfakcjonujące. No i gdzieś tam nie wiem, piętnaście lat temu zapisana myśl o tym, że iteracje miesięczne to jest całkiem satysfakcjonujący Agile, to z perspektywy dzisiejszej wydają się być absurdalne. I możliwe, że zbliżamy się na przykład do tak dużego skracania tych cykli, że wiele zespołów w niedługim czasie będzie na przykład musiało skrócić swoje sprinty. Bo i technologia tego potrzebuje, i biznes może tego wymagać. No i to są takie rzeczy, które nowy zupełnie poziom problemu mogą postawić przed Scrum Masterem. Ale chyba trochę odbiegamy od wątku, kim jest Scrum Master.

Jacek: Tak, zacząłem się zastanawiać, czy dostatecznie wypowiedzieliśmy się na temat już, kto to jest.

Kuba: Ja bym jeszcze dodał do tych takich podstawowych definicji, że jakby ten wymiar definicji Scrum Mastera w czasie to jest jedno. Czyli na początku bardziej nauczyciel i osoba, która tłumaczy, jak dobrze wykorzystać Scruma, potem bardziej konsultant, coraz bardziej coach. Ale też taka inna, trzypunktowa definicja Scrum Mastera to jest pokazanie, w jakich obszarach on pracuje.

Jacek: Tak.

Kuba: I tutaj jest skupienie się na zespole, skupienie się na Product Ownerze i tym aspekcie pracy z produktem. No i duża część odpowiedzialności Scrum Mastera jednocześnie wydaje mi się najtrudniejsza, jednocześnie też największa, jeśli chodzi o potencjał do długofalowej pracy, to jest praca z organizacją. Z otoczeniem zespołu i z firmą jako całością, z jej procesami, z jej strukturami.

Jacek: No i znów tutaj jakby to, co z mojej perspektywy jest interesujące w tej roli to jest to, że proporcje pracy między zespołem, Product Ownerem, produktem a organizacją różnią się w zależności od firmy, w której się znajdujemy. Stąd będąc w firmie A możemy przykładowo pracować więcej z Product Ownerami, z produktem, zakładając powiedzmy, że te osoby są pierwszy raz w tej roli. Natomiast będąc w organizacji, w której powiedzmy produkt ma się dobrze i już jest od lat, ale powiedzmy firma boryka się z wieloma impedimentami, z wieloma problemami takimi nigdy nierozwiązanymi, wtedy być może to skupienie Scrum Mastera będzie musiało być nieco bardziej przesunięte w organizację. Myślę sobie jeszcze, kończąc myśl, że nie ma jednego dobrego wzoru, jak się tym dzielić. Natomiast jakby to, co z mojej perspektywy działa i jest rozsądnym podejściem, to jest szukanie informacji zwrotnej na temat tego, czy dostatecznie dobrze wspieramy wszystkie te trzy wspomniane obszary.

Jacek: Tak.

Kuba: Zacząć wykorzystywać w poprawny, a potem nawet w całkiem umiejętny sposób Scruma. Ale po jakimś czasie to się może bardzo mocno odwrócić i się okaże, że jeszcze tam cyzelowanie pięciu procent efektywności zespołów w prowadzeniu tych nie wiem, retrospektyw, może nie dać tyle, co jakieś odblokowanie bardzo dużego problemu nie wiem, ze środowiskami testowymi, co może się dziać praktycznie kompletnie poza zespołem. I to, co wtedy bardzo jest ważnym aspektem i jest takim wyjściem naprzeciw takim pytaniom, co robi Scrum Master z perspektywy konkretnego, pojedynczego zespołu, to jest bardzo transparentne stosowanie tego czy opowiadanie o tym, co się robi. Czyli ten Scrum Master fajnie, żeby nie był osobą, która w jakiś taki tajemniczy sposób podchodzi do swojej pracy, tylko wręcz odwrotnie, był wzorem transparentności, przejrzystości wszystkich podejmowanych przez siebie działań, wszystkich tych wysiłków, wszystkich swoich pomysłów, żeby było przed zespołem jawne, co ten Scrum Master robi, czym się zajmuje, o co się stara. No i żeby też później, po jakimś czasie, zespół docenił, ile tego wszystkiego dla tego zespołu ten Scrum Master jest w stanie zrobić. I broń Boże nie sugeruję, że to Scrum Master osobiście musi te wszystkie rzeczy robić, natomiast, no czasami jest tak, że pewne rzeczy się dzieją, a na przykład z jakiegoś powodu ktoś stwierdza, że nie chce o tym w zespole opowiadać i mamy prostą receptę na takie proste promowanie, że tam Scrum Master chodzi na spotkania, ale w sumie nie wiadomo, co robi. To taki prosty zarzut, który czasami spotykam.

Jacek: Tak, no z jednej strony spodziewamy się, że podczas codziennego Scruma członkowie zespołu developerskiego będą transparentnie opowiadać, jak przebiega praca, jak przebiega dążenie do realizacji celu sprintu, natomiast, no Scrum Master jako członek zespołu scrumowego z kolei, no trudno, żeby pozostał taki na zasadzie, no wy tutaj pracujcie, wy tu bądźcie transparentni, a ja mam wiecie, poważne rzeczy z panami menadżerami do załatwienia, więc nie interesujcie się. Tak więc zgadzam się z tym, co mówisz, że jeśli uczyć transparentności i ogólnie, no przejrzystości pracy, no to warto tutaj zacząć, będąc w roli Scrum Mastera zacząć od siebie. I praktycznie rzecz ujmując, no to może wyglądać na przykład w ten sposób, że po codziennym Scrumie, jak już developerzy zaplanują pracę, Scrum Master może opowiedzieć ze swojej perspektywy nad czym pracuje, co się dzieje i też skomunikować się z zespołem.

Kuba: Coś, co też często polecam Scrum Masterom to też w tym duchu, którym teraz, przed chwilą, wspomnieliśmy, to też jawne przedstawianie swoich intencji, czyli zaawansowany Scrum Master będzie miał pewien wachlarz technik, które może zastosować, pewne konkretne praktyki, które może w zespole proponować, i dużą krzywdę niektórzy Scrum Masterzy robią sobie, mając dobre intencje z wprowadzaniem jakichś rozwiązań, technik czy dając jakieś propozycje, ale robiąc to w sposób taki, no powiedzmy siłowy czy z takiej pozycji wiem, co mówię, używajmy testów behavior driven development czy jakiejś nie wiem, automatyzacji, czy nawet wracając do jeszcze prostszych rozwiązań nie wiem, stosujmy konstrukcję w postaci historii użytkownika w product backlogu. No może się okazać, że jeśli nie opowiemy, dlaczego tego chcemy zrobić, co takiego jako Scrum Master mamy na myśli, jakie korzyści chcemy uzyskać, wprowadzając pewne rozwiązania, pewne techniki, pewne praktyki czy chcąc coś zmienić w zespole, to też się nadziewamy na duże niebezpieczeństwo, że intencje mamy dobre i nawet rozwiązania mamy poprawne, tylko na przykład zapomnieliśmy opowiedzieć czystym tekstem i prostymi słowami tego, co i dlaczego chcemy w tym zespole zmieniać i jakie są te kroki. I to jakby fajną nagrodą za taką jawność i przejrzystość tego jest też to, że jest spora szansa, że w zespole uzyskamy wsparcie i uzyskamy też, jeśli to są jakieś dyskusyjne rzeczy, to odpowiednio wczesną korektę, odpowiednio wczesne propozycje dodatkowe czy alternatywne do tego, co chcemy wprowadzić, tak żeby to rozwiązanie zostało przez cały zespół lepiej przyjęte.

Jacek: Tak.

Kuba: Zacząć wykorzystywać w poprawny, a potem nawet w całkiem umiejętny sposób Scruma. Ale po jakimś czasie to się może bardzo mocno odwrócić i się okaże, że jeszcze tam cyzelowanie pięciu procent efektywności zespołów w prowadzeniu tych nie wiem, retrospektyw, może nie dać tyle, co jakieś odblokowanie bardzo dużego problemu nie wiem, ze środowiskami testowymi, co może się dziać praktycznie kompletnie poza zespołem. I to, co wtedy bardzo jest ważnym aspektem i jest takim wyjściem naprzeciw takim pytaniom, co robi Scrum Master z perspektywy konkretnego, pojedynczego zespołu, to jest bardzo transparentne stosowanie tego czy opowiadanie o tym, co się robi. Czyli ten Scrum Master fajnie, żeby nie był osobą, która w jakiś taki tajemniczy sposób podchodzi do swojej pracy, tylko wręcz odwrotnie, był wzorem transparentności, przejrzystości wszystkich podejmowanych przez siebie działań, wszystkich tych wysiłków, wszystkich swoich pomysłów, żeby było przed zespołem jawne, co ten Scrum Master robi, czym się zajmuje, o co się stara. No i żeby też później, po jakimś czasie, zespół docenił, ile tego wszystkiego dla tego zespołu ten Scrum Master jest w stanie zrobić. I broń Boże nie sugeruję, że to Scrum Master osobiście musi te wszystkie rzeczy robić, natomiast, no czasami jest tak, że pewne rzeczy się dzieją, a na przykład z jakiegoś powodu ktoś stwierdza, że nie chce o tym w zespole opowiadać i mamy prostą receptę na takie proste promowanie, że tam Scrum Master chodzi na spotkania, ale w sumie nie wiadomo, co robi. To taki prosty zarzut, który czasami spotykam.

Jacek: No, jak mówisz o tym wsparciu zespołu i o tym, jak zespół przejmuje rozwiązania, to myślę, że też warto wspomnieć o tym, że Scrum Master nie musi tych rzeczy analizować, przygotowywać i wymyślać samodzielnie.

Kuba: Tak.

Jacek: Taką fajną zasadą z książki „Coaching Agile Teams” Lyssy Adkins jest zasada take it to the team, czyli nie musimy gdzieś tam samodzielnie w słuchawkach na uszach przez godzinę się zastanawiać, jak sobie poradzić z problemem. Spodziewałbym się raczej, że Scrum Master będzie potrafił nazwać problem, będzie w stanie go jasno przedstawić w zespole, a następnie tak poprowadzić dyskusję i zaproponować taką strukturę spotkania, żeby na koniec mieć jakieś konkretne akcje, jakieś pierwsze kroki do wykonania. Natomiast moje doświadczenie jest takie, że im bardziej zespół będzie zaangażowany w generowanie tych rozwiązań, tym większa jest szansa, że te rzeczy faktycznie zostaną zaimplementowane. Myślę, że przez takie poczucie sprawczości i przez takie poczucie właścicielstwa.

Kuba: No i z tą zasadą, żeby zabierać wszystkie pomysły czy problemy do zespołu, jest też taka dodatkowa zasada, którą ja sobie tak rozszerzam, że zespół ma rację, nawet jeśli, zwłaszcza z perspektywy doświadczenia, stwierdzamy, że ładują się na minę, że tam nie wiem, wymyślają sobie, że nie chcą robić codziennego Scruma. I to może być bardzo pocieszne, obserwowanie tego, i powiedzmy taki bardzo pryncypialny Scrum Master zabroniłby tego pomysłu, natomiast myślę, że zaawansowany i pewny siebie Scrum Master po prostu z zespołem przepracuje ten pomysł. Jeśli zespół twardo uważa, że tak, nie będziemy robili codziennego Scruma, no to spróbujmy tego, zróbmy eksperyment na jeden sprint, może nawet na kilka dni w sprincie, no i zadbajmy o to, żeby to po prostu przećwiczyć i wyciągnąć z tego wnioski. I długofalowo ja bardziej bym się skupił na tym, że Scrum Master skupia się na tym, że zespół staje się samodzielny, skupia się na tym, żeby zespół się ciągle usprawniał, był zaangażowany w to, jak pracują, a nie tylko trzymał ich sztywno według jakichś ram takich metodycznych, nawet z podstaw teorii, bo może się okazać, że zespół, który na chwilę porzuci Daily Scrum, żeby potem odkryć, po co im to w ogóle jest, będzie to robił dwa razy lepiej i znacznie bardziej świadomie niż zespół, który robi Daily Scrum, bo przychodzi Scrum Master i rzuca piłkę, i każe odpowiadać na trzy pytania, i zespół robi to tylko dlatego, że nie można się nie zgodzić ze Scrum Masterem, bo tak menadżer kazał w zespole na przykład. Takie sytuacje czasem spotykam.

Jacek: A czy spotkasz się z pytaniem albo prośbą o wyjaśnienie, czy to na szkoleniach, czy w pracy z zespołami, by tak opowiedzieć, jak wygląda taki dzień Scrum Mastera?

Kuba: Pojawiają się takie pytania. No znów, jakby tutaj odpowiedź jest bardzo kontekstowa, w sensie w zależności od tego, w jakiej jesteś firmie, na jakim poziomie jest Twój zespół, jak wygląda dojrzałość produktowa w firmie, no to ten dzień może wyglądać bardzo różnorodnie. Więc mogę powiedzieć ze swojego doświadczenia, kiedy sam byłem w roli Scrum Mastera, że tak naprawdę nie było jakiegoś takiej stałej czy powtarzalnej struktury dnia. W sensie pewien taki, tak patrząc jakby całościowo na kalendarz, no to automatycznie część Twojego czasu zabierają wydarzenia w Scrumie. Czyli powiedzmy sobie, że jeżeli pracuję jako Scrum Master w tygodniowym sprincie, no to możemy policzyć tak mniej więcej, że jeden dzień odchodzi nam na to, że jesteśmy z zespołem podczas wydarzeń w Scrumie. To jest jakby pierwszy aspekt, który no zjada, powiedziałbym, no taką pewną ilość czasu. To, co myślę w dalszej kolejności się dzieje, to, przynajmniej, jeśli chodzi o moje doświadczenia, to jest regularne spędzanie czasu z product ownerem. Czyli to nie jest taka sytuacja, że ja product ownera widzę tylko na wydarzeniach w Scrumie, tylko zwykle z product ownerem rozmawiam i przed wydarzeniami, żeby ustalić jakiś taki ogólny plan co chcemy uzyskać, współpracowałem podczas wydarzeń, żeby też po już wydarzeniach spotkać się, na spokojnie umówić, co się zadziało z naszej perspektywy, co możemy zrobić lepiej następnym razem. Idąc dalej, każde z tych wydarzeń zwykle generowało jakieś tam akcje do wykonania. Oczywiście takim najbardziej akcjogennym spotkaniem jest retrospektywa, natomiast, no gros notatek, obserwacji czy jakichś takich ad hoc’wych dyskusji z zespołem, no może wychodzić podczas właściwie niemal każdego spotkania. No więc jakby te wszystkie akcje czy te wszystkie rzeczy, które nie działają, no to też jest jakiś temat, który powiedzmy jako Scrum Master po spotkaniach trzeba zrealizować. Oczywiście nie chodzi mi tutaj o to, żeby robić rzeczy za zespół, ale powiedzmy sobie, że nie wiem, jeżeli jest problem ze środowiskami testowymi albo jeżeli jest problem nie wiem, z dostępnością jakichś kompetencji, no to są to rzeczy, które Scrum Master po tym czasie spędzonym z zespołem ma na swojej liście, no i to jest taki dzień, bym powiedział, trochę bym porównał taką pracę Scrum Mastera do pracy menadżera, że czasem to jest koszmar i trzeba zareagować, czasem to jest wcześniej umówione spotkanie, czasem to jest jakiś warsztat, na którym trzeba wypracować jakieś rozwiązania, a czasem też taka bardzo, że tak powiem, przyziemna praca na zasadzie nie wiem, pomoc zespołowi skonfigurować program, w którym trzymają backlog, czy pomóc z jakimiś takimi rzeczami organizacyjnymi, nie wiem, pomóc w przeprowadzce zespołów tam nie wiem, z open space’a jakby do oddzielnych pokojów. Tak więc wbrew pozorom ten czas znika i to, co mnie osobiście najbardziej zawsze bolało, że przez to, że te zdania są różne i ich jest dużo, no to chcąc, nie chcąc, w to wszystko jeszcze dochodzi koszt przyłączenia kontekstu.

Jacek: Tak.

Kuba: I czasem budziłem się na koniec dnia z takim poczuciem zrobiłem tak niewiele, a ten dzień się skończył.

Jacek: Przeleciał nie wiadomo gdzie.

Kuba: Tak, no nie wiadomo gdzie. Ale tu jakaś rozmowa z kimś, tu kogoś próbujemy zagadać na jakiś temat, jego nie ma, no dobra, to bierzemy kolejną rzecz, tamten się odzywa, no i jakby komunikatory, rozmowy takie offline’owe, jakieś maile, ktoś do nas przyjdzie. Ja bym powiedział, że to jest praca trochę taka oparta też na slacku.

Jacek: Tak.

Kuba: W sensie, że czasem warto być dostępnym po to, żeby w tym momencie, kiedy ktoś chce przyjść i porozmawiać, i poruszyć jakiś ważny temat, żeby być.

Jacek: Tak.

Kuba: Bo często taka rozmowa może uruchomić fajne i ciekawe interakcje.

Jacek: No i właśnie ten slack time, o którym wspominasz, znalazłeś w końcu jakieś dobre tłumaczenie słowa slack time? Na jakie się zdecydowałeś?

Kuba: Na żadne się nie zdecydowałem.

Jacek: Nie zdecydowałeś. No bo teraz może być takie skojarzenie, że jest komunikator Slack, a chodzi bardziej o podejście, że po prostu nie jesteśmy na ful zaplanowani.

Kuba: Obłożeni.

Jacek: Ten Slack time to jest właśnie coś, co jest pułapką w tym pytaniu, od którego zacząłem przed chwilą, że jak wygląda kalendarz Scrum Mastera, to ten kalendarz tak przed rozpoczęciem dnia fajnie, jeśli on nie wygląda tak, że jest na sto procent wypełniony, bo Scrum Master ma też jakąś tam porcję pracy nieplanowalną i to może być nieplanowalne również w bardzo losowy sposób. I fajnie, jeśli ten Scrum Master ma też chwilę oddechu. Zakładam, że Scrum Master, jak ma chwilę oddechu, to nie będzie siedział i dłubał w nosie i grał sobie w piłkarzyki, oczywiście parę minut nikomu nie zaszkodzi, ale w tym czasie też na przykład poczyta trochę o technikach na retrospektywę, pójdzie do innego zespołu, do zaprzyjaźnionego innego Scrum Mastera, podejrzeć, jak on pracuje, być może się umówią w jakąś grupę kilku Scrum Masterów z różnych zespołów z danej firmy, żeby coś fajnie razem między zespołowego zorganizować albo rozwiązać jakiś problem, albo może coś nie wiem, pokomunikować do całej firmy, przygotować jakiś warsztat, zrobić jakiś fajny event. Więc ja zakładam, że Scrum Master raczej się nie nudzi. To w drugą stronę bardzo ryzykowne podejście, które czasem spotykam ze strony menadżerów, zwłaszcza takich, którzy gdzieś tam mocno myślą tą perspektywą, żeby wszystkie osoby w firmie były bardzo zajęte, no to takie osoby potrafią też ładować robotę Scrum Masterowi i on nie ma czasu reagować na potrzeby takie codzienne, wynikające z zespołu. I nawet nie chodzi o to, czy on tam po prostu rzuca wszystko i natychmiast reaguje, ale też po prostu, jak przychodzi naprawdę większy impediment, na przykład zaczyna podejmować jakieś fajne działania zespołowe i ogólnofirmowe. No i Scrum Master, który ma z góry zaplanowany bardzo mocno czas, może nie dać rady zareagować, a w najgorszych przypadkach, i takie czasem spotykam, to może
nawet nie zauważyć, że potrzebuje zareagować.

Kuba: No dobra, to opowiedzieliśmy sobie trochę, jaka jest definicja Scrum Mastera, co robi, jak wygląda jego kalendarz, jakie typowe działania podejmuje, a czego Twoim zdaniem Scrum Master w szczególności nie robi?

Jacek: Ja myślę, że tutaj taką najczęstszą pułapką, która się pojawia w roli Scrum Mastera, to jest wchodzenie w rolę taką project menadżerską. I mówiąc o roli project menadżerskiej mam na myśli to, że taki Scrum Master zaczyna mocno interesować się zakresem realizowanego produktu.

Kuba: Mieć zdanie na jego temat.

Jacek: Mieć zdanie, dokładnie. Dokładać jakieś elementy do tego backlogu. Często wiąże się to też z taką chęcią posiadania dużej kontroli nad tym, co się dzieje, czyli bardzo punktowe wskazywanie, kto czym się będzie zajmował, jednocześnie dbając o to, żeby te wskazania były monitorowanie, czyli…

Kuba: Tak, oczywiście w dobrych intencjach i żeby projekt szedł do przodu, i żeby wszyscy byli tacy zorganizowani. No też byłem tam i to widziałem.

Jacek: Zgadza się. Co więcej, no jakby jeszcze pozostając w tej pułapce takiej project menadżerskiej, no to często to takie ciśnienie wynikające z tego, że mamy termin i mamy zakres, powoduje, że bardzo łatwo Scrum Masterom, którzy wchodzą w rolę project menadżera, przychodzi ucinanie wszelkich takich aktywności rozwojowych, czyli…

Kuba: Tak.

Jacek: Zamiast się zatrzymać i omówić problem, no to raczej jest takie jakby popychanie tematu do przodu, że dobra, później, bo teraz mamy terminy, musimy dowieźć. Tak więc czego nie robi? No na pewno nie jest zarządcą, na pewno nie jest kimś, kto mówi, kto czym się będzie zajmował. Zwykle nie jest też szefem zespołu, chociaż to może być różne w zależności od zespołu. No i myślę, że nie jest też osobą, która bierze odpowiedzialność, czy jakby nie powinien być osobą, która bierze odpowiedzialność za rezultaty pracy zespołowej. Czyli nie jest też takim chłopcem do bicia na wypadek, gdyby się okazało, że nie wiem, produkt nie spełnia oczekiwań czy dzieją się jakieś niedobre rzeczy. Zamiast się zatrzymać i omówić problem, no to raczej jest takie jakby popychanie tematu do przodu, że dobra, później, bo teraz mamy terminy, musimy dowieźć. Tak więc czego nie robi? No na pewno nie jest zarządcą, na pewno nie jest kimś, kto mówi, kto czym się będzie zajmował. Zwykle nie jest też szefem zespołu, chociaż to może być różne w zależności od zespołu. No i myślę, że nie jest też osobą, która bierze odpowiedzialność, czy jakby nie powinien być osobą, która bierze odpowiedzialność za rezultaty pracy zespołowej. Czyli nie jest też takim chłopcem do bicia na wypadek, gdyby się okazało, że nie wiem, produkt nie spełnia oczekiwań czy dzieją się jakieś niedobre rzeczy.

Kuba: A takie ciągoty, żeby kogoś takiego w zespole scrumowym mieć, mimo że framework wyraźnie mówi o tej odpowiedzialności całego zespołu scrumowego? No to niejeden menadżer ma ochotę wzbogacić Scruma o to podejście, że a jak ktoś ma się tłumaczyć, to niech to będzie Scrum Master i to do niego pójdziemy, żeby nam opowiedział, jak przebiegają prace, kto zawodzi, gdzie należy coś poprawić. No to faktycznie nie są wszystko rzeczy scrum masterskie. Nie jest przedstawicielem zespołu scrumowego, ale coś, co też bym podkreślił, że nie jest rolą Scrum Mastera też na przykład bycie przedstawicielem zespołu developerskiego, bycie, czasem to słyszę…

Jacek: Myślę, że nie jest też sekretarką zespołu. Nie jest proxy zespołu.

Kuba: Tak. A takie ciągoty, żeby kogoś takiego w zespole scrumowym mieć, mimo że framework wyraźnie mówi o tej odpowiedzialności całego zespołu scrumowego? No to niejeden menadżer ma ochotę wzbogacić Scruma o to podejście, że a jak ktoś ma się tłumaczyć, to niech to będzie Scrum Master i to do niego pójdziemy, żeby nam opowiedział, jak przebiegają prace, kto zawodzi, gdzie należy coś poprawić. No to faktycznie nie są wszystko rzeczy scrum masterskie. Nie jest przedstawicielem zespołu scrumowego, ale coś, co też bym podkreślił, że nie jest rolą Scrum Mastera też na przykład bycie przedstawicielem zespołu developerskiego, bycie, czasem to słyszę…

Jacek: Adwokatem.

Kuba: Właśnie adwokatem albo związkowcem związków zawodowych, że on tutaj w imieniu zespołu, dla dobra zespołu, ale mimo wszystko tak bardzo staje po jednej ze stron, zamiast być raczej tym tutaj takim coachem całego procesu.

Jacek: Nie wiem, czy to nie jest naleciałość tego angielskiego stwierdzenia, że protect the team. Okej, chroni, ale ta ochrona to nie znaczy, że wkłada zespół pod szklany kosz i ktokolwiek chce przyjść do zespołu, porozmawiać, to mówi nie teraz, mamy sprint i w ogóle odejdź, no bo to jakby stoi absolutnie w sprzeczności też z jakimiś wartościami, które stoją za manifestem agile’owym. Jeśli mówimy też o tym, kim jest, kim nie jest, a nie wspomnieliśmy o tym jeszcze, to ta rola może być pełniona przez osoby, które mają jakieś określone stanowiska odpowiedzialności w firmie. I to oczywiście ma plusy, i minusy, natomiast może możesz się spotkać z sytuacją, w której Scrum Master będzie jednocześnie developerem albo będzie jednocześnie menadżerem. Widziałem sytuację, w których był też product ownerem. Natomiast moje podejście jest takie i wiem, że tutaj się możemy chyba różnić…

Kuba: Bardzo.

Jacek: W sensie ja…

Kuba: Elegancko.

Jacek: Tak, to ja powiem, jakie jest moje podejście. Ja uważam, że to jest rola taka jakby stuprocentowa, w sensie możesz pracować z jednym zespołem jako Scrum Master, możesz z dwoma, natomiast nie widziałem dotychczas i myślę, że to jest powód, dla którego tak bardzo się jakby trzymam tego mojego podejścia, nie widziałem udanej implementacji Scrum Mastera będącego jednocześnie developerem. Zwykle, kiedy te dwie odpowiedzialności się łączą, no to widzę bądź osobę, która jest developerem dokładnie tu i teraz, i właśnie przez to, że jestem developerem, przez to, że skupia się na tych aspektach powiedzmy technicznych, dosłownie w tym samym momencie nie ma nikogo, kto zadbałby o to, żeby na przykład zmoderować spotkanie, żeby zaangażować osoby, które od pół godziny konsumują tlen w pokoju, a jakby nie dają nic w zamian i tak dalej. Tak więc jakby to z mojego punktu widzenia jest jakieś tam ryzyko.

Kuba: No, tutaj się różnimy o tyle, że powiedzmy upraszczając, ja widzę możliwość łączenia roli Scrum Mastera z innymi rolami, czy w zespole, czy w ogóle w firmie, natomiast na pewno takie granice, w których ja tego łączenia na pewno nie widzę, no to wspomniane przez Ciebie łączenie roli ownera i Scrum Mastera, to nie mas szans. Też średnio zapatruję się na łączenie roli jakiejś takiej kierowniczej, menadżerskiej nad kimkolwiek w zespole i bycie jednocześnie w tym zespole Scrum Masterem. Natomiast co do roli członka zespołu developerskiego czy powiedzmy pełnienia funkcji, no bo to nie jest w sumie w Scrumie rola i roli Scrum Mastera, to ja tutaj bardziej wierzę w taki powiedzmy długofalowy proces rozpoczynania od czegoś i dorastania do roli Scrum Mastera, więc ja często w zespołach, w których pracuję, nie mam wielkiego problemu z tym, że role Scrum Mastera i członka zespołu wytwórczego się łączy. To na początku z tym problemu nie mam, ale długofalowo fajnie, żeby ten Scrum Master coraz bardziej się profesjonalizował. I coś, do czego ja się tu przekonuję, to to, że to jest taka rola, do której uważam, że trzeba dorosnąć i trudno, trudniej może, przejść w taki tryb wszystko albo nic, że musisz pierwszego dnia próbowania roli Scrum Mastera od razu być dedykowanym, full-time’owym, profesjonalnym Scrum Masterem. W wielu organizacjach jest to trudne do zorganizowania, ale też z perspektywy wielu osób, które świetnie się do tego nadają, może to być po prostu duży przeskok, jeśli ktoś od kilku lat rozwija swoją karierę programisty i ma świetne zadatki na Scrum Mastera, to możliwe, że potrzebuje też parę ładnych miesięcy do tego, żeby spróbować tej roli, przekonać się do niej i ja długofalowo jestem za tym, żeby się uprofesjonalniać i być zawodowym Scrum Masterem, ale w takim okresie przejściowym, zwłaszcza, jeśli uwzględnimy temat transformacji organizacji, to możliwe, że w okresie przejściowym to może zadziałać, żeby przez jakiś czas na przykład tą rolę łączyć. Ważne, żeby wtedy mieć mentora, żeby ciągle się rozwijać i też żyć tą myślą, że za jakiś czas dojdę do tego rozstaju dróg, w którym muszę się zdecydować, czy chcę być zawodowym Scrum Masterem, czy chcę nadal łączyć tą rolę i z perspektywy organizacji być może jakaś część Scrum Masterów może być taka łącząca role, ale no długofalowo łączenie tych ról z tymi wszystkimi powiedzmy dysfunkcjami, o których wspomniałeś, że nie zwracam uwagi, bo jestem po prostu developerem jednym z wielu i oprócz tego połowę czapki Scrum Mastera mam na głowie, no to tak naprawdę nie masz żadnej czapki i możliwe, że ten Scrum też po prostu u Ciebie nie działa.

Jacek: No ten obszar wiedzy, który jakby czeka na Ciebie, kiedy zaczynasz jako Scrum Master, no jest olbrzymi. Jakby i drugi tak samo olbrzymi obszar to jest, jeśli chcesz być nie wiem, full-stack developerem. Tak więc jakby myślę sobie, że naprawdę takie chyba tylko bardzo rozsądne podejście do tego, co wyjmować z tego zestawu umiejętności Scrum Mastera, może doprowadzić do tego, że takie łączenie ról w szczególności to tutaj takie z rolą developera mogłoby się udać. Przykładowo wyobrażam sobie developera, który ustawia sobie jakieś tam skupienie na dbanie o porządek spotkań. Czyli dba o to, żeby był jakiś sensowny początek, jakiś cel, żeby później nadać temu spotkaniu jakąś strukturę i ją zakończyć. Pewnie nie będzie to łatwe, no bo wyobrażam sobie, że chęć wskoczenia w dyskusję może być silniejsza niż jakby to takie bycie krok do tyłu, żeby mieć jakby obraz całego spotkania, ale z drugiej strony nie twierdzę, że to jest niemożliwe, przy czym jakby domykając bardzo chciałbym zobaczyć jakby na własne oczy w akcji osobę, która płynnie przełącza się między tymi dwoma rolami bez jakichkolwiek dysfunkcji i uchybień.

Kuba: No to w ogóle jest bardzo powiązane z szerszym wątkiem, skąd brać Scrum Masterów i skąd organizacja ma ich wziąć, i też jak zespół ma sobie poradzić z tą koniecznością posiadania Scrum Mastera i na przykład brakiem chęci do poświęcania się tej roli w całości, więc ta moja wersja powiedzmy takiego okresu przejściowego z łączeniem ról możliwe, że jest taka bardziej ewolucyjna i bardziej bezpieczna. Nie wymaga radykalnych ruchów. Ja sam tak przez może odwrócenie, tak jak mówisz o tym, że są zagrożenia roli łączonej, ja widzę też zagrożenia roli dedykowanej Scrum Mastera, zwłaszcza, jeśli to jest osoba, która przychodzi zupełnie spoza zespołu, to jest no nie zerowa szansa, że ta osoba może być taka trochę wyalienowana od zespołu. Trochę nie wie, na czym polega praca poszczególnych członków zespołu, trochę może nie kojarzy też w ogóle kontekstu produktu, no i też taki dyskutowany pewnie i nierozwiązywalny problem, czy też Scrum Master musi mieć doświadczenie techniczne i na przykład, no ja osobiście znam sporo Scrum Masterów z bardzo fajną techniką, z bardzo fajnymi umiejętnościami, którzy nigdy nie skończyli żadnej uczelni technicznej, a wręcz są po jakiejś psychologii czy po jakichś takich kierunkach humanistycznych i może nie mają ścisłego backgroundu technicznego, nie mają tego doświadczenia osobistego wyprodukowania kodu czy osobistego dołożenia się do wytwarzania oprogramowania, ale za to nadrabiają tymi umiejętnościami miękkimi. Na tą kwestię ja nie mam odpowiedzi, a patrząc z perspektywy całych zespołów scrum masterskich w większych firmach to siłą rzeczy jest więcej tych Scrum Masterów. Uważam, że właśnie ten taki środek jest ekstra, że mamy trochę tych technicznych Scrum Masterów, mamy tych trochę miękkich, mamy te osoby, które jeszcze całkiem niedawno były ściśle w kodzie, mamy te osoby, które już parę lat temu zrezygnowały z tej roli, że tak naprawdę te perspektywy nam się mieszają. I wtedy taka grupa Scrum Masterów działająca na poziomie całej organizacji z różnymi jakby w sumie takimi optykami to jest takie optimum, o które szczególnie bym zawalczył. No jeśli patrzeć na to z perspektywy pojedynczej osoby, Ciebie słuchaczu, no to zastanów się, jak wyglądają te Twoje silne strony, czy nimi grasz, co zrobisz, żeby też zasypać te ewentualne słabości, takie, które wynikają z braku jakichś doświadczeń czy wynikają z braku jakichś przeżyć wspólnych z zespołem.

Jacek: No to, co mówisz, granie na silne strony, to absolutnie to kupuję w sensie takim, że widziałem Scrum Masterów z backgroundem technicznym i oni powiedzmy bardziej się skupiali na tym takim aspekcie procesowym pracy, czyli powiedzmy sobie nie wiem, dążenia do tego, żeby jakość była jak najwyższa, dążenie do tego, żeby automatyzować testy, dążenie do tego, żeby skracać lead time. I to było okej, a z drugiej strony widziałem Scrum Masterów absolutnie nietechnicznych, którzy genialnie pracowali na poziomie procesu grupowego. I potrafili w naprawdę krótkim czasie z grupy osób robić zespoły, które brały odpowiedzialność, tak więc myślę, że tak jak w przypadku po prostu generalnie zespołów, to, co powiedziałeś, fajnie jest mieć różnorodność i możliwość patrzenia na to samo z różnych perspektyw.

Kuba: Patrząc z perspektywy pojedynczego zespołu może być tak, że do danego zespołu pasuje pewien specyficzny typ Scrum Mastera. Wyobrażam sobie, że zespoły z wielkim kultem podejścia inżynierskiego mogą same też oczekiwać, że ten Scrum Master jest jednym z nich. W innych zespołach, w których jest bardziej problem międzyludzki i tak naprawdę świetny background techniczny, znajomość technik, znajomość praktyk inżynierskich może się okazać wtórne względem tego, że po prostu się nie dogadujemy, mamy konflikty, nie umiemy sobie przekazywać informacji zwrotnej. I tam akurat osoba o profilu bardzo miękkim może być tym, co jest bardzo potrzebne. To jest to prostu tak też, że może nawet, jeśli w Twoim obecnym zespole jako Scrum Master czujesz, że coś nie gra, to może nie jest tak, że to z Tobą jest coś nie tak, tylko po prostu w tym zespole jest potrzebny po prostu ktoś inny. Jest fajnie, jeśli w ramach organizacji można spróbować zmiany roli Scrum Mastera na zasadzie spróbowania w jakimś innym zespole, może tak zresetowania się, wystartowania od zera i zobaczenia, czy to z nowym zespołem, na innych regułach, ze świeżym startem, jesteśmy w stanie zadziałać trochę lepiej. Ja sam też czuję to też nawet po sobie, ale też widzę, jak obserwuję Scrum Masterów, z którymi pracuję, których rozwijam, że tak naprawdę ten pierwszy zespół, to i tak z perspektywy czasu nasz pierwszy zespół, dla niektórych Scrum Masterów jedyny zespół, to jest tak naprawdę takie przetarcie się. Te fajne rezultaty uzyskuje się w kolejnych zespołach i nie ma co się tego bać, żeby za jakiś czas wyjść ze swojego zespołu, zmienić ten zespół, czy w ramach tej samej firmy, czy nawet skorzystać z okazji do wyjścia poza firmę, odświeżyć, być może spróbować trochę już z nowymi doświadczeniami rozpocząć pracę jeszcze raz, zwłaszcza, jeśli mówimy tutaj o tej perspektywie zawodowej, no to to jest ścieżka kariery, bycie Scrum Masterem. I to też jest, no jakby kompetencja bardzo na rynku poszukiwana.

Jacek: Tak, jak sięgam pamięcią w tył, to takie punkty, w których mam poczucie, że najwięcej się nauczyłem, to były właśnie momenty, kiedy zmieniałem kompletnie zespół, czyli na przykład przechodziłem z zespołu, który rozwijał produkt taki developerski, aplikacje, przechodziłem na przykład do zespołu, który w ogóle nie wytwarzał software’u. I takie zderzenie się z trochę inną rzeczywistością to są te momenty, kiedy zwoje mózgowe zaczynają intensywnie pracować i uważam, że takie wystawianie się na nowe okoliczności, na nowe realia, no jest silnym bodźcem do rozwoju jako Scrum Master.

Kuba: No właśnie, to może na zakończenie odcinka porozmawiajmy chwilę o rozwoju. Już parę razy o tym wspomnieliśmy i to jest już w kontekście tych naszych wypowiedzi pozaszywane. Czy jest coś jeszcze albo jakaś taka najważniejsza rzecz, o której myślisz, że musi każdy Scrum Master zadbać, żeby się rozwijać?

Jacek: Myślę, że bardzo wartościową rzeczą, o którą warto zadbać, jest regularny dostęp do informacji zwrotnej. I jest to i proste, i trudne jednocześnie, natomiast jakby to, co jest proste, to to, że ta informacja zwrotna jest wszędzie. To możemy poprosić pojedynczą osobę z zespołu, możemy poprosić product ownera, możemy zespół poprosić, możemy przyjąć menadżera, możemy poprosić innego Scrum Mastera, tak więc jakby właściwie każdy w naszym obszarze, takim trzysta sześćdziesiąt, jest w stanie nam powiedzieć, dać informację zwrotną. To, co jest trudne, to jest zwykle takie przełamanie się i to takie wystawienie się na to, że za chwilę ktoś może mi powiedzieć rzeczy, których może nie do końca chce słyszeć.

Kuba: Tak. Sam dobrze wiem, że jak mam z czymś problem, ale lepiej tego nie wiedzieć, nie usłyszeć.

Jacek: Tak, więc myślę, że ta informacja zwrotna to jest taki… hm, nie wiem, jak to ładnie ująć, ale coś takiego, co jest w stanie nam jakby pokazywać kierunek, korygować takie spojrzenie z zewnątrz, bo często samodzielnie, no pewnych rzeczy po prostu nie będziemy w stanie dostrzec.

Kuba: Ja z takich rzeczy, które uważam za nietrywialne, a samemu mi bardzo pomagały i często radzę to innym Scrum Masterom, to jest wyjście trochę poza swój obszar powiedzmy firmy, czyli relatywnie prosto dostać feedback od własnego zespołu, relatywnie prosto się też dogadać z sąsiednimi Scrum Masterami, natomiast ja widzę sam po sobie i też widzę po innych, ile dają spotkania społeczności dobry kontakt, dobre, takie głębokie czerpanie z konferencji, nie tylko z samych prezentacji, ale też z tego, co się dzieje w kuluarach, poznawanie nowych osób, branie sobie do serca różne rzeczy, które inne osoby mówią, nawet jeśli się z nimi nie zgadzamy, to zastanowienie się, co w tym wszystkim jest. No i teraz jakby ta społeczność zwinna ma tą świetną zaletę, że ta wiedza jest bardzo otwarta, te osoby korzystające ze społeczności są też bardzo nastawione na współpracę, więc są, w każdym mieście odbywają się różnego rodzaju spotkania typu open space, typu bring on no problem, typu jakieś prezentacje, jakieś konferencje, mini konferencje, jest masa tego materiału, masa tych okazji, tylko no trzeba w to zainwestować i trzeba z tego skorzystać. I to jest świetna okazja, żeby się tak przewietrzyć, żeby trochę wyjść spoza tak jakby perspektywy swojej własnej firmy, być może swoich własnych też jakichś tam powiedzmy lokalnych optymalizacji, które łatwo rozbić dopiero w momencie, gdy się zaczerpnie tego powietrza z zewnątrz.

Jacek: Ja myślę, że temat, jak rozwijać się jako Scrum Master, to jest kąsek na zupełnie oddzielny odcinek. A dzisiaj myślę, że będziemy kończyć.