Scrum Masterze, graj pauzą!

Każdy Scrum Master dysponuje rewelacyjną techniką, dzięki której zespół stanie się bardziej samodzielny. Szkoda, że tak rzadko jest ona wykorzystywana. Mowa o graniu pauzą i jej kuzynie – bierności. Możemy nawet powiedzieć, że jedna technika jest podstawowa, a druga – zaawansowana.

 

Gra pauzą

„Zawsze jak dochodzi do momentu przedstawienia się na szkoleniu i powiedzenia czegoś o sobie, mamy problem. Ktoś musi zacząć, a wiele osób nie chce być pierwsza. Ale w każdej grupie jest przynajmniej jedna odważna osoba, która – jak przestanę mówić – odezwie się i zacznie nam kolejkę. A jeśli powiem to, co powiedziałem przed chwilą, a potem zamilknę, to mamy praktycznie gwarancję, że ktoś faktycznie zacznie.”

Takim albo bardzo podobnym tekstem od wielu lat rozpoczynam sekcję „poznajmy się” na każdym prowadzonym przeze mnie szkoleniu Scrum i agile. Nie ma tu znaczenia forma prowadzenia zajęć – zarówno przy szkoleniach zdalnych, jak i stacjonarnych, działa to tak samo. Wydaje mi się, że składają się na to trzy czynniki, chociaż jestem świadom, że może to być  dorabianie ideologii.

Pierwsze dwie rzeczy to niezręczność wynikająca z pauzy i dość prosty sposób na jej przełamanie. Ja naprawdę przestaję mówić i czekam. Ciężar nie leży na mnie, tylko na uczestnikach. To nie ja „robię coś nie tak” – już się przedstawiłem i powiedziałem coś o sobie, teraz kolej na zgromadzonych. Presja rośnie więc z każdą sekundą i poczucie, że „chyba robimy coś nie tak” jest coraz większe. Jednocześnie przepis na przełamanie tego impasu i pozbycie się niezręczności został przekazany przez prowadzącego. Wszyscy dokładnie wiedzą co należy zrobić, żeby wrócić do normalności.

Dodatkowo, działa tu efekt psychologiczny w postaci zachęty dla osób lubiących się wyróżniać. „Odważna osoba” może chcieć pokazać innym, że jest odważna. Ktoś też może po prostu chcieć zabłysnąć albo nawet „mieć to już za sobą”. Niezależnie od powodów, to po prostu działa. Wystarczy zagrać pauzą.

 

Być jak Jordan Belfort

„Then you wait. You wait and whoever speaks first – loses.” – The Wolf of Wall Street

Okej, wcale nie chcemy zyskać miana Jordana Belforta agile’a. Nie chodzi o to, żeby ktokolwiek „przegrał”. Od dawna jednak mówię, że najlepsze studia dla Scrum Mastera to psychologia. A już na pewno warto, żeby to było nasze hobby, jeśli nasze scrummasterowanie traktujemy poważnie.

Pamiętajmy jednak, że wszystkie psychologiczne „sztuczki” i „triki” to tylko narzędzia. Dodatkowo, należy pamiętać, że tylko używając ich wielokrotnie możemy przekonać się, czy faktycznie działają. A działają.

Mówiliśmy o tym w filmie, który na naszym YouTube’owym kanale wylądował gdzieś za kanapą. „Wykorzystanie prawdopodobieństwa w agile’owym podejściu„, tak się bowiem nazywał, dotyczył dokładnie tego faktu. Jeżeli coś ma 80% szans na powodzenie, ale tę rzecz robimy tylko raz, to nijak tego prawdopodobieństwa nie zweryfikujemy. Albo się uda, albo się nie uda. Zupełnie inaczej sprawa się ma z eksperymentami powtarzalnymi lub atrybutami, które faktycznie da się zmierzyć – czas, energię, twardość materiału, etc.

Nauki społeczne, psychologia, teoria podejmowania decyzji, negocjacje – wszystkie te dziedziny nauki wymagają od nas wielu powtórzeń, żeby móc wyciągnąć jakieś wnioski. W rezultacie nie dostajemy jednak twardych danych czy pomiarów. Nie jesteśmy w stanie skwantyfikować chciwości, uległości czy odporności na sugestie. Ale możemy zobaczyć co działa, a co nie.

Ale chyba odbiegam od dzisiejszego tematu.

 

Scrum Masterze, graj pauzą!

Jako doświadczony Scrum Master bardzo często trafimy na sytuacje, w których my wiemy co zrobić, ale Scrum Team nie ma pojęcia. Bardzo często kusi opcja podania im rozwiązania na tacy. Wiadomo jednak, że lepiej sprawdzi się podejście coachingowe. Zadając odpowiednie pytania jesteśmy w stanie naprowadzić zespół na jedno z właściwych rozwiązań. Ba, czasem nawet zostaniemy zaskoczeni przez pomysłowość tegoż zespołu.

Inna alternatywa to oczywiście gra pauzą, gdzie nie mówimy nic. Rzucamy problem i patrzymy jak zostanie rozwiązany. Oczywiście, zwykle będziemy musieli jakoś naprowadzić zespół na właściwe tory, ale chciałbym dzisiaj zwrócić uwagę na sytuacje, w których naprawdę nie musimy nic mówić ani nawet nic robić. Pamiętajmy jednak o odpowiednich warunkach.

Zespół musi wiedzieć, jak coś zrobić, żeby gra pauzą była efektywna. To znaczy, jeżeli np. nauczymy wszystkich jak przebiega efektywne Planowanie Sprintu czy Retrospektywa, to wcale nie musimy za każdym razem prowadzić ani nawet zaczynać. Możemy po prostu zamilknąć i czekać. Skoro wszyscy wiedzą co trzeba zrobić, to w końcu ktoś to zacznie robić. I nie musi to wcale być proaktywny Scrum Master. Ta technika działa dla Daily Scrum, gdzie SM-a w ogóle nie ma. Dlaczego miałaby nie działać gdzie indziej?

Takie podejście możemy również zastosować dla poszczególnych aspektów Wydarzeń Scrum i innych stałych elementów gry.

Jeżeli zespół zauważy, że Backlog Sprintu jest jakiś taki mały i warto wziąć coś więcej, to nie szukajmy dla nich kolejnego elementu Backlogu Produktu. Pozwólmy im znaleźć go samodzielnie, nawet jeśli zajmie to kilka minut dłużej. Nie zapisujmy akcji po retro, „bo przecież jak tego nie zrobię, to o nich zapomnimy”. Działając w ten sposób uczymy zespół być niesamodzielnym. Grajmy pauzą gdzie się da, patrzmy czy zespół wie co warto zrobić i czy robi to sam z siebie.

Najpierw edukacja i świecenie przykładem, potem stopniowe wycofywanie się z prowadzenia spotkań i facylitacji. W skali makro mówiłem o tym lata temu w wystąpieniu pod tytułem „Czterogodzinny Scrum Master„. Zamiast grać pauzą – idźmy na inne spotkanie albo na urlop. Czy jeśli nie pojawimy się na Planowaniu to Zespół będzie przez cztery godziny siedział w milczeniu? Jeżeli tak, to jeszcze dużo pracy przed nami. Jeżeli nie, to przestańmy ich we wszystkim wyręczać i dajmy szansę się wykazać. Na przykład grając pauzą albo nieobecnością.

Tomasz Dzierżek

18 lat doświadczenia w IT, 10 lat doświadczenia w Scrum, PSM I-III, Scrum Master zespołów zwinnych, analityk IT, trener Scrum

Click Here to Leave a Comment Below

Leave a Reply: