#001 – Kto to jest Scrum Master i czym się zajmuje?

W pierwszym odcinku naszego podcastu przedstawiamy rolę Scrum Mastera. Definiujemy kim jest Scrum Master, opowiadamy jak wygląda dzień Scrum Mastera i podpowiadamy kilka najważniejszych kroków jak Scrum Master może się rozwijać, by stać się lepszym profesjonalistą.

Zobacz wersję wideo

W tym odcinku mówimy o:

  • 01:07 – Kim jest Scrum Master.
  • 04:40 – Na czym polega jego praca.
  • 06:50 – Gdzie szukać Scrum Masterów.
  • 29:00 – Czego nie robi Scrum Master.
  • 37: 29 – Jak możesz rozwijać się jako Scrum Master.

Jeśli odcinek Ci się podobał, koniecznie podziel się nim z innymi osobami, które Twoim zdaniem mogą go potrzebować. Daj nam znać co sądzisz o odcinku i samej idei podcastu “Porządny Agile”:

Chcemy usprawniać podcast z każdym kolejnym odcinkiem, więc podpowiedz nam, jakie niedoskonałości Twoim zdaniem powinniśmy poprawić.

Mamy sporo pomysłów na to, co jeszcze moglibyśmy nagrać, ale jesteśmy bardzo otwarci na Twoją sugestię – przekaż nam hasło albo temat, o którym moglibyśmy opowiadać w pierwszej kolejności.

 

Transkrypcja odcinka

 

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 definitywnych takich wątków typu 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 raidowe 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ń, co 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 i 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 akie wątek Scrum Mastera w czasie, że 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, w sensie 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 w 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 spring 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ół, ale raczej rozmowa taka na zasadzie partnerstwa i współpracy. 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 spring 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ół, ale 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 time box’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 interview, 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 soft developmentu się rozwija, więc chociażby też, no obaj raptem w parę lat widzimy wzrost znaczenia UX, wzrost znaczenia technologii mobilnych, wzrost też takiego powiedzmy znaczenia związanego z powiedzmy nurtem devox i takim ciągłym dostarczaniem. To wszystko powoduje, że to, co było jeszcze okej 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, no 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ę. Natomiast 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ście, 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: 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 gro 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 jestwcześ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.

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ć.


20 Replies to “#001 – Kto to jest Scrum Master i czym się zajmuje?”

  1. Karola Kluczyk

    Świetna dawka praktyki i doświadczenia. Słuchając od razu widać, że autorzy podcastu mają bycie Scrum Masterem za sobą. Znają każdy szczegół tej roli. Na pewno będę Was słuchać 😊👍

  2. Ania

    Dziękuję za ten podcast. Uwielbiam Was czytać, teraz mogę też posłuchać. Rozmowa bardzo dobrze „płynęła”, nie było przestojów, temat się naturalnie logicznie rozwijał – same plusy! Poza tym macie bardzo fajne, radiowe głosy – co jest niebagatelne przy tego rodzaju przedsięwzięciach – bardzo dobrze się Was słucha 🙂
    Byłabym wdzięczna, gdybyście w jednym z nagrań rozwinęli nieco temat „nie-agile’owych” stakeholderów. W mojej pracy dość często spotykam się z osobami, które może i chciałyby wprowadzać zmianę podejścia, ale są tak przywiązane do waterfalla, że w kółko rodzą się potworki typu „półroczny sprint”… Jak rozmawiać z menadżerami, którzy nie mają pojęcia o agile’u? Gdzie zacząć? Jak nie zniechęcić na dzień dobry do słusznej, ale (w porównaniu do waterfalla) dość trudnej drogi wymagającej jednak poprzestawiania sobie pewnych zapadek w wypracowanych nawykach?
    Dziękuję i pozdrawiam,
    Ania

    • Kuba

      Dzięki za propozycje i za feedback Ania (zwłaszcza ten o radiowych głosach ;). Faktycznie temat rozmawiania z niezwinnymi menedżerami to coś trudnego i wartego przegadania. Wrzucamy sobie na listę propozycji tematów.
      Pozdrawiam,
      Kuba

  3. Katarzyna

    Ogromna wdzięczność za ten podcast – po kilku miesiącach pracy w roli SM (nie technicznego, bez doświadczenie w IT, wcześniej coach, trener) i początkowym zachwycie rolą ( w kontekście jak łatwo pracuje mi się procesowo), „dziś” zaczęłam mieć coraz więcej wątpliwości – czy sama wiem, jak w tej roli się odnaleźć. Największą trudnością było to, ze z początkowo dwóch osób w tej roli, nagle zostałam sama na poziomie firmie, więc pole wymiany zostało ograniczone do społeczności. Na szczęście pojawił się drugi SM, z innym podejściem nieco do roli, niż ja i widzę, jaką wartość ma taka wymiana. Jednocześnie, zawsze, gdy szukam odpowiedzi, zaglądam na Agile247 lub do Labiryntów Scruma (które jednak nieco w niektórych aspektach mój nietechniczny umysł przerastają :), jednak w połączeniu z tym podcastem, czuję że znów mi łatwiej wrócić na właściwe tory…czyli wiem, który obszar mam zaniedbany, czy to, że czasem i SM do zespołu nie pasuje – bo widzę, jak różne są energie spotkań w różnych zespołach. Dziękuję i z chęcią posłucham więcej 🙂

  4. MaciekU

    Fajne! Propsuję i czekam na więcej. Podoba mi się, że podchodzić do tego, jak do budowania produków – bardzo fajnie. Dla mnie personalnie 30 minut podcastu to idealnie, ale może dlatego, że droga do pracy tyle mi zajmuje :).
    Czekam na #002 – Kto to jest Agile Coach i czym się zajmuje? 🙂

    • Kuba

      Maciek, że tak będzie brzmiał tytuł #002 to nie mogę obiecać, a wręcz jestem pewien, że szykuję się raczej temat rozwijania się jako Scrum Master. Ale temat roli Agile Coacha jest również niezwykle ciekawy, gdybyś nie mógł się doczekać materiału od nas, w tej tematyce często piszę na swoim blogu http://www.kubaszczepanik.pl/tag/agile-coach/ .

      Pozdrawiam i dzięki za feedback co do długości odcinka, rozważymy.

  5. Martyna

    Dzięki za podcast. To super móc Was posłuchac, w szczególności że nie jest to mowa o teorii tylko praktyce. Już nie mogę doczekać sie kolejnego odcinka 🙂 Ciężko mi było wygospodarować aż 50min. Też uważam że 30min byłoby akurat. Wolałabym również posłuchać nagranie z ogólnodostępnych narzędzi. Tutaj musiałam instalować apkę i się logować. Powodzenia w przedsięwzięciu!

    • Kuba

      Dzięki Martyna za komentarz, długość odcinka przewija się w komentarzach po tym pierwszym i rozważymy co możemy z tym zrobić. Żeby zmieścić w jednym odcinku zarówno teorię (wytłumaczoną konkretnie) jak i praktykę i dać powiedzieć obu z nas co myślimy jednak potrzebujemy trochę czasu. Niektóre tematy zmieścimy w czasie krótszym, inne pewnie będą jednak potrzebowały podobnej długości do pierwszego.

      Co do narzędzi – będziemy to poszerzać. Jest z tym trochę roboty organizacyjnej, procesy weryfikacyjne przez niektóre kanały trwają. Chcieliśmy zacząć od części możliwych sposobów dotarcia (w imię MVP) i poszerzać je z czasem. Jakiego narzędzia Ty używasz do słuchania podcastów (jakiego nam zabrakło, by było Tobie wygodnie)?

  6. Ewa

    Jacek, Kuba – dobrze się Was słucha. Opowiadacie prawdziwe historie z inteligentnym komentarzem. Dołączam Wasz podcast do regularnie słuchanych.

    Duży plus dla Was za podkreślenie jak ważne dla Scrum Mastera jest jawne skomunikowanie intencji swoich działań. Jeszcze większy plus za podkreślenie szybkiej korekty jaką Scrum Master może wtedy od zespołu uzyskać.

    Polecam ten odcinek do posłuchania Scrum Masterom, z którymi pracuję.
    Dzięki za wartościowy materiał

    • Kuba

      Dziękujemy Ewa, ważne docenienie dla nas i przydatne, że podzieliłaś się szczegółami co Tobie się podoba – będziemy kontynuować formę w kolejnych odcinkach 🙂

      Pozdrawiam,
      Kuba

Pozostaw odpowiedź MaciekU Anuluj pisanie odpowiedzi

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

Jesteśmy też tutaj

Podcast od kuchni. Tak nagrywamy dla Ciebie!

Jacek Wieczorek i Kuba Szczepanik
scenariusz do nagrania podcastu
Jacek Wieczorek Kuba Szczepanik podcast

Opinie naszych słuchaczy.

„To jest to! Ekstremalnie dobra dawka potrzebnej wiedzy. Część podcastów otwiera oczy, część porządkuje wiedzę. Polecam!”

„Mimo iż nie jestem bardzo związany z agilem/scrumem, jakieś doświadczenia z nim miałem („retrożale” ;), to bardzo przyjemnie się Panów słucha. Duża i bardzo konkretna dawka wiedzy, bez przynudzania, widać „napracowanie” przy każdym odcinku, jakość ścieżki audio na poziomie, całość w odbiorze sprawia profesjonalne wrażenie. Życzę obu prowadzącym sił do kontunuowania tego (nie)małego dzieła. :)”.

„Takich podcastów nam potrzeba!”

Oceń Podcast. Kliknij poniżej.

Apple Podcast logo
logo stitcher
Wordpress Social Share Plugin powered by Ultimatelysocial