21 sierpnia 2019Scrum

Mity Scruma

Scrum jest prosty, ale bywa mylnie rozumiany. Na bazie informacji od słuchaczy wyselekcjonowaliśmy 5 najpopularniejszych mitów, nad którymi pochylamy się w tym odcinku.

Zobacz wersję wideo

Dodatkowe materiały

Transkrypcja podcastu „Mity Scruma”

Kuba: W dzisiejszym odcinku chcielibyśmy kontynuować mini-cykl, który zapoczątkowaliśmy w odcinku siedemnastym, czyli „mity”. Tym razem – spośród listy rzeczy zgłoszonych przez naszych słuchaczy na naszą prośbę – wybraliśmy mity związane ściśle z frameworkiem scrumowym. Wybraliśmy pięć mitów scrumowych, które po kolei przytoczymy, wspomnimy, kto je zgłosił i trochę o nich opowiemy.

Jacek: Pierwszy mit, który chcielibyśmy dzisiaj rozwiać, brzmi: „Myślenie o Sprincie jako o fazie waterfalla, tylko z inną etykietką”. Jest to mit zgłoszony przez Jakuba. Jak rozumiemy ten mit? Wyobraźmy sobie, że rozwijamy jakiś produkt, realizujemy jakiś projekt, realizujemy jakąś inicjatywę i postępujemy takim bardzo klasycznym sposobem, czyli najpierw jest jakaś analiza, jakieś projektowanie – to są takie fazy, które toczą się gdzieś tam, nie wiadomo gdzie, ale na pewno poza Zespołem Deweloperskim i w momencie kiedy specyfikacja naszego rozwiązania jest gotowa, jest podpisana, jest zatwierdzona przez wszystkie ważne osoby w procesie…

Kuba: I może nawet jeszcze architektura jest już rozpisana. I całe rozwiązanie jest zaplanowane.

Jacek: Czyli wszystko jest bardzo dobrze przygotowane, no to wtedy pojawia się zespół, wtedy się pojawia Scrum, i tak naprawdę ten Scrum jest pewną fazą wytwarzania, natomiast, no, absolutnie umocowaną w procesie waterfallowym. No i jeśliby się zastanowić nad tym mitem, no to tak, po pierwsze: absolutnie nie jest tak, że Scrum jest tylko etapem pracy w waterfallu. Idąc dalej, takie podejście do wykorzystania Scruma, no to jest jak kupić samochód wyścigowy, no i próbować nim jeździć po lesie – tak naprawdę nie będzie z tego żadnego sensownego efektu, a tylko będziemy mogli sobie zrobić krzywdę.

Kuba: Rozsupłując tą twoją metaforę, chodzi o to, że mamy podejście, które umożliwia elastyczność, kreatywność, wymyślanie jak najszybszych i wartościowych rozwiązań na wskazany problem – i odbieramy sobie tą możliwość, ponieważ zespołowi jest zlecany szczegółowy zakres, nie ma więcej pytań, ma być po prostu to precyzyjnie wykonane. W ogóle nie dajemy okazji, żeby wykorzystać potencjał zespołu, tylko sprowadzamy Scrum jako metodę kontroli zespołu.

Jacek: Tak.

Kuba: Smutna rzeczywistość – bywa tak w firmach, ale to jest zdecydowanie mit i niewłaściwe wykorzystanie Scruma.

Jacek: Bardzo popularnym określeniem, które możesz spotkać w kontekście tego, o czym teraz opowiadamy, jest pojęcie Water-Scrum-Fall, gdzie tak naprawdę Scrum jest tylko pewnym elementem – tak jak, Kuba, powiedziałeś – takim pewnym uproszczeniem, często narzędziem kontroli, a przede wszystkim narzędziem, które tak zastosowane sprowadza zespół do takiej roli mocno podwykonawczej, gdzie po prostu mają za zadanie w pewnych iteracjach dostarczać wymagania, które zostały zdefiniowane. I, no, taka historia, którą ostatnio doświadczyłem – pracując z jedną z firm – było… sytuacja, w której Zespół Deweloperski otrzymał specyfikację. Ta specyfikacja była wytwarzana wcześniej przez… no, dobrych kilka miesięcy. Zespół dostał tą specyfikację i kiedy zapytałem jednego z Deweloperów, jak im idzie praca, na ile ten dokument jest dla nich przydatny, no to ten Deweloper się tylko uśmiechnął i powiedział: „3/4 tej analizy poszła do kosza”, ponieważ dopiero jak rozpoczęli faktyczną pracę, no to zaczęli natrafiać na problemy, których nikt wcześniej z wyprzedzeniem nie przewidział. No i to jest przykład na to, że de facto pewnego rodzaju marnotrawstwem jest taka „nadprodukcja” i stosowanie tylko Scruma, jako narzędzia, żeby je wykonać czy dostarczyć.

