Kult cargo w Scrumie

Kult cargo w Scrumie może być niebezpieczny. Zespoły naśladują wiernie inne zespoły scrumowe. Ślepo wierzą bardziej doświadczonej osobie, że stosowane i rekomendowane przez nią metody działają zawsze i wszędzie najlepiej. Wcale tak nie musi być. Z racji mniejszego doświadczenia masz obawę przed spróbowaniem czegoś innego? Wyjaśniamy, z czego może wynikać kult cargo w Scrumie i co można zrobić, żeby nie paść jego ofiarą.

Co poruszamy w tym materiale?

Czym jest kult cargo? 

Kult cargo to pojęcie z antropologii opisujące wierzenia i zachowania występujące wśród plemion zamieszkujących wyspy Melanezji. Plemiona te, pierwotnie nieznające cywilizacji, zaczęły imitować zachowania i sposób ubierania lotników, którzy założyli bazę na ich wyspie. Tubylcy zaczęli tworzyć budowle, nabrzeża dla okrętów i lotniska imitujące te z nowoczesnego świata. Oczywiście robili to posługując się dostępnymi im materiałami jak np. gałęzie, palmy, czy liście. Miało to sprawić, że spłyną do nich dobra z tego cywilizowanego świata.  

Kult cargo to przekonanie o tym, że jeśli będziemy wykonywać te czynności, które sprawiają, że u kogoś pojawiają się dobra, to te dobra się u nas również pojawią. Stanie się tak, bo zaobserwowaliśmy to zjawisko, chcemy żeby się powtórzyło i go potrzebujemy. Co ważne – imitowane są zachowania, na poziomie zrozumienia danego wykonawcy.

Mimo że jest to pojęcie przypisywane pierwotnym plemionom i brak mu racjonalności, to przenosi się ono także do codziennego życia biznesowego. Pojęciem tym opisujemy szereg zachowań, które powodują, że realizowane jest coś powierzchownie i imitowane są pewne praktyki. Pojawia się wiara, że to wystarczy, aby uzyskać dobre wyniki i oczekiwane korzyści. 

Pułapka jest w tym, że kopiowane są czyjeś działania, opierając się jedynie na wierze, że to działa. Imitator nie ma wiedzy i nie sprawdza, czy tak faktycznie jest.  

Kult cargo w Scrumie – konkretne przykłady

Kult cargo widoczny jest również w Scrumie, co pokażemy Ci na pięciu przykładach. Nie mamy intencji krytykowania tych praktyk. Chcemy tylko zwrócić Twoją uwagę, na to, że warto poddawać refleksji rzeczy, które robią różne zespoły.

1. “Ładne” wykresy spalania (tzw. burndowny) – wiele zespołów bardzo dba o to, aby były one idealnie równo spadające przez cały Sprint. Dzieje się tak dlatego, że ich członkowie wierzą, że to zapewni im regularne dostarczanie. 
2. Trzymanie się formatu User Stories w Backlogu Produktu – stoi za tym wiara, że format ten zapewni, że tworzony przez nas produkt, będzie wartościowy dla użytkownika.
3. Story pointy jako jedyna wersja wyceniania pracy – spowodowane jest to wiarą, że Story pointy prowadzą zespół do trafnych estymat i pozwalają na bardzo przewidywalne dostarczanie. 
4. 3 pytania na Daily Scrum lub Stand-upach – jeżeli wszystkie osoby z zespołu odpowiedzą na każdym spotkaniu na 3 pytania, które są sugerowane we wcześniejszych wersjach „Przewodnika po Scrumie”, to zapewniona będzie dobra komunikacja.
5. Kurczowe trzymanie się konkretnej techniki Retrospektywy Sprintu – Każde „retro” jest identycznie prowadzone i nie ma zbyt wielu usprawnień. Stoi za tym wiara, że to pozwoli na bycie lepszym, usprawniającym się zespołem. 

Powtórzymy, że nie jest naszym celem krytykowanie złego doboru pewnych praktyk. My sami też się czasem łapiemy na tym, że kult cargo występował w historii naszej pracy często i zupełnie bezwiednie. Poruszyliśmy ten temat, aby zainspirować Cię do refleksji nad tym, jak działa Twój zespół. Czy powyższe punkty są widoczne w sposobie rozumowania o zwinności w twojej firmie czy zespole? Jak kurczowo trzymacie się ustalonych schematów, bez dopasowania do kontekstu? Czy widzisz u siebie kult cargo?

Kult cargo w Scrumie – możliwe przyczyny

Istnieje wiele przyczyn, przez które pojawiają się objawy kultu cargo. Poniżej wymieniamy kilka najbardziej prawdopodobnych powodów, potraktuj je jako listę otwartą i zastanów się, czy w twoim przypadku nie ma kolejnych punktów, które wpływają na sytuację.

Wdrażanie Scruma „by the book”

W przypadku zespołów zwinnych kult cargo może wynikać ze wdrażania Scruma w 100% zgodnie z instrukcją, tzw. “by the book”. Sami zresztą chwaliliśmy się takim wdrożeniem na pierwszej prezentacji w naszej karierze na konferencji ACE w Krakowie w 2012 roku. Skutkiem takiej taktyki „by the book” może być realizowanie pewnych praktyk według wyobrażenia jak powinny one wyglądać.

Niedopasowanie Scruma do danego kontekstu

Scrum jako sam model pracy zespołu może być również traktowany jako kult cargo. Czasem (zazwyczaj bez głębszej refleksji) Scrum jest wdrażany tam, gdzie nie ma on racji bytu. Jest tak niedopasowany do klasy problemu, z którym mierzy się konkretny zespół czy obszar organizacji.

Niechęć Scrum Mastera do innego podejścia

Bywa też tak, że pewne pomysły dotyczące zmian czy ulepszeń w zespole są ucinane np. przez Scrum Mastera/kę, bo ta osoba chce, by stale działać w konkretny, zarekomendowany przez niego/nią sposób. Powoduje to umacnianie się „jedynej słusznej” metody postępowania. Przy okazji zniechęca to zespół do jakiejkolwiek formy dyskusji o tym, jak i dlaczego właśnie tak postępują.

