#078 – Kult cargo w Scrumie

Kult cargo w Scrumie może być niebezpieczny. Naśladujesz inne zespoły scrumowe. Ślepo wierzysz bardziej doświadczonej osobie, że stosowane i rekomendowane przez nią metody działają 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ć ten kult cargo w Scrumie i co można zrobić, żeby nie paść jego ofiarą.

Zapraszamy Cię do obejrzenia nagrania podcastu i do przeczytania artykułu pod filmem.

Słyszałeś/aś o kulcie cargo w Scrumie? Czy zaobserwowałeś/aś go w swoim zespole? Jaki ma on wpływ na całościowy efekt Waszej pracy? 

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

Innymi słowy, kult cargo to przekonanie o tym, że jeśli będziemy wykonywać te czynności, które sprawiają, że pojawiają się dobra, to te dobra się u nas pojawią, bo przecież na nie czekamy, chcemy je i ich potrzebujemy.

Mimo że jest to pojęcie przypisywane pierwotnym plemionom i brak mu racjonalności, to przenosi się ono także do naszego codziennego życia. Pojęciem tym opisujemy szereg zachowań, które powodują, że realizujemy coś powierzchownie i imitujemy pewne zachowania, wierząc, że to wystarczy, aby uzyskać dobre wyniki i oczekiwane korzyści. 

Pułapka jest w tym, że kopiujemy czyjeś działania, opierając się jedynie na wierze, że to działa, nie mamy wiedzy, że tak faktycznie jest.  

Kult cargo w Scrumie – przykłady

Kult cargo widoczny jest również w Scrumie, co pokażemy Ci na pięciu przykładach. Zaznaczamy tu jednak, że nie chodzi nam o krytykowanie kogokolwiek. Chcemy tylko zwrócić Twoją uwagę, na to, że warto poddawać refleksji rzeczy, które robimy. Warto czasem spojrzeć na wszystko z trochę innej perspektywy, gdyż może nawet drobne zmiany w naszym działaniu przyniosą lepsze efekty. 

  1. “Ładne” wykresy spalania (tzw. burn downy) – 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 słuszna wersja wyceniania pracy – spowodowane jest to wiarą, że Story pointy prowadzą nas do trafnych estymat i pozwalają na bardzo przewidywalne dostarczanie. 
  4. 3 pytania na Daily lub Stand-upach – intencja jest tu taka, że 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 zapewnimy sobie dobrą komunikację w zespole.
  5. Kurczowe trzymanie się konkretnej techniki czy struktury Retrospektywy Sprintu – czyli nic się nie zmienia, nie ma żadnych ulepszeń, dostosowania do specyfiki zespołu. Stoi za tym wiara, że to pozwoli na bycie lepszym, usprawniającym się zespołem. 

Tak jak wspomnieliśmy wcześniej, nie mamy tu na celu krytykowania złego zastosowania Scruma czy 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 kurczowo trzymacie się jakichś schematów, czy ów kult cargo i u Was się pojawił.

Kult cargo w Scrumie – przyczyny

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 na konferencji ACE w Krakowie. Oczywiście można tak działać, jednak skutkiem tego może realizowanie pewnych czynności według tego co nam się wydaje, kurczowe trzymanie się tego z powodu nieznajomości innych modeli.

Zresztą Scrum jako model może być traktowany jako kult cargo. Czasem trochę bez głębszej refleksji Scrum jest wdrażany tam, gdzie nie ma on racji bytu. Jest tak jakby niedopasowany do klasy problemu, z którym mierzy się konkretny zespół czy obszar organizacji.

Bywa też tak, że pewne pomysły dotyczące zmian czy ulepszeń są ucinane np. przez Scrum Masterów, którzy chcą, by stale działać w konkretny, zarekomendowany przez nich sposób. Powoduje to takie umacnianie się jedynej słusznej metody postępowania, a przy okazji zniechęca to trochę zespół do jakiejkolwiek formy dyskusji o tym, jak i dlaczego właśnie tak postępujemy.

Istotne jest tu także to, że jako ludzie przyzwyczajamy się do pewnych schematów oraz sposobów postępowania i nie próbujemy tego zmieniać, bo tak jest wygodnie. Przykładowo, cały czas korzystamy z tej samej struktury na Retrospektywie albo w ten sam powtarzalny sposób przenosimy z zespołu do zespołu podejście do pielęgnacji Backlogu Produktu. Tego typu działanie może powodować, że pewne rzeczy staną się bardzo  i w pewnym momencie zapomnimy po co, to robimy. 

Ostatnia przyczyna stosowania kultu cargo w Scrumie dotyczy w dużym stopniu nas samych. Chodzi tu o sposób przekazywania wiedzy przez trenerów, konsultantów czy osoby mające doświadczenie w tym obszarze. Bardzo łatwo jest wpaść w pułapkę dawania konkretnych, gotowych instrukcji, gdyż jest na to nacisk, 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, czy rozwiązywania jakiegoś problemu w zespole. Stąd zawsze staramy się dobierać kilka sprzecznych ze sobą przykładów, aby słuchacz mógł poznać różne sposoby postępowania, np. przy planowaniu Sprintu.

Jak się uchronić przed kultem Cargo w Scrumie?

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 

Łączy się to trochę z poprzednią poradą, gdzie Scrum Master przede wszystkim chce zrozumieć istotę Scruma. Znajdź przestrzeń na to, aby poddawać analizie to, jak działacie, jak podejmujecie decyzję, co i dlaczego tak robicie? Refleksji poddawaj też to co powoduje, że wybierasz, taką, a nie inną technikę, czy to ma sens, czy nie działasz już za bardzo mechanicznie? 