Kuba: I to, co wspomniałeś, to jest klasyk tego zjawiska – próby rozwiązywania złożonego problemu. Tego nie zaplanujemy, mocno o tym już mówiliśmy w odcinku siedemnastym, który – jak zwykle – zalinkujemy w opisie odcinka.

Jacek: Dobrze.

Kuba: Drugim mitem scrumowym, który wybraliśmy, jest mit zgłoszony przez Krystiana: „W Scrumie nie ma roadmapy”. I faktycznie rozumiem, z czego taki mit może wynikać, bo jeślibyśmy wrócili do „Przewodnika po Scrumie”, to faktycznie tam raczej słowo „roadmapa” nie jest zbytnio widoczne, a też takie zapalczywe, wczesne podejście do Scruma – zwłaszcza jako alternatywy do waterfalla – no to będzie takie podejście: „No, mamy Backlog” czyli: mamy wszystko, nic więcej nie musimy planować, nic nie musimy nigdzie nikomu raportować, po prostu musimy rozpocząć prace i nasz Backlog jest naszym planem czy naszą drogą, a przyrosty będą się broniły same i nic więcej nie trzeba tworzyć ani produkować.

[śmiech]

Jacek: Tak, no, tak uśmiechnąłem się trochę, bo dosłownie jakbym już słyszał taką rozmowę czy takie wypowiedzi, natomiast z mojej perspektywy ten mit bardzo często jest furtką i dla osób z biznesu, i dla osób z Zespołu Scrumowego, i dla Product Ownera, który pozwala myśleć, że tak naprawdę nie muszę mieć żadnych długofalowych planów – no bo, tak jak mówisz, wystarczy, że mam Backlog, no i w sumie wszystko jest jasne. Natomiast z mojej perspektywy, niewykonanie tego ćwiczenia pod tytułem: „Zastanówmy się, gdzie chcemy być, powiedzmy, pół roku od dzisiaj czy rok od dzisiaj”, jest bardzo istotne i nawet jeśli te plany się, czy ta roadmapa nasza się zmieni, no to samo to takie ćwiczenie, gdzie się zastanowimy w sumie, co chcemy osiągnąć, jaki jest cel, gdzie chcemy być, jakim sposobem, jest bardzo fajnym ćwiczeniem, takim umysłowym, z którego rezygnowanie w myśl tego mitu, że przecież to jest Scrum i nie ma roadmapy, no, jest, uważam, z bardzo dużą szkodą dla rozwoju produktu.

Kuba: Klucz może być w tym, jak sprawni jesteśmy w tworzeniu roadmapy i klucz może być też w tym, jak dużo czasu na to poświęcamy. No i pewnie ostatnia rzecz, jak kto rozumie to, co w takiej ewentualnej stworzonej roadmapie będzie interpretował. Na pewno roadmapa nie jest żadną obietnicą, roadmapa jest raczej przybliżeniem czy naszym wyobrażeniem pewnych kolejnych kroków, które chcemy wytworzyć w naszym produkcie czy zrobić w kolejnych jakichś większych etapach. No i to jest tylko tyle i aż tyle. To jest pewna wizja działania i pewna nasza wizja czy pomysł na nasz produkt w kolejnych krokach, ale na pewno to nie jest żadna obietnica, nie daj Boże, żadne zobowiązanie do zrealizowania jakiegoś konkretnego zakresu.

Jacek: Tak, z mojej perspektywy tego… ogólnie tego planowania na różnych poziomach w podejściu zwinnym, ale także w Scrumie, jest bardzo dużo, tak więc to planowanie może być i na poziomie planu nadchodzącego Sprintu, to może być – skracając to okienko planowania – to może być plan aktualizowany na codziennym Scrumie, gdzie tak naprawdę planujemy na najbliższe 24 godziny. To może być z kolei plan w dłuższej perspektywie, gdzie zastanawiamy się nad jakimś release’em, milestone’em, nad jakimś kwartałem, no, ale możemy też wyjść dalej i te nasze roadmapy ustawiać np. w perspektywie rocznej. To, co jest istotne, to to, co już wspomniałeś, że byłbym bardzo ostrożny z traktowaniem roadmapy jako narzędzia takiego, gdzie konkretne feature’y są „wyryte w kamieniu” i ta roadmapa staje się narzędziem opresji dla zespołu. Trudno oczekiwać, że Zespołu Scrumowe, które zwykle pracują w złożonym środowisku, będą w stanie obiecać, że ten konkretny feature będzie dostępny za siedem i pół miesiąca. Z mojej perspektywy jest to bardzo trudne w praktyce do wykonania.

Kuba: Ciekawą alternatywą do takich roadmap opartych o feature’y są roadmapy oparte na celach, czyli rezultatach jakichś biznesowych czy jakichś wskaźnikach, które chcemy zrealizować, być może jakichś wskaźnikach, które chcemy w ogóle umożliwić – szczególnie naszym klientom czy naszym partnerom biznesowym – no i to jest taka roadmapa, która bardziej mówi nie, że do naszego produktu dokładamy trzy nowe zakładki, a czwartą przebudowujemy w całości, tylko że roadmapa, która mówi: „W najbliższym kwartale chcemy się skupić na tym, żeby danemu typowi użytkownika poprawić, nie wiem, docieralność do ostatniego kroku w naszym procesie, a potem przerzucimy się na pousuwanie jakichś niedoskonałości zabezpieczeń, a dopiero na końcu będziemy się skupiać na trzecim typie użytkownika, który jest dla nas najmniej priorytetowym i póki co, póki nie rozwiążemy tych poprzednich rzeczy, to nie będziemy realizować nic dla tego ostatniego.

Jacek: Tak, tak więc te roadmapy – czy w takim klasycznym ujęciu feature’woym czy w takim ujęciu, o którym przed chwilą powiedziałeś – z mojej perspektywy są bardzo ważnym kierunkowskazem dla Zespołów Deweloperskich, które dają kontekst też po co pewne rzeczy robimy, w którą stronę idziemy, no i też dają Zespołowi Deweloperskiemu możliwość współkreowania tego produktu, jeżeli oczywiście mają ku temu kompetencje i odpowiednio stworzoną przestrzeń.

Kuba: I tu mi się przypomina taki przykład à propos współkreowania, bo to może być współkreowanie na zasadzie: „Słuchajcie, mam świetny pomysł, jak zrobić nowe rozwiązanie w koszyku naszego sklepu”, ale sam byłem też świadkiem, i to dosłownie w zespole, który zajmował się sklepami, gdzie jak usłyszeli od Product Ownera, że naszym celem przez jakiś najbliższy czas jest zwiększenie ilości transakcji w naszym systemie o „X” i te „X” było bardzo dużą liczbą jak na realia tego zespołu, no to nagle się programiści złapali za głowę – „Nasz system nie będzie w stanie unieść tego nowego ruchu”, więc jeśli naszym celem biznesowym jest zwiększyć transakcyjność, to – oprócz tych nowych rozwiązań biznesowych, które będą atrakcyjne dla klienta – niezbędnym elementem składowym na poziomie rozwiązania jest również poprawić miejsca, w których po prostu się nie skaluje nasz system czy ma słabą wydajność, bo po prostu nie zrealizujemy celu biznesowego „wzrostu o X” bez zmian na poziomie technologicznym.

Jacek: Trzecim mitem scrumowym, o którym chcieliśmy dzisiaj porozmawiać, jest mit, który brzmi: „Na planowaniu zespół zobowiązuje się dowieźć wszystko”, czyli dowieźć cały zakres. Jest to mit zgłoszony również przez Krystiana, no i z mojej perspektywy jest to mit bardzo często obserwowany przeze mnie w trakcie planowań Zespołów Scrumowych, gdzie zwykle Product Owner bądź czasem jacyś stakeholderzy, managerowie, którzy również znajdują się na tym planowaniu – bardzo precyzyjnie pilnują tego momentu, kiedy zespół obiecuje czy zapewnia wszystkich zebranych, że: „Tak, te tutaj sześć, siedem, dwanaście elementów z Backlogu, które przesunęliśmy z Backlogu Produktu do Backlogu Sprintu, to jest dokładnie ten konkretny zakres, który chcemy dowieźć czy dostarczyć”, no i teraz, niedostarczenie nawet jednego z tych elementów oznacza porażkę.

