Praca Scrum Mastera z narzekaniem
Pracując jako mentorka Scrum Masterów często się spotykam z przypadkami, kiedy Scrum Masterzy usiłują przekonać zespół, że jest nieźle (albo zmienia się na lepsze), a zespół dalej narzeka. Im silniej Scrum Master przekonuje, podaje przykłady, wchodzi w polemikę, tym bardziej przepaść pomiędzy nim a zespołem rośnie.
Dlaczego Scrum Masterzy tak postępują? Jest kilka powodów. Bardzo możliwe, że wkładając wiele pracy w zmianę środowiska, w jakim funkcjonuje zespół, przeceniają skalę zmian. Z ich punktu widzenia widać jaskółki poprawy, dla zespołu są to bardziej pierwotniaki niż ptaki. Owszem, pod mikroskopem widać, ale ogólnej sytuacji to nie zmienia. Często chcą być liderem i pokazać, jak można pozytywnie podchodzić do trudności. Najczęściej jest za tym wyłącznie pozytywna motywacja, jedyny problem jest taki, że to nie działa.
Im bardziej Scrum Master tłumaczy, że jest dobrze, tym bardziej się oddala od zespołu. A podstawą pracy z zespołem jest przyjęcie ich perspektywy i praca z jej poziomu. Dlatego podawanie przykładów zmiany na lepsze nie ma sensu, bo zespół prawdopodobnie jest w stanie podać przykłady, że jest po staremu, a nawet gorzej. Co w takim razie można zrobić?
Przede wszystkim zachować autentyczność, ciekawość i uważność na drugiego człowieka. Jak to wygląda w praktyce? Oto krótka scenka z omówieniem. Oczywiście słownictwo należy dopasować do swojego stylu mówienia i zwyczajów zespołu.
Dominik (deweloper): Znowu się wysypał build. W tej firmie nic nie działa.
Sebastian (Scrum Master): Serio?! To irytujące, że musisz nad tym siedzieć, zamiast zająć się czymś sensownym.
Czyli pierwszym krokiem jest automatyczne przyjęcie perspektywy rozmówcy, dostrzeżenie trudności, jakie napotyka i emocji, jakie mu towarzyszą oraz wykazanie się współczuciem (rozumianym jako angielskie compassion, a nie litość).
D: Tak jest ciągle, tracę na to kilka godzin tygodniowo.
S: Cholera, myślałem, że jest już trochę lepiej. Który raz w tym tygodniu to się zdarza?
Nadal pozostajemy w perspektywie rozmówcy, z ciekawością i troską dowiadując się, jakie są jego doświadczenia. Jednocześnie jesteśmy blisko siebie i możemy pokazać, że mieliśmy inne wyobrażenie o tym samym problemie.
To jest taki moment, kiedy może się zadziać jedna z dwóch rzeczy. Opcja pierwsza – Dominik uświadamia sobie, że to wcale nie było tak często.
D: No w tym tygodniu to pierwszy raz. Ale to jest spieprzone, trzeba to zaorać.
S; No to dobrze. Dasz znać zespołowi, jak będzie więcej problemów ze środowiskiem? To poważny problem i jeśli znowu narośnie, to powinniśmy się nim zająć jako cały zespół.
Czyli w przypadku, kiedy ktoś przesadził w ocenie problemu, zajmujemy się jego emocjami i dążymy do tego, żeby na poziomie autorefleksji skorygował swoje przekonania. Nie drążymy tematu, pozwalamy mu zachować twarz i pokazujemy swoją postawą, że traktujemy go poważnie i chcemy zajmować się rzeczami, które mu przeszkadzają.
Scrum Master a jakość
Opcja druga – buildy sypią się często.
D: Trzeci raz w tym tygodniu, a jest środa. Wczoraj siedziałem nad tym dwie godziny.
S: To naprawdę długo, musisz być sfrustrowany tym, że poświęcasz czas na takie rzeczy, zamiast zająć się kodowaniem. Szczególnie, że mamy w tym Sprincie ciśnienie. Wiesz co? Fajnie, że mamy Cię w zespole. Mimo, że Cię to wkurza, to za każdym razem jednak Ty wygrywasz, a nie build serwer.
Ta rozmowa jest znowu na poziomie czysto ludzkim – dostrzeżenia i uprawomocnienia emocji, docenienia wysiłku i pokazania, co on dla nas oznacza. W tej sytuacji rolą Scrum Mastera jest przeniesienie problemu na płaszczyznę zespołową.
Sebastian do zespołu: Dominik mówi, że trzy buildy mu się wysypały w tym tygodniu. A jak to wygląda u Was?
Celem jest komunikacja z zespołem, poznanie ich perspektywy. Oczywiście, że to można sprawdzić w narzędziu, ale nie o to chodzi.
Jeśli zespół nie potwierdzi obserwacji Dominika:
S: Dominik, masz pecha w tym tygodniu. Może powinniśmy Ci wspólnie postawić piwo, bo ściągasz wszystkie niepowodzenia na siebie? Głupio, żebyś został z tym sam. Powiesz nam, jak znowu Ci się to zdarzy? W dwie osoby będzie łatwiej wymyślić, jak ten problem rozwiązać kompleksowo.
Jako Scrum Master należy mieć z tyłu głowy opcję, że to jakiś błąd Dominika powoduje problemy. On o tym też pomyśli i pewnie sprawdzi, zanim poprosi kogoś z zespołu o wspólne przyjrzenie się problemowi. Jeśli nie, to pewnie druga osoba zobaczy co jest przyczyną. Takie działanie SM wspiera zespołowość, nie zostawia ludzi samych z problemami, jakich doświadczają (nawet jeśli sami je wywołali), i dąży do rozwiązania problemu.
A co, jeśli reszta osób potwierdzi problem? Wtedy trzeba zespołowi zadać kilka pytań (pominęłam odpowiedzi zespołu):
S: Czy mamy wystarczająco dużo informacji, żeby teraz poszukać rozwiązania?
S: Kto z Was chce rozkminiać ten problem?
S: OK, to wrzucam spotkanie na 15 dla Pawła, Dominika i Izy. Czy warto, żebyśmy coś przygotowali przed spotkaniem? Może wyciągnę jakieś dane?
Jest wysoce prawdopodobne, że zespół nie będzie chciał się problemem zająć od razu. Wtedy praca idzie w przygotowanie zespołu do rozwiązania problemu.
S: Czy chcemy się tym problemem zająć na najbliższym retro?
S: Jakie dane potrzebujemy sobie przygotować, żeby się tym skutecznie zająć?
S: Czy chcemy kogoś doprosić, żeby skuteczniej to rozwiązać?
S: To ja przygotuję te dane i pokażę Wam dzień przed retro, żebyśmy zweryfikowali, czy to wszystko.
Jeśli się okaże, że części informacji nie mamy, bo nie da się ich wyciągnąć z narzędzia?
S: Zastanawiam się, jak najmniejszym kosztem możemy te informacje zebrać. Chciałbym, żeby Wam to zajmowało mniej niż 30 sekund na incydent. Może założę kanał na slacku i każdy, kto miał problemy z build serwerem napisze tam możliwie krótko, co się stało? Czy to będzie wystarczająco wygodne dla Was? Pozwoli nam to zdiagnozować, ile jest kategorii problemów?
W całej tej historyjce widać, że Scrum Master ani razu nie wchodzi w polemikę, nie przekonuje ani nie zaprzecza. Traktuje ludzi poważnie i z szacunkiem. Jest liderem, ale nie przez unieważnianie odczuć zespołu. Jest liderem procesu rozwiązywania problemu. Liderem służebnym, nie zawłaszczającym tematu, ale katalizującym proces i pozwalającym podjąć zespołowi decyzję czy i jak chce problem rozwiązać. Taka postawa jest zgodna z odwagą, skupieniem, szacunkiem, zaangażowaniem i otwartością.
[grafika: Dall-e2, Open Ai]