Przyzwyczajenie i wygoda całego Zespołu

Istotne jest też to, że jako ludzie naturalnie przyzwyczajamy się do pewnych schematów oraz sposobów postępowania. Wcale nie jest łatwo zmieniać coś, co jest już znane i wygodne. Przykładem tego może być wspomniana wyżej ta sama struktura na Retrospektywie albo podejście do Refinementu Backlogu Produktu.  

Sposób uczenia i wyjaśniania Scruma przez trenerów

Ostatnia przyczyna istnienia kultu cargo w Scrumie dotyczy w dużym stopniu nas samych, autorów tego materiału. Sposób przekazywania wiedzy przez trenerów i konsultantów również może być niedoskonały. Bardzo łatwo jest wpaść w pułapkę dawania konkretnych, gotowych instrukcji jak powinny postępować zespoły czy firmy. Często jest na to wręcz nacisk ze strony uczestników, aby operować na konkretnych przykładach i rozwiązaniach.

Powoduje to, że bardzo łatwo na początku przygody ze Scrumem nasiąknąć bardzo konkretnymi metodami realizowania jakiegoś zagadnienia. Osoba początkująca poznaje tylko jedną metodę rozwiązywania danego problemu w zespole. Zrozumiałym może w takiej sytuacji być to, że stara się realizować to, co poznała od eksperta.

Obecnie my sami jako trenerzy czy konsultanci zawsze staramy się dobierać kilka (świadomie) sprzecznych ze sobą przykładów, aby słuchacz mógł poznać różne sposoby postępowania. Dopiero z tej mnogości można dobrać praktykę, która wygląda obiecująco w kontekście danego zespołu i firmy.

Kult cargo w Scrumie – jak się przed tym chronić?

1. Zrozum istotę Scruma i zwinności

Nie trzymaj się sztywno schematu odpowiedzi z certyfikacji i nie powtarzaj jak mantra słów kluczy typu: empiryzm, inspekcja i adaptacja. Zrozum, co to dokładnie znaczy. 

Oczywiście jako początkujący Scrum Master możesz nie rozumieć pewnych rzeczy, a ich sens pojawi się po pewnym czasie. To jest naturalne i warto też poszerzać wiedzę, a zwłaszcza współpracować z mentorem, który pozwoli szerzej otworzyć oczy na pewne sprawy. Ważne jest, aby chcieć lepiej zrozumieć Scruma i nie szukać gotowych odpowiedzi (np. właśnie u mentora), tylko zgłębić zagadnienie, drążyć temat. 

2. Przemyśl swój warsztat pracy jako Scrum Master 

Znajdź przestrzeń na to, aby poddawać analizie to, jak działasz. Jak podejmujesz decyzję o stosowanych praktykach? Refleksji poddawaj też to, co powoduje, że wybierasz daną technikę. Robisz to, bo to ma sens, czy wręcz przeciwnie – działasz „mechanicznie” i bez zastanowienia? 

Praktycznie każda aktywność Scrum Mastera może być małą pułapką. Rekomendujemy, aby cyklicznie spoglądać z pewnej perspektywy, na to, jak pracujesz i zadawać sobie pytania skłaniające do autorefleksji.

3. Poznawaj różne techniki pracy

Często spotykamy się z tym, że mniej zaawansowane osoby nawet nie zdają sobie sprawy, jaka mnogość opcji na poszczególne elementy Scruma istnieje. Jest wiele technik na prowadzenie wydarzeń scrumowych (np. Planowanie Sprintu) czy pielęgnowanie Backlogu Produktu. Wszystko to, można rozwiązać na dziesiątki różnych sposobów, które są sprawdzone w praktyce.

Nie stawaj w miejscu, tylko wciąż się rozwijaj i szukaj innych metod. Może znajdziesz coś bardziej adekwatnego do potrzeby firmy i zespołu, w danym momencie ich rozwoju. Otwórz się na eksperymenty. Spróbuj raz nie trzymać się znanej Ci struktury, nie zrób Daily lub nie prowadź go zgodnie ze zwykłą instrukcją. Zobacz, co się stanie i wyciągnij na tej bazie wnioski. To może być świetny przyczynek do rozmowy w zespole odnośnie tego co członkowie zespołu lubią i dlaczego w ogóle stosowane są wybrane praktyki.

4.  Szukaj inspiracji w innych podejściach 

Mamy tu na myśli metody bliskie zwinności, ale różne od Scruma takie jak np. Kanban, Design Sprint, czy Design Thinking. Wszelkiego rodzaju doświadczenie innych podejść w praktyce bardzo otwiera głowę. Może się okazać, że to, co w Scrumie jest oczywiste, w innych modelach się kwestionuje. Pozwoli Ci to zastanowić się, dlaczego robisz przykładowo Sprinty których w Kanbanie nie ma. Inne wspomniane wcześniej podejścia mocno kwestionują sensowność rzucania się w wir pracy. Design Thinking zachęca, by rozwiązania w odpowiedni sposób przemyśleć i zaprojektować, najlepiej przetestowanie prototypu. 

W praktyce widzimy, że mając wiedzę o różnych podejściach, możemy bardzo płynnie zapożyczać praktyki i pewne podstawy. W efekcie może to prowadzić do świadomego dostarczania wartości biznesowej zamiast trzymania się jednej wskazanej „książki” czy formalnej metody. 

5. Stosuj alternatywne sposoby facylitacji współpracy

Wielu Scrum Masterów widzi współpracę w zespole w sposób synchroniczny. Wszyscy członkowie zespołu muszą pracować jednocześnie nad jednym wątkiem. Choć to możliwy wariant, jest przecież wiele innych metod pracy. Może to być praca indywidualna lub praca w podgrupach. Szukaj technik facylitacji, które dają większą swobodę zespołowi i najlepszy efekt w danej sytuacji. 

Jako Scrum Master bądź osobą, która wspiera zespół w różnych modelach współpracy. Pokazuj różne style dochodzenia do decyzji i alternatywne sposoby pracy w ramach Zespołu Scrumowego.

6. Usprawniaj się jako zespół we właściwy sposób 