Kuba: Porażkę, kłopot.

Jacek: Problem.

Kuba: Wstyd, jakkolwiek byśmy na to…

Jacek: Coś na czerwono będzie.

Kuba: Tak.

[śmiech]

Kuba: Jakiś procent się nie wyliczy do równego stu. No, zdecydowanie jest to mit, w tym sensie, że już – na razie przynajmniej, póki co – jak przybliżałeś tą historię, nie ma słowa o Celu Sprintu, no i warto sobie w tym miejscu przypomnieć tą istotność celu. To jest to, do czego dążymy i to jest to, co powinniśmy realizować, natomiast zakres realizowanych prac to jest prognoza. Może nam się pomysł na zakres zmienić, może wpadniemy na zupełnie nowe rozwiązania – szereg rzeczy, szereg korzyści z właściwego zastosowania celu sprintu wspomnieliśmy Tobie w nagraniu numer 7, w odcinku „Cel Sprintu”, do którego również zachęcamy, nie będziemy się powtarzać w tym nagraniu, warto odsłuchać cały odcinek o Celu Sprintu.

Jacek: No generalnie mi też trudno jest, znaczy… rozumiem niełatwą sytuację Zespołu Deweloperskiego, który znając całą złożoność produktu – często to są jakieś lata utrzymywania systemu, a osoby, które pisały ten system już nie pracują, zaciągnięty dług technologiczny, często brak odpowiedniej wiedzy biznesowej, często te elementy Backlogu Produktu nie są dostatecznie dobrze omówione, przygotowane czy właściciel produktu nie jest dostępny – albo stakeholderzy – żeby zadać jakieś pytanie. No to w tak wykreowanych warunkach trudno oczekiwać, że ktoś krwią się podpisze i obieca, że: „Tak, te konkretne rzeczy w tak konkretnie zdefiniowanym zakresie zostaną zrealizowane”. Po to mamy Cel Sprintu, po to zespół ze sobą rozmawia, po to mamy codziennego Scruma, no, żeby z tą złożonością sobie radzić, ale na pewno nie jest tak, że Scrum to jest świetne narzędzie Project Managementowe, które zapewnia, że jak zespół powie, że dostarczy „A”, to na koniec Sprintu dostarcza „A”, jakby tutaj, no, widziałem wiele zawiedzionych osób, które po takiej dłuższej dyskusji rozgraniczającej czym jest Prognoza Sprintu a czym jest ten taki… „commitment” czy zobowiązanie często źle rozumiane, no, robiły się „usta w podkówkę” na zasadzie, że: „Tak w sumie to takie było główne oczekiwanie, że ten Scrum to jest takie 100% delivery, coś takiego, co zapewnia”. No niestety, ze smutkiem musimy stwierdzić, że tak niewątpliwie nie jest.

Kuba: I teraz sobie trochę żartujemy o tym smutku, ale jest bardzo konkretna negatywna konsekwencja forsowania tego mitu, że zespół musi dostarczyć 100% zakresu, oczywiście zespół znajdzie sposób na dostarczenie 100% zakresu, bardzo obniżając sobie poprzeczkę tego, ile jesteśmy w stanie zrealizować w Sprincie biorąc rzeczy do Spritu z bardzo dużym zapasem wolnego miejsca, buforem na ewentualne niepowodzenia. No i jeśli…

Jacek: Obniżając jakość.

Kuba: Obniżając jakość, też znajdując sobie dużo problemów, których wcale nie powinni sobie znajdować. No i, w dużym skrócie, jeśli Zespoły Scrumowe konsekwentnie Sprint w Sprint realizują 100% zakresu, to mnie nie się akurat…

Jacek: …zapala lampka.