Praktycznie każda rzecz, która definiuje nas jako Scrum Mastera, może być taką małą pułapką. Stąd rekomendujemy, aby cyklicznie spoglądać z pewnej perspektywy, na to jak pracujesze i zadawać sobie pytania, dlaczego w ten, a nie w inny sposób?

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 wszystkie poszczególne elementy Scruma istnieje. Jest wiele technik na prowadzenie wydarzeń scrumowych albo na planowanie pracy 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 metod adekwatnych do potrzeby w danej sytuacji organizacji, w danym momencie rozwoju zespołu. Jako przykład niech posłużą różne sposoby priorytetyzacji Backlogu, różne techniki Retro. Bądź otwarty na eksperymenty. Spróbuj raz nie trzymać się jakiejś struktury, nie zrób Daily lub nie prowadź go kurczowo zgodnie z instrukcją i zobacz, co się stanie. To może być świetny przyczynek do rozmowy w zespole odnośnie tego co lubimy, czego nie lubimy, po co nam to wszystko jest.

4.  Szukaj inspiracji w innych podejściach 

Mamy tu na myśli metody bliskie zwinności, takie jak np. Kanban, Google Sprint, czy Design Thinking. Wszelkiego rodzaju lektury czy doświadczenie innych podejść w praktyce bardzo otwiera głowę. Nagle może się okazać, ż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. Przykładowo, w Scrumie Sprinty są święte, a nie ma ich w Kanbanie. Z kolei Sprinty googlowskie bardzo mocno kwestionują sensowność rzucania się w wir pracy i raczej pokazują, że rozwiązania trzeba przemyśleć, zaprojektować, a najlepiej zbudować prototyp i go przetestować. 

W praktyce widzimy, że mając wiedzę o różnych podejściach, możemy sobie bardzo płynnie sięgać, zapożyczać, przywoływać praktyki, anegdoty, pewne pryncypia wartości. Na koniec dnia, może to spowodować, że jesteśmy bliżej świadomego dostarczania wartości, a dalej od tego, że robimy coś, bo tak każe książka lub tak wypada coś zrobić. 

5. Stosuj alternatywne sposoby facylitacji współpracy

Wielu Scrum Masterów widzi bardzo zero-jedynkowo współpracę w zespole, czyli w sposób synchroniczny, gdzie wszyscy pracują jednocześnie nad jednym wątkiem. A przecież jest wiele innych metod pracy, np. praca indywidualna lub praca w podgrupach. Warto szukać technik facylitacji, które dają większą swobodę zespołowi i dają też lepszy efekt w danej jednostce czasu. 

Jako Scrum Master bądź osobą, która wspiera zespół w różnych modelach współpracy, dochodzenia do różnych decyzji, czy wypracowania różnych kawałków pracy typowej dla zespołu scrumowego.

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

Poprzez właściwy sposób rozumiemy faktyczne rozwiązywanie problemów. Samo prowadzenie Retrospektywy według jakiejś instrukcji wcale nie musi zapewnić, że zespół długofalowo będzie się usprawniał. 

Bardzo mocno rekomendujemy tutaj faktyczne zrozumienie problemu, a następnie szukanie kilku możliwych rozwiązań, przeanalizowanie ich plusów i minusów, ocenę ich skuteczności wybierając ostatecznie konkretną opcję oraz ustalając jakich efektów się spodziewamy. Określmy, po czym poznamy, że problem został rozwiązany, kiedy się tego spodziewamy? Wykonajmy taki eksperyment i sprawdźmy, czy uzyskaliśmy pożądany efekt. Jeśli nie to dlaczego? Jakie działania korygujące możemy zastosować?

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

Nowy rok to dobry czas na chwile refleksji i zastanowienie się co możemy poprawić. A jeśli potrzebujesz wsparcia w tym zakresie np. w postaci szkolenia lub szukasz mentora, to zapraszamy do kontaktu poprzez porządnyagile.pl/kontakt

Dodatkowe materiały

Zachęcamy Cię do pogłębienia tego tematu i zapoznania się z dodatkowymi materiałami:

Współpraca z nami

Jeśli w Twojej firmie planujecie jakieś wyjazdowe integracje czy spotkania z elementami edukacyjnymi w formie warsztatów i chcielibyście mieć w agendzie angażujące warsztaty, czy ciekawą prezentację inspiracyjną, to daj nam znać przez formularz porzadnyagile.pl/kontakt. Z przyjemnością podzielimy się z Wami swoją wiedzą i doświadczeniem, których tu nie mamy możliwości w pełni przekazać.

Dołącz do dyskusji o tym odcinku na naszych social mediach

Chcesz przeczytać transkrypcję naszej rozmowy w tym odcinku podcastu? Czytaj poniżej!

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ą Strory 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 kultu 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 takiego kultu 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 kultu 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 kultem 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? Czy czujesz się komfortowo 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 kultu 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 kultu 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 cargo kultu, 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 kultem 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.

Kuba: Jeśli odcinek ci się podobał zostaw lajka, to pomoże propagować te nagrania do kolejnych osób, które też mogą z niego skorzystać. Jeśli masz jakieś pytania lub uwagi zostaw komentarz pod odcinkiem. No i sprawdź, czy subskrybujesz nasz kanał, żeby dostawać powiadomienia o kolejnych odcinkach. 

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

 Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.

Daj nam znać co sądzisz o tym odcinku


Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany.

Newsletter „Porządny Agile”

.

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