Samo prowadzenie Retrospektywy według najlepszej nawet instrukcji wcale nie musi zapewnić, że Zespół długofalowo będzie się usprawniał. 

Bardzo mocno rekomendujemy faktyczne zrozumienie problemu, a następnie szukanie kilku możliwych rozwiązań. Dopiero mając kilka opcji rozwiązań możliwe jest przeanalizowanie ich plusów i minusów, oraz ocenę ich przewidywanej skuteczności. Pomóż swojemu Zespołowi określać, po czym poznacie, że problem został rozwiązany. Zachęcaj do wykonywania eksperymentów i pomóż sprawdzać, czy uzyskaliście pożądany efekt. Jeśli nie to dlaczego? Jakie działania korygujące możecie zastosować?

Czy widzisz kult cargo także w swoim zespole? To dobrze! Tylko, gdy zauważysz problem, możesz go świadomie rozwiązać. Mamy nadzieję, że nasze propozycje uniknięcia kultu cargo pozwolą Ci jeszcze lepiej wykorzystywać techniki zwinne w swojej pracy. 

Dodatkowe materiały

• Kult cargo opisany w Encyklopedii Britannica

Transkrypcja podcastu „Kult cargo w Scrumie”

Jacek: Dzisiejszy odcinek poświęcimy na rozmowę o kulcie cargo w Scrumie. Kierujemy go do osób średnio zaawansowanych i celem tego nagrania jest zachęta do refleksji czy nie wplatamy w swoje działania wspomnianego wcześniej kultu cargo. Kuba za chwilę wyjaśnię to pojęcie. Jeżeli wcześniej się z nim nie spotkałeś bądź nie spotkałaś.

Kuba: Kult cargo to jest pojęcie znane z antropologii. Ono występuje wśród plemion takich miejscowych, zamieszkujących wyspy w okolicy Melanezji. I te miejscowe plemiona, już pod koniec XIX wieku zostało zaobserwowane, że zachowują się w bardzo dziwny sposób. To są takie plemiona pierwotne, jakby nieznające cywilizacji. Ale jak tylko pojawiły się pierwsze ślady kolonizacji, zwłaszcza gdy się to się rozwijało również w czasie wojen, gdy pojawiały się jakieś oddziały wojskowe na tych takich pierwotnych wyspach. Miejscowi, te plemiona zaczęły się zachowywać bardzo dziwny sposób, imitując zachowania i imitując też pewne budowle, które w ich wierzeniu, w ich przekonaniu miały sprawić, że spływają do nich te dobra z takiego właśnie nowoczesnego świata. Więc budowali przystanie dla okrętów, lotniska, ubierali się w bardzo specyficzny sposób. Jest też w internecie taka seria zdjęć i filmów pokazujących bardzo sugestywnie, że tam ubrani ci miejscowi, te miejscowe plemiona, zbudowane z palm, z jakichś takich miejscowych produktów czapki, które wyglądają jak jakieś tutaj. Ubiór osoby sterującej ruchem. Też te samoloty transportowe zbudowane z jakichś gałęzi. W skrócie no jest to wierzenie czy wiara, przekonanie o tym, że jeśli będziemy wykonywać te czynności, które sprawiają, że pojawiają się dobra, to te dobra się pojawią lub pojawią się szybciej, bo czekamy na nie, chcemy i ich potrzebujemy. I to jest oczywiście w bardzo skrócie. Nie jestem tutaj antropologiem. Raczej jest to taka, powiedzmy skrótowa wersja tej historii. Natomiast rzecz w tym, że ten kult cargo, który dosyć łatwo jakby tutaj przypisać tym pierwotnym plemionom, które przecież są takie nieświadome i tak łatwo zapominają o racjonalnym myśleniu, albo w ogóle nie mają swoim świecie tej wiedzy, która powoduje, że wiedzą, że to jest nieracjonalne. 

Kuba: Ten kult cargo też przenosi się do świata takiego naszego codziennego. Używa się też tego pojęcia na szereg zachowań, które powodują, że realizujemy coś powierzchownie, imitujemy pewne zachowania wierząc, że te powierzchowne zachowania dadzą nam te dobre korzyści. Przyniosą te towary, na które na które liczymy. Czyli robimy kopie pewnych zewnętrznych zachowań, bo myślimy, że jeśli będziemy się tak zachowywać, podpatrzyliśmy to u innych. Starszyzna naszego plemienia powiedziała, że tak należy właśnie postępować i to nam wszystko da dobre oczekiwane spodziewane efekty. Natomiast pułapka jest w tym, że wierzymy, a nie wiemy, albo znamy to. No i druga pułapka, że tak naprawdę robimy to coś. To zewnętrzne objawy, a nie tak naprawdę walczymy o to faktyczne jakby dobro, czy korzystne efekty, o które nam chodzi. 

Jacek: I ktoś mógłby pomyśleć, że włączył niewłaściwy podcast. Bo jak to wszystko ma się do Scruma? A więc, żeby ułatwić Ci zrozumienie, jak kult cargo przejawia się w Scrumie podzielimy się z Kubą kilkoma przykładami jak kult cargo możesz zaobserwować w tym Frameworku. 

Kuba: Pierwszym przykładem cargo kultu, który przychodzi mi do głowy w Scrumie to wykresy spalania. Znane też jako burn downy. Wielu Scrum Masterów, wiele zespołów wpatruje się w te wykresy. Dba o to, żeby były ładne. Dba o to, żeby były takie idealnie równo spadające przez cały Sprint. Wierząc, że właśnie dzięki temu narzędziu uzyskamy regularne dostarczanie. 

Jacek: Innym przykładem jest trzymanie się formatu historii użytkownika, czyli popularnego formatu User Stories w Backlogu Produktu – jeśli mówimy o Scrumie. I stoi za tym wiara, że jeżeli będziemy używać tego formatu, nawet w taki bardzo bezmyślny sposób, to zapewni nam to to, że będziemy tworzyć produkt, który jest wartościowy dla Użytkownika.