Kuba: Zapala lampka ostrzegawcza: ktoś tu albo fałszuje wyniki, albo naprawdę pracuje w superbezpiecznym trybie, bo boi się konsekwencji zrealizowania, nie wiem, 80% przewidywanego zakresu. Skupmy się na tym, żeby była realizowana wartość, żeby były realizowane usprawnienia co Sprint, a nie na tym, żeby na zielono się świeciła jakaś miara „cały Sprint dowieziony”.

Kuba: Czwartym mitem, który opowiemy w tym odcinku jest mit zgłoszony przez Jacka, ale nie Jacka Wieczorka, tylko Jacka, naszego słuchacza. Mit brzmi: „Jeżeli codzienne spotkanie trwa 15 minut i 10 sekund, to już nie jest Scrum”. Rozszerzę to, bo tutaj jest konkretny przypadek przekroczenia timeboxu o 1% przewidywanego czasu. Ja bym to rozszerzył na jakiekolwiek postrzegania Scruma w taki sposób, który ja nazywam „aptekarstwem”, czyli przekroczenie timeboxa choć o minimalny czas czy naruszenie jakiejś szczegółowej zasady faktycznie funkcjonującej w Scrumie, powoduje, że cała reszta wysiłku – jeśli byśmy Scruma sprowadzili, nie wiem, do stu czynników, no to mamy 99, ale nie mamy tego jednego i on nie jest może jakiś taki superkluczowy, ale to już wtedy nie mamy Scruma, czyli takie postawienie sobie sprawy, że „albo czysty Scrum, który dostanie pieczęć Jeffa Sutherlanda i Kena Schwabera, albo to nie jest w ogóle Scrum”.

Jacek: Tak. No i tu… ja – znów, z doświadczenia – wielokrotnie byłem sytuacji, w której toczy się jakaś interesująca dyskusja w zespole, powiedzmy na Planowaniu Sprintu czy na Retrospektywie. Scrum Master nerwowo spogląda na zegarek, no i wybija 14, spotkanie się kończy i Scrum Master zaczyna przerywać, „koniec”, „timebox”. Ktoś tam z zespołu mówi, nieśmiało, że: „Ale przecież to jest ważny temat”. No i tu pada: „Nie, w Scrumie są timeboxy, musimy skończyć, dokończycie kiedy indziej”. No nie.

Kuba: Tak. I tu jest dyskusyjny punkt, bo z jednej strony uważamy takie aptekarstwo w przestrzeganiu reguł Scruma, dosłownie co do milimetra, co do sekundy, minuty czy tam… jednego z czynniku spośród setki – to jest dla nas mit. W sensie, faktycznie, Scrum to Scrum, czyli potrzebne są wszystkie elementy, natomiast dołóżmy do tego taki aspekt…

Jacek: Zdrowy rozsądek.

Kuba: Zdroworozsądkowego, nie wiem, uczenia się Scruma, pewnej drogi w stronę coraz lepszego Scruma, czyli: wycinkowo może to nie jest jeszcze Scrum, ale staramy się, żeby to Scrum był, ciągle się usprawniamy, coraz lepsi jesteśmy, więc nawet jeśli Daily jeszcze nam nie wychodzi w równo 15 minut, ale wiemy, że nam przeszkadza, albo Retrospektywa nie zawsze będzie superudana i np. z danej Retrospektywy niestety nie udaje się nam jakiegoś jednego co najmniej usprawnienia ustalić, no to z tego powodu, że nam jedna Retrospektywa nie wyszła, nie mamy Scruma, czy może jednak mamy, tylko nie zawsze nam wychodzi dobre jego zastosowanie.

Jacek: To, co z mojej perspektywy jest istotne, jeśli chodzi o konkretnie tutaj, o timeboxy, to jest też zrozumienie, dlaczego tak naprawdę stosujemy timeboxy, jakby… do czego służy nam to narzędzie, co chcemy uzyskać przez to, że nałożymy sobie pewne ograniczenie czasowe i jeśli poczytamy „Przewodnik po Scrumie”, czyli popularnego „Scrum Guide’a”, to oczywiście tam te timeboxy są precyzyjnie określone, czyli: planning trwa ileś czasu dla miesięcznego Sprintu, natomiast dla krótszych Sprintów jest odpowiednio krótszy, tak więc jakby, no, to na co chciałbym tutaj zwrócić uwagę to to, że bardzo łatwo jest wpaść w taką pułapkę, że tutaj dłuższe Daily, tutaj planowanie zrobimy po swojemu, a tu z Retro przecież nie trzeba wyjść z usprawnieniem, no i zaraz się okaże, że taka suma małych odejść spowoduje taką erozję frameworka, że tak naprawdę nic z niego nie zostanie, no i obudzimy się w rzeczywistości, w której w sumie to można wszystko, tak więc tak naprawdę nic nas nie ogranicza.

Kuba: No i to zdecydowanie nie jest coś, co byśmy chcieli w tym odcinku przekazać. Mitem jest aptekarskie, szczegółowe takie zasłanianie się jakimiś precyzyjnymi wytycznymi, ale nie pozwólmy sobie, żeby w imię stwierdzenia „Ha, to jest mit” po prostu Scruma mieć w 1/3 albo ze Scruma mieć Daily Scruma, a całą resztę nie mieć. Więc zdecydowanie tutaj jest coś bardzo zniuansowanego, czego pewnie w ramach tego odcinka w całości nie jesteśmy w stanie pokryć. Ostatnim mitem, który chcemy wymienić w tym odcinku, jest mit również zgłoszony przez Krystiana, który jest naszym małym sponsorem merytorycznym tego odcinka. To mit: „Scrum Master zarządza zadaniami zespołu i jest interfejsem do zespołu”. To jest mit, on nawet ma w sumie dwie składowe – jest jednocześnie dosyć niebezpiecznym antywzorcem, ale zacznijmy od tej części mitowej. No, tutaj parafrazując to stwierdzenie ze strony Krystiana, faktycznie spotyka się, głównie pewnie managerów, którzy oczekują, że Scrum Master będzie jakimś takim „ukrytym” koordynatorem, tak: „Wiecie, wiecie, coaching” i lekkie mrugnięcie okiem, „lider służebny”, drugie mrugnięcie okiem. „No, ale ktoś musi przypilnować, ktoś musi zapanować, ktoś musi zorganizować – przecież nasi ludzie są tacy” albo „w tym zespole to inaczej się nie da”, no i oczekuje się czy interpretuje się czy się tak rozumie, że „Dobra, dobra”, ale tak naprawdę chodzi o to, że Scrum Master jednak jest tym zarządzającym, koordynatorem, liderem, mini-szefem, jakkolwiek go rozumiemy. No i jest też ta druga perspektywa, no to skoro już tak ładnie wypełnia tą rolę lidera, no to przy okazji jest też interfejsem, czyli jeśli chcę coś od zespołu, to sobie idę załatwić u Scrum Mastera. Jeśli chcę się dowiedzieć, jak w zespole funkcjonuje, to też Scrum Master jest wezwany na dywanik albo wezwany na jakąś tam rozmowę 1:1, żeby opowiedział, co tam w zespole się dzieje.

Jacek: Tak, czyli Scrum Master staje się odbiorcą zarówno pochwał, jak i też odbiorcą nagan i kar, no jego zadaniem jest jak gdyby – w tym micie, oczywiście – przekazywanie tego dalej do zespołu. No, popularny mit, w sumie to… kolejność jego wymienienia nie ma znaczenia, ale bardzo często obserwuję sprowadzanie Scrum Mastera bądź do zarządcy, bądź do jakiegoś tam interfejsu, no, co uważam, że absolutnie jest błędne. Odpowiedzialność Scrum Mastera jest zdefiniowana, ona jest zupełnie inna. To jest wspieranie pracy Zespołu Deweloperskiego, wspieranie właściciela produktu i praca z organizacją. Z mojej perspektywy, wchodzenie w taką rolę zarządcy bądź w rolę takiego interfejsu, stoi w sprzeczności z tą pierwszą odpowiedzialnością Scrum Mastera, czyli to nie jest wspieranie pracy zespołu, moim zdaniem to jest działanie na szkodę. Tak więc więcej problemów z tego będzie niż pożytku tak naprawdę.