Kuba: W niejednym plemieniu stosowane są Story pointy jako jedyna słuszna wersja wyceniania pracy. Story pointy, które nas prowadzą do trafnych estymat, bardzo przewidywanego dostarczania.

Jacek: I równie bardzo popularne są trzy pytania zadawane podczas codziennego Scruma, czyli na popularnych spotkaniach typu Daily czy Stand-up. Z taką intencją, że jeżeli wszystkie osoby odpowiedzą na trzy pytania sugerowane we wcześniejszych wersjach „Przewodnika po Scrumie”, no to zapewnia nam to dobrą komunikację w zespole.

Kuba: I ostatnia rzecz, która przychodzi mi do głowy, gdy myślę o cargo kulcie w Scrumie, to bardzo kurczowo trzymanie się bardzo konkretnej techniki, czy struktury Retrospektywy Sprintu. Trzymanie się i nieodstępowanie ani co Sprint, ani co dyskusje. Dokładnie tak samo, na to samo kopyto. Wiedząc, czy wierząc w to, że ta technika się na pewno sprawdzi i doprowadzi do tego, że będziemy lepszym usprawniającym się zespołem. 

Jacek: I istotny komentarz, zanim pójdziemy dalej jest taki, że w szczególności wymieniając tutaj te przykłady kultu cargo, nie chodzi nam o krytykowanie osób, tylko raczej o zwrócenie uwagi na to, że warto poddawać refleksji rzeczy, które robimy i zadbać o to, żeby ta perspektywa taka trochę zewnętrzna, czy może z lotu ptaka spojrzenia na to, co robimy, żeby ona cały czas gdzieś była w naszym pobliżu.

Kuba: My sami też się łapiemy, a zwłaszcza jak patrzymy na swoją własną przeszłość, czy historię swoich doświadczeń na tym, że w niejednym miejscu taki kult cargo następował zupełnie bezwiednie. I to, co też chcę na pewno mocno podkreślić to, że to nie jest krytyka złego stosowania Scruma jako takiego, czy złego doboru pewnych praktyk. Tutaj nawet to nie jest odcinek o tym, czy User stories są częścią Scruma, czy nie. Bardziej taka refleksja na temat tego, że jakoś tak się dzieje, że trafiamy do kolejnej firmy, do kolejnego zespołu i tam też następuje pewien powtarzalny schemat bardzo kurczowego trzymania się pewnych konkretnych technik i nieodpuszczania ich. Idąc nawet głębiej, gdy wejdzie się w jakąś szerszą, szczerą rozmowę, no to się wszyscy łapią na tym, że – Kurczę. Nawet się nad tym nie zastanawiałem, nie zastanawiałam, dlaczego tak, a nie inaczej postępuję – No i to byłby właśnie sygnał czy taki ślad, że ta analogia, czy porównanie do tego, czym jest kult cargo jest właściwe. 

Kuba: Z czego może wynikać ten kult cargo w przypadku zwinnych zespołów? Kilka myśli, zanim przejdziemy w ostatniej części tego odcinka do konkretnych podpowiedzi, co można zrobić, żeby tego uniknąć. Moim zdaniem może to wynikać na przykład za bardzo konkretną sugestią co do sposobu wdrażania Scruma czy wprowadzania Scruma do zespołu. Wiele osób bardzo mocno wierzy w takie podejście – podążaj za instrukcją. Wprowadzaj Scruma by the book. I tak jak wspominaliśmy chwilę temu, sami też z Jackiem jesteśmy znani z pierwszej prezentacji na konferencji ACE w Krakowie, lata temu już, gdzie też między innymi bardzo się dumnie chwaliliśmy, że wprowadzaliśmy Scruma by the book. I jest to jeden ze wzorców postępowania. Można tak robić, natomiast skutkiem tego może być też realizowanie pewnych czynności tak, jak mi się wydaje, że one powinny być realizowane i bardzo kurczowo trzymanie się tego, bo nie znam innych modeli. 

Jacek: Innym powodem tego, że kult cargo pojawia się w świecie zespołów, jest to, że Scrum sam w sobie może jako cały model być traktowany jako kult cargo. Na takiej zasadzie, że trochę czasem bez głębszej refleksji Scrum jest pchany właściwie w rejony, w których on tam nie pasuje. Jest jakby niedopasowany do klasy problemu, z którym mierzy się konkretny obszar organizacji czy zespół. I bardzo często też w mojej praktyce spotykam się z takimi dyskusjami, które doprowadzają do konkluzji, że wcale niekoniecznie nie Scrum. OK. Być może będziemy chcieli się inspirować rzeczami czy ze świata zwinnego, czy z Kanbanu. Ale to nie musi być ten książkowy Scrum, o którym wszyscy tak dużo opowiadają. 

Kuba: No i ten książkowy Scrum może mieć też trzeci powód tego, dlaczego występuje kult cargo. Taki już trochę wtórny powód. Czyli zespoły czasami, czy pojedyncze osoby w zespole mogą proponować jakąś zmianę, jakieś odejście. Natomiast wiele osób na taki pomysł, zwłaszcza wybrani Scrum Masterzy mogą reagować dosyć alergicznie. Czyli Daily będziemy robić tak, Backlog będziemy prowadzić tak, Retro czy wszystkie inne wydarzenia scrumowe będziemy prowadzić tak, a nie inaczej. Co powoduje takie umacnianie się jedynej słusznej metody postępowania i – co gorsza – trochę zniechęca do jakiejkolwiek formy dyskusji o tym, jak postępujemy, dlaczego tak postępujemy, czy nam pasuje ta konkretna technika, czy ten konkretny cały Framework. No i jeśli transformacja zwinna, jeśli Scrum, jeśli Scrum Masterzy mają mocne, niepodważalne stanowisko w firmie i jakby nie można odrzucić Scruma, to może to prowadzić do takiej rytualizacji. Czyli wykonujemy te, i tutaj bardzo pasuje to słowo, którego nie lubię, wykonujemy te ceremonie. Stosujemy jakieś konkretne narzędzia. Uzupełniamy jakieś elektroniczne tablice. Ale tak naprawdę nie wnikamy w to, a próby jakiejś tam zmiany rzeczywistości zostały dosyć szybko zgaszone w zarodku, więc sobie odpuszczamy. No i to jest dosyć prosty przepis na takie samo nakręcają się kulty cargo właśnie w metodach pracy zespołów zwinnych 

Jacek: Takim trochę rozwinięciem tego, co mówisz Kuba, może być też to, że po prostu jako ludzie przyzwyczajamy się do pewnych schematów, pewnych takich sposobów postępowania i nie próbujemy tego zmieniać. Więc w pewnym sensie cementujemy nasze zachowanie. Czyli na przykład, być może cały czas korzystamy z tej samej struktury na Retrospektywie, albo być może cały czas w ten sam powtarzalny sposób przenosimy z zespołu do zespołu sposób podejścia do pielęgnacji Backlogu Produktu. Tego typu działanie również może powodować, że pewne rzeczy staną się bardzo mechaniczne. W pewnym momencie być może nawet zapomnimy, po co to robimy. No ale tak robiliśmy wcześniej, tak robiliśmy od zawsze. No więc po prostu przestajemy to w ogóle kwestionować 

Kuba: I Ostatnią przyczyną źródłową tego, że kult cargo w Scrumie może być stosowany, będzie coś, co dotyczy o wiele większym stopniu nas samych oraz osoby nam podobne. Kult cargo może wynikać z tego, jak trenerzy, jak konsultanci, jak mentorzy, bardziej doświadczone osoby przekazują wiedzę tym początkującym. Bardzo łatwo wpaść w taką pułapkę dania bardzo konkretnej, gotowej szczegółowej instrukcji. Zawsze jest na to presja, na przykład na szkoleniach, gdzie trener zawsze jest pod naciskiem dawania bardzo konkretnych przykładów, bardzo konkretnych instrukcji. Mniej filozofii i więcej doświadczeń, mniej ogólnej historii, więcej konkretnych przykładów z zespołów. Co powoduje, że bardzo łatwo na początku nasiąkać bardzo konkretnymi jednymi i jedynymi metodami realizowania jakiegoś powiedzmy problemu, czy rozwiązania jakiegoś zagadnienia w zespole. No to jest powiedzmy coś, co trzeba unieść. Każdy mentor musi wiedzieć, jak to dobrać, ale mimo wszystko znaleźć w sobie możliwość przekazania na przykład kilku przykładów, kilku trochę ze sobą sprzecznych, żeby ten słuchacz sobie dobrał, albo chociaż zdawał sobie sprawę, że jest wiele sposobów na planowanie Sprintu, a nie usłyszał wręcz procedurę i później na przykład przez najbliższy rok się będzie się jej bardzo kurczowo trzymał. O ile w pierwszym Sprincie lub drugim Sprincie taka procedura może być potrzebna, żeby wiedzieć, od czego zacząć, to może niepotrzebnie ubezwłasnowolnić taką osobę, żeby w przyszłości nie szukała alternatyw do tego, co poznała na bardzo wczesnym etapie.

Jacek: Myślę, że całkiem nieźle narysowaliśmy temat kultu cargo w Scrumie. Przejdziemy teraz do konkretów. Czyli, co można zrobić z tym, żeby nie paść ofiarą kultu cargo? Co byś Kuba zarekomendował, jako pierwsza porada dla naszego słuchacza?

Kuba: To może być dosyć ogólne to, co powiem, ale dla mnie najważniejsze w temacie unikania zjawiska jakim jest kult cargo w Scrumie jest to, żeby zrozumieć istotę Scruma i ewentualnie też istotę zwinności. Wyjść trochę poza taki schemat znania odpowiedzi na certyfikację, albo wykucia na blachę konkretnych zdań. Czy powtarzania takie jak mantra tych konkretnych słów kluczy, empiryzm, inspekcja i adaptacja. Tylko zrozumienie, co to dokładnie znaczy. Po co właśnie takie rzeczy zostały zrobione? I tutaj, zwłaszcza jeśli jakby jesteśmy w trakcie rozwoju scrumowego, jako początkujący Scrum Master, jako osoba, która gdzieś tam w miarę dopiero zaczyna. Może być tak, że tego po prostu nie da się uniknąć, że na początku będę pewne rzeczy nie rozumiał, będę widział je o wiele za płasko. To jest dla mnie klasyk pamiętający, to akurat twojego zespołu dawno temu dotyczyło. To jest tak, że przez pierwszych kilka miesięcy robimy coś, a potem dopiero na nowo odkrywamy, że w sumie to Daily, to ma jakiś większy, głębszy sens. Może musimy trochę inaczej do niego podejść. To jest naturalna droga, że jakby na nowo po parę razy będziemy odkrywać tego Scruma. Ze swojego osobistego doświadczenia wiem, że mi niesamowitą różnicę zrobiła współpraca z mentorem. Niezależnie od tego, co się uczyłem na szkoleniach. Niezależnie od tego, co sobie sam doczytałem, czy obejrzałem gdzieś w internecie, co sam po praktykowałem z zespołem w swoim własnym pierwszym. No… Głowa mnie bolała i czułem lekki niesmak do samego siebie, jak mi ten mój najważniejszy mentor bardzo dobitnie pokazał, że pewne rzeczy nie rozumiałem, że pewne sposoby postępowania na przykład na Retrospektywie są dramatycznie groźne dla zespołu. No i to mi pomogło lepiej zrozumieć, po co jest Scrum. I nad tym jeszcze reflektuję to jakby dwie ważne myśli. Ja musiałem chcieć lepiej zrozumieć Scruma i mój mentor też chciał i musiał mieć nastawienie na to, żeby jakby pokazywać mi szerszy obraz. Czyli niekoniecznie zawsze mi dawał gotowe odpowiedzi, tylko wręcz mnie prowokował dalszymi pytaniami do wnikania. Pokazywał pewne materiały, żebym ja sobie sam tego szukał. I teraz jakby to przekuć na konkrety, no, to jeśli ty słuchaczu lub słuchaczko jesteś w takiej sytuacji, to drąż. A jeśli jesteś już na etapie bycia mentorem dla kogoś, to też zwracaj na to uwagę, czy czasami nie daje zbyt szczegółowych, jednorodnych instrukcji. A czy czasami nie jest tak, że osoba, którą wspierasz, mogłaby chcieć trochę szerszego pomyślenia, zrozumienia, zagłębienia istoty rzeczy. 

Jacek: Druga porada na temat tego jak radzić sobie z tym, czym jest kult cargo, brzmi, przemyśl swój warsztat pracy jako Scrum Master. Jest to porada, która trochę w sumie zahacza Kuba to, co mówiłeś wcześniej, że ta osoba, która pracuje w Scrumie, no przede wszystkim chce zrozumieć, ma przestrzeń taką umysłową – bym powiedział – i czasową na to, żeby w ogóle takie rzeczy poddawać pod analizę. I ja bym to powiedział tak po prostu, warto dokonać refleksji. Na zasadzie, jaki mamy warsztat? Jak podejmujemy decyzje? Co robimy? Dlaczego tak robimy? Co powoduje, że decydujemy się na taką, a nie inną technikę? Czy to jest, to co robimy już z automatu i spodziewamy się tych samych efektów? Czy to ma sens, że stosujemy te same podejścia, te same techniki? Przykładowo, ktoś może stosować Story mapping w jakimś konkretnym zespole, uzyskać fajne efekty i dojść do konkluzji, że może zawsze warto wykorzystać tę technikę. Może to być pułapka. Nie wiem, jakiś konkretny sposób prowadzenia Retrospektywy też może być problematyczny. Czy nawet jakaś taka postawa jako Scrum Master. Czyli powiedzmy, nie wiem, domyślne występowanie w roli takiej bardziej nauczyciela na przykład niż coacha. Wszystkie takie drobne decyzje, które nas definiują ostatecznie jako Scrum Mastera, no to każda z nich może być jakąś tam delikatną pułapką. Stąd rekomendacja, żeby cyklicznie spoglądać z pewnej perspektywy na to, jak pracujemy i czasami zastanawiać się po prostu, dlaczego właśnie w ten sposób postępujemy, a nie w inny. 

Kuba: Ja to trochę odwrócę, nawet może bardziej prowokacyjnie ujmę. Bo pracuję, ostatnio tak się zdarzyło, że w zasadzie kilka razy w różnych organizacjach z podobnym typem Scrum Masterów, relatywnie zaczynających swoją karierę, ale już jakimś backgroundem, już po szkoleniach, już z certyfikacją, już coś tam wiedzą. Regularnie łapię się na tym, że wiele osób takich mniej zaawansowanych, nawet nie zdaje sobie sprawy, jaka mnogość opcji na wszystkie poszczególne elementy Scruma istnieje. Czyli, gdzie tu prowokacja? To drogi słuchaczu lub słuchaczko. Ile znasz technik na konkretne na przykład poprowadzenie wydarzeń scrumowych? O ile łatwiej gdzieś tutaj iść w Retrospektywę, bo są tysiące i można na różne sposoby je poprowadzić. Ale chodzi mi też o to, jak różnorodne są te techniki. Nie mam na myśli tego, że na 10 sposobów generujemy tematy. Miejmy jeden lub pięć technik, których w ogóle nic nie generujemy, tylko zaatakujemy problem jeszcze zupełnie inaczej. A jeszcze weselej się robi, gdy myślę o planowaniu pracy, albo na przykład pielęgnowaniu Backlogu Produktu. To można rozwiązać na dziesiątki różnych sposobów, konkretnych, sprawdzonych, bardzo różnych od siebie technik lub w ogóle jakichś hybryd czy miksów. I pytanie. Czy znasz? Czy umiesz? Jak komfortowo czujesz się w kilku i umiesz je dobrać do sytuacji w swoim zespole? I idąc tropem, trzecia rada to, poznawaj różne techniki pracy. Jeśli z tego poprzedniego czelendżu wynika, że kurczę gdzieś mi coś brakuje, no to zdecydowanie jedną z rzeczy, którą oczekuję od Scrum Mastera, to dalszy ciągły rozwój. Szukanie metod adekwatnych do potrzeby w danej sytuacji organizacji, w danym momencie rozwoju zespołu. I mam tu na myśli na przykład sposoby priorytetyzacji Backlogu. Są bardzo różne. Nie musi to być tylko jedna lista. Może być uwzględnienie różnych wielu jakby podejść, całej sfery tutaj, chociażby zarządzania produktem. Jest na to dużo technik. Różne techniki Retro, już wspomniałem. Nie zdawajmy się na los. Nie zdawajmy się też na to, że poznałem jedną, więc ją stosuję, albo moje narzędzie elektroniczne ma tylko jedną, więc twardo się tego trzymam. To jest piękne pole do eksperymentu. Również do takiego eksperymentu szalonego. Mam tu na myśli na przykład niezastosowanie żadnej struktury, po to, żeby zobaczyć, po co w ogóle to coś robimy? Na przykład, nie zróbmy Daily, albo nie poprowadźmy go tym razem tak bardzo kurczowo według tej metody, którą znamy i zobaczmy, co się stanie, jeśli zrobimy to świadomie, jeśli to zrobimy razem z całym zespołem. To może być świetna rozmowa czy świetny przyczynek do tego, żebyśmy sobie powiedzieli, co lubimy, czego nie lubimy, po co nam to wszystko jest.

Jacek: Jak słucham tego, o czym mówisz, to myślę, że tutaj to, co pomaga i też takie moje ostatnie doświadczenia pracy z zespołem, to na pewno otwartość na eksperymenty. Wyobrażam sobie historię, w której spotykam się z oporem, niechęcią, albo może po prostu z takim brakiem, nazwijmy to podążania za pewną koncepcją. Z różnych powodów, bo terminy, bo mamy tylko godzinę, bo zawsze tak robiliśmy. Więc żeby też mieć fajne pole do eksperymentowania i poszukiwania tych odpowiedzi nazwijmy to, no to musi być też pewna taka wola na to, że może nie wyjść. Mówisz Retro bez struktury. W sumie, co może się stać? Wiele zespołów w ogóle nie ma tej struktury i funkcjonuje. Tak więc zdecydowanie otwartość na eksperymenty jest tutaj pomocna. 

Jacek: Kolejna porada brzmi, szukaj inspiracji w innych podejściach. I mówiąc o innych podejściach, jesteśmy w tym odcinku mocno w okolicach Scruma, mam na myśli takie rzeczy jak Kanban, takie rzeczy jak na przykład Google sprint czy Design Thinking. Czyli takie rzeczy, które jednak są gdzieś tam, nazwijmy to, w otoczeniu zwinności. Może być tak, że ze względu na naszą ścieżkę rozwoju mogliśmy nigdy nie trafić na inny sposób pracy niż na przykład klasyczny Scrum, albo pracowaliśmy tylko przy użyciu Kanbanu i nigdy nie pracowaliśmy na przykład Scrumem. Sam widzę, jak bardzo otwierające głowę są wszelkiego rodzaju czy lektury, czy doświadczenie też tych innych podejść w praktyce. Gdzie nagle okazuje się, że musimy pewne nasze założenia dosyć mocno zakwestionować i zastanowić się, dlaczego to robimy, skoro okazuje się, że w jakiejś innej metodzie, w ogóle takich założeń nie ma. Czyli przykładowo taki klasyk. No to w Scrumie mamy Sprinty. No i przecież one są święte. Natomiast Kanban? No są jakieś kadencje, prawda? Ale co do zasady takiego wyraźnego Sprintu znanego ze Scruma, nie ma. Sam też pamiętam bardzo fajne takie przemyślenia, które mi do głowy przychodziły jak czytałem o Sprintach googlowskich, które też bardzo mocno kwestionowały sensowność rzucania się w wir pracy, a raczej pokazywały, że rozwiązania trzeba przemyśleć, zaprojektować, a najlepiej jak zbudujemy prototyp i przetestujemy. I to też było bardzo fajne doświadczenie. W praktyce widzę, że mając tą wiedzę, możemy sobie bardzo płynnie sięgać, zapożyczać, przywoływać praktyki, anegdoty, pewne pryncypia wartości. Wydaje mi się, że na koniec dnia, to powoduje, że jesteśmy bliżej świadomego dostarczania wartości, a dalej od tego, że robimy coś, bo tak każe książka czy bo tak by wypadało to zrobić. 

Kuba: I uogólniając to trochę, co Jacek powiedziałeś, to taka refleksja, że bo ja też mam dużo dobrych wspomnień po na przykład odkryciu podejścia kanbanowego. Ta refleksja to to, że Scrum i jego twórcy podjęli za Scrum Masterów szereg konkretnych decyzji na temat tego, jak będzie wyglądać proces. Mamy właśnie iteracje, przyrosty, mamy konkretne reguły co do ról. Wszystkie te rzeczy przychodzą jako właśnie potencjalnie zagrożenie tego zjawisko jakim jest kult cargo. Zachowuj się dokładnie tak, ubierz taką czapkę i zbuduj takie nabrzeże, to będzie dobrze. I teraz broń Boże nie atakuję Scruma, bo sam coś, co widzę to to, że możemy to wszystko jakby z powrotem zintegrować i lepiej rozumieć, kiedy faktycznie trzeba pracować iteracyjnie, przyrostowo, a kiedy to może być nieadekwatne. Jakie są warunki, żeby funkcjonowały pewne konkretne role, czy inne konkretne mechanizmy Scrumowe, które jakby idą w pakiecie. One są nam dane, one są już zakomunikowane, że tak mamy postępować. No i zwłaszcza na początku możemy w ogóle nie zdawać sobie sprawy, dlaczego właśnie tak, a nie inaczej. I tutaj te inne metody, inne podejścia, inne sposoby postępowania, mogą nam pokazywać, że pewne świętości jednak takie święte nie są. Możemy kręcić większą ilością pokręteł, albo po prostu sobie wkładać do naszej metody inne techniki, które też powodują dużo dobrego

Kuba: Do osobnego punktu, do osobnej porady à propos unikania zjawiska jakim jest kult cargo, dokładam taką podpowiedź, stosuj alternatywne sposoby facylitacji współpracy. Wiele osób, wielu Scrum Masterów łapie na tym, że bardzo zero-jedynkowo widzą współpracę, jako cały zespół współpracuję jednocześnie nad jednym wątkiem. To wyciągam do osobnej porady, bo to nie jest powiązane z żadną z konkretnych technik. To też nie jest w zasadzie w ogóle wskazane jako jedyna słuszna wersja Scruma. Wydaje mi się, że tu jest jakaś taka, powiedzmy moda, czy jest jakiś taki wzorzec postępowania, że Refinement to jest spotkanie całego zespołu. Retrospektywa to jest dyskusja całego zespołu nad jednym tematem. Coś, co sugeruję w tym punkcie to to, żeby być w porządku, być świadomym co do tego, że jest też praca indywidualna w ciszy. Jest praca w podgrupach. Pewne elementy możemy w jakiś mniejszych konfiguracjach realizować i szukać technik facylitacji, które dają większą swobodę zespołowi i dają też lepszy efekt w danej jednostce czasu. I nie bójmy się ich stosować. Nie bójmy się gdzieś tak rozszerzać ten sposób postrzegania tego, jaka jest moja rola jako Scrum Master. Nie jestem tylko moderatorem prowadzącym jednowątkową dyskusję, mogę być też osobą, która wspiera zespół w różnych modelach współpracy, dochodzenia do różnych decyzji, wypracowania różnych szczegółowych jakichś kawałków pracy typowej dla zespołu scrumowego.

Jacek: Powiedziałeś o modzie. I jak sobie o tym pomyślałem, to myślę, że to może nawet nie być moda. W sensie modę rozumiem jako to, że jest teraz popularne, żeby robić coś. Ja myślę, że to może być bardziej nieznajomość tego, że w ogóle można inaczej. Czyli przed pracą zwinną wszystko robiliśmy jako jeden team, dokładnie tak jak mówisz. Wyświetlaliśmy sobie jakieś tam wymagania w formie pliku i wszyscy patrzyliśmy w ekran. Więc w Scrumie na Refinemencie nadal patrzymy w ekran, tylko nie ma wymagań, tylko jest Backlog Produktu. Ale generalnie ten core właśnie, jak to spotkanie jest ustrukturyzowane, pozostaje taki sam. Efekty można sobie wyobrazić, jakie potencjalnie mogą być, a przynajmniej to, co widzę, to taką stratę, że moglibyśmy dowiedzieć się, czy można inaczej. Iteracyjnie zespół dochodzi do fajnych rezultatów, chociaż niektóre eksperymenty nie wychodzą.