Kuba: I jakie mogą być z tego problemy to to, że jeśli Scrum Master nawet by się zachowywał – a nawet jeśli tylko wszyscy myślą, że powinien się tak zachowywać jak koordynator – no to natychmiast cała reszta zespołu będzie się odpowiednio zachowywać czy reagować na takie prace koordynacyjne, czyli Scrum Master nas pyta coachingowo, ale my wiemy, że on jest liderem, więc tak naprawdę to słyszymy podprogowo jakąś sugestię, być może jakoś zaczynamy się chować, kryć – albo wręcz odwrotnie, tak pod tego Scrum Mastera grać, się pokazywać. No bo on za chwilę pójdzie z tą informacją do szefa i powie, kto w naszym zespole jest najlepszy, bardziej pracowity, lepiej komunikatywny. Czyli wszystkie te reguły takiego zaufania, których Scrum Master potrzebuje, żeby dobrze funkcjonować w zespole, zostają naruszane, bo zaczynamy się zachowywać dziwnie, sztucznie, panuje między nami jakiś dodatkowy czynnik, który powoduje, że zamiast efektywnie, bezpośrednio, fajnie współpracować, to zaczynamy coś kombinować. Albo Scrum Master sili się na koordynowanie, mimo że nikt od niego tego w zespole nie oczekuje. Albo odwrotnie – wszyscy w zespole myślą, że no to Scrum Master faktycznie jest od tej koordynacji, no to niech on już tam sprawy załatwi. I kompletnie zanika nam samoorganizacja, a przy okazji niestety, ale kompromitujemy też wartości, które w Scrumie też są niezbędne i konkretnie dookreślone.

Jacek: I generalnie myślę, że warto tutaj przy okazji tego mitu wspomnieć czy podzielić się taką wskazówką – jeżeli bierzesz udział w rekrutacji na stanowisko Scrum Mastera, to mając świadomość tego mitu, możesz poeksplorować temat kogo spodziewa się otrzymać organizacja, rekrutując Scrum Mastera. Często to widać już po ogłoszeniu, że tak naprawdę poszukiwany jest Project Manger, a nie Scrum Master. Czasem jest to dobrze zamaskowane, natomiast pogłębiające pytania w trakcie takiej rozmowy rekrutacyjnej, jak firma rozumie tą rolę Scrum Mastera, no, może dać dużo odpowiedzi i też uchronić nas przed dołączeniem do firmy, która szuka zarządcy, a nie osobę, która będzie pracowała nad zwinnością w firmie. Więcej o tym, dlaczego nie warto robić ze Scrum Mastera pośrednika i dlaczego wręcz nie powinien Scrum Master być pośrednikiem, znajdziecie w artykule Kuby, do którego podlinkujemy w notatkach do tego odcinka.

Kuba: Natomiast jeśli chcesz wiedzieć więcej na temat tego, co robi Scrum Master, no to akurat ten temat poruszyliśmy w pierwszym odcinku naszego podcastu, który również mocno polecamy, bo tam idziemy nie perspektywą mitu, kim Scrum Master nie jest, tylko perspektywą, jakie ma swoje zadania i – na przykładach – jak je realizuje.

Jacek: Jeżeli chciałbyś, bądź chciałabyś, pogłębić temat pułapek, mitów i antywzorców w Scrumie, to zapraszam Cię 23. i 24. września do Warszawy na autorski warsztat na bazie mojej książki. Będzie to warsztat „Labirynty Scruma” i będą to dwa dni, podczas których skupimy się na praktycznym rozwiązywaniu pułapek w Scrumie. Zapraszam i do zobaczenia.

Kuba: Link do tego warsztatu i zapisu znajdziesz również w opisie. A ja ze swojej strony zapraszam na „Agile by Example”. Wydarzenie, cała konferencja będzie między 21. a 23. października, natomiast w tym roku będę w programie warsztatów i chcę przekazać materiał unikalny, do tej pory jeszcze nierealizowany, chciałbym podzielić się swoimi doświadczeniami w wykorzystaniu zwinnego podejścia w świecie poza IT. I konkretnie tutaj wybrałem taki aspekt dzielenia produktu – definiowania i dzielenia produktu – w realiach poza IT. Myślę, że będzie to ciekawy warsztat do tego, żeby popracować. Nie kojarzę, żeby taki materiał w ogóle był gdziekolwiek dostępny, więc jeśli w ogóle masz coś wspólnego z podejściem Agile poza IT, to nawet już dla samego tego faktu zapraszam na to wydarzenie, jak i na całą konferencję, na którą siłą rzeczy… będę w niej uczestniczył.