Jacek: I ostatnią poradę, którą mamy na dzisiaj brzmi, usprawniaj się jako zespół we właściwy sposób. Ten właściwy sposób, to mamy tutaj na myśli to, żeby faktycznie rozwiązywać problemy. Czyli może ktoś pomyśleć, no przecież robimy Retrospektywy. No ale samo przeprowadzenie, tak jak to wspomniałeś, to konkretne słowo – ceremonii Retrospektywy – wcale nie zapewni, że zespół długofalowo będzie się usprawniał. Nawet możemy mieć strukturę tego spotkania i tak dalej. To też nie jest gwarant. I to, co tutaj rekomendujemy, to poświęcenie czasu na faktyczne zdefiniowanie problemu. Czasem obserwuję, że problemem jest po prostu jakaś taka bardzo powierzchowna obserwacja. Natomiast problem jest gdzieś tam kilka poziomów niżej. Na przykład dopiero po paru jakichś tam iteracjach zadawania konkretnych pytań dochodzimy, co jest problemem źródłowym. Idąc dalej. Nie wskakujemy w pierwsze lepsze rozwiązanie, które ktoś tam pierwszy powiedział, tylko jednak sobie eksplorujemy, jakie są opcje, ile ich mamy, plusy i minusy. Może to można pogrupować? W jakiś sposób dokonać ewaluacji. No i idąc dalej, tak trochę domykając, jednak wybieramy jakąś konkretną opcję i wykonujemy jakiś taki, nazwijmy to, świadomy eksperyment. Ustalamy, czego się spodziewamy. Po czym poznamy, że to wyszło? Kiedy? Wykonujemy ten eksperyment, a następnie sprawdzamy, czy uzyskaliśmy efekt. Jeśli tak to znów tutaj mamy rozdroże, co z tym robimy dalej. Czyli podsumowując. Chodzi o to, żeby faktycznie głęboko schodzić, bo wyobrażam sobie, że taka głęboka Retrospektywa, taki sposób podchodzenia do problemów, może być pomocny w zdiagnozowaniu tego, że właśnie być może coś robimy na autopilocie. Jak tak się głębiej zastanowimy, to w sumie na przykład tracimy czas. No ale tak robiliśmy i po prostu zabrakło nam tego, żeby na spokojnie się przyjrzeć tej konkretnej sytuacji i jakoś tam spróbować ocenić.

Kuba: Trochę odwracając, to co powiedziałeś, to pokażę przykład, dlaczego tutaj jest zagrożenie zjawiskiem jakim jest kult cargo, albo to, co powiedziałeś, może być sposobem na pominięcie tego. Niejedna Retrospektywa wśród tematów do pogadania ma na przykład właśnie – zacznijmy stosować Story Mapping, albo i Event Storming, bo jest modny, jest świeży, ktoś tam fajnie coś opowiedział. Brzmi ciekawie, to robimy. Czyli jakby, nie rozwiązujemy problemu, nie zastanawialiśmy się, jaki to jest problem. Nie zgłębiliśmy tych głębszych przyczyn. A nawet, jeśli to zrobiliśmy, to od razu nam przychodzi do głowy konkretne rozwiązanie. To jest właśnie ten fragment, gdzie jest największe zagrożenie tym, czym jest kult cargo. Mamy już gotowce i nawet nie do końca wiemy, czy to jest to, ale robimy to. No i ewentualnie w dalszym kroku jest zawsze zagrożenie, że nawet jeśli dobrze to przemyśleliśmy, to u nas to nie zadziała, bo z jakiegoś powodu czegoś nie dostrzegliśmy. Po prostu jest złożony świat. Może niedobrze to rozpoznaliśmy? Dlatego do tych wniosków z Retrospektywy trzeba wrócić. Zobaczyć czy pomogło, czy jest lepiej, czy rozwiązaliśmy problem. Jakie są efekty, ale też, jakie są efekty takie uboczne, których się nie spodziewaliśmy, a jednak wystąpiły. Żebyśmy mieli tutaj jakby pełną świadomość tego, gdzie zmierzamy, co zaplanowaliśmy, co uzyskaliśmy i jak jeszcze możemy to skorygować. 

Kuba: Podsumowując. Co możesz zrobić, aby uniknąć kultu cargo w Scrumie? Zrozum istotę Scruma i zwinności. Przemyśl swój warsztat pracy jako Scrum Master. Poznawaj różne techniki pracy.

Jacek: Szukaj inspiracji w innych podejściach. Stosuję alternatywne sposoby facylitacji współpracy i usprawniaj się jako zespół we właściwy sposób. 

Kuba: Jeśli słuchasz nas na bieżąco, to ten odcinek jest pierwszym w nowym roku 2022, a Nowy Rok to zazwyczaj nowy budżet i nowe otwarcie w jakimś atakowaniu wyzwań czy reorganizacji. Realizujemy skrojone na miarę programy wsparcia. Na przykład rozwój Scrum Mastera w swojej roli. Robimy wtedy superwizję, wskazujemy obszary do usprawnienia. Podpowiadamy co i jak usprawnić i pomagamy wprowadzać w życie te usprawnienia. Jeśli takie wsparcie to jest coś, co Twoja firma albo Twoje zespoły by potrzebowały, skontaktuj się z nami poprzez porządnyagile.pl/kontakt. 

Jacek: Notatki do tego odcinka, transkrypcję, zapis wideo, a po kilku dniach również artykuł podsumowujący rozmowę, znajdziesz na stronie porządnyagile.pl/78.

Jacek: I to by było wszystko na dzisiaj. Dzięki Kuba.

 Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.