Każdy z nas popełnia błędy. Najważniejsze, aby je rozpoznawać i móc się na nich uczyć. Dzisiaj przygotowałem dla was mój subiektywny spis kilku najczęściej popełnianych przez Scrum Masterów błędów. Sam popełniłem je wszystkie, a niektóre wielokrotnie! 🙂
1. Nadmierna kontrola
Każdy z nas ma jakieś wyobrażenie tego idealnego, płynnie działającego zespołu, gdzie praca idzie jak po maśle, ze stabilną prędkością, a zespół dostarcza wspaniałą wartość i reaguje zwinnie na zmieniające się potrzeby użytkowników. Rzadko jednak udaje nam się taki stan osiągnąć w praktyce. Czasem pragniemy tak bardzo tam dojść, że każde, nawet najdrobniejsze niepowodzenie czy odstępstwo od ‘prawdziwej północy’, traktujemy jako okazję do wnikliwej analizy i wprowadzenia akcji naprawczych.
Jeśli usprawnienia nie przynoszą oczekiwanych przez nas rezultatów, to pojawia się pokusa zwiększenia swojej ingerencji w pracę zespołu.
Symptomy:
- “A co się dzieje z tym zadaniem? Czemu tak długo wisi na tablicy? Przecież wprowadziliśmy pomiar czasu życia zadań.”
- “Zapytałeś się w drugim zespole na kiedy to będzie? Skąd ten bloker?
- “Zaplanowaliście 15 itemów w sprincie, a tymczasem średnia przepustowość to 12.”
Nadmierna kontrola może faktycznie pomóc wypracować pewne nawyki, ale będą to te niewłaściwe. Zespół może się przyzwyczaić, że zawsze jest ktoś, kto skontroluje sposób pracy, dopyta o opóźnienia, blokery, metryki - więc sami członkowie nie będą się musieli już o to martwić.
Jak to naprawić: Porozmawiaj otwarcie z zespołem o swojej roli. Czego potrzebują od ciebie, a czego ty od nich. Możecie też wspólnie zdiagnozować na jakim etapie rozwoju samoorganizacji jesteście i gdzie są obszary, w których faktycznie przyda się twoja większa uwaga. Porozmawiajcie też o wspólnej wizji idealnego zespołu - aby nie była to tylko twoja ‘prawdziwa północ’.
2. Metryki jako cele
“Każda obserwowana statystycznie zależność ma skłonność do zawodzenia, w momencie w którym zaczyna być wykorzystywana do celów regulacyjnych” - prawo Goodharta
Proces empiryczny, czyli podstawa zwinnych metod (w tym Scruma) nie może działać bez zastosowania miar. Każda inspekcja elementów procesu wiąże się ze zmierzeniem czegoś i podjęciem decyzji co do dalszych działań (adaptacji).
Same metryki nie wystarczą jednak, by móc ulepszać proces. Potrzebny jest jeszcze cel!
Jakiś czas temu, przy rozpoczynaniu pracy z nowymi zespołami, wprowadzałem podstawowe metryki, które potem przeglądaliśmy w czasie retrospekcji. Moim zamiarem było zachęcenie zespołu do oparcia rozmowy o dane, jako uzupełnienie tego co się działo w sprincie. Na wstępie retrospekcji chciałem, abyśmy sprawdzali metryki, które mogą generować tematy/problemy do omówienia, czy pozwolić ocenić efektywność eksperymentów. Czyli jeśli np. wzrasta nam cycle time, ilość WIP, to należałoby rozpocząć dyskusję o efektywności przepływu i wąskich gardłach. I tak też starałem się to wyjaśnić zespołowi.
Symptomy: Zespół proponuje różne metody by 'zhakować' metrykę (np. zamykanie zadań z dopiskiem 'testy później')
Mój eksperyment zbiegł się w czasie z informacją od managementu, że “dobrze by było”, aby cycle time dla historyjek był mniejszy niż 2 tygodnie, a dla całych funkcjonalności - mniejszy niż 90 dni. Ludzie w zespołach bardzo szybko zaczęli się obawiać, że będą jakoś rozliczani z tego jeśli te normy przekroczą, a moje prezentowanie tych metryk co retrospekcję jest elementem kontroli ze strony managementu. Na nic się zdały tłumaczenia, że jest to coś dla nas, a management daje tylko pewne sugestie. Zamiast traktować metrykę jako coś dodatkowego, zaczęli traktować ją jako cel sam w sobie.
Jak to naprawić: Patrząc na tę sytuację z perspektywy czasu, moim największym błędem było narzucenie metryk zespołom na starcie. Teraz najpierw wyklaryfikowałbym misję i cele zespołu, by do tego dobrać metryki (np. przy pomocy GQM), a nie zastosować te rzeczy, które już znałem i sądziłem, że “na pewno” nie zaszkodzi obserwować.
3. Nadopiekuńczość
Opieka nad zespołem jest szczególnie ważna w początkowych fazach jego rozwoju. To wtedy głównym zadaniem Scrum Mastera jest zbudowanie bezpieczeństwa psychologicznego. A to z kolei potrzebne jest by członkowie zespołu mogli się otworzyć na to, co ich różni oraz aby zaufali sobie na tyle, aby nie obawiać się konfliktów. Jednak kiedy ta opieka przeradza się w nadopiekuńczość, zespół może nigdy nie osiągnąć swojego pełnego potencjału.
Opowiadając ostatnio na Agile4Good o stylach przywództwa według D. Golemana wspomniałem o stylu afiliacyjnym jako tym, którego ciemną stroną (kiedy się go nadużywa) może być właśnie sytuacja, gdzie zespół bardziej skupia się na tym, aby panowały dobre relacje niż na osiąganiu rezultatów. Dobre relacje są oczywiście podstawą do efektywnej pracy, jednak nie mogą być celem samym w sobie w przypadku zespołu, który chce realizować cele i wykorzystać swój potencjał - który to ujawnia się także w konflikcie.
Symptomy: Trudne tematy są omijane przez zespół szerokim łukiem. Nie spełnianie wzajemnych oczekiwań (“ustalamy, że zrobimy to tak i tak, a ktoś się wyłamuje”), nie niosą ze sobą żadnych konsekwencji. Jeśli zdarzają się błędy, to zespół (lub lider wewnętrzny) reaguje defensywnie (“no tak, zdarzyło się, ale zaraz naprawiliśmy, a poza tym to wymagania były słabe i były problemy ze środowiskiem”). Jako Scrum Master, lądujesz na pozycji sekretarki i organizatora spotkań. Do tego większość komunikacji na zewnątrz zespołu ląduje na twojej głowie (“bo przecież ty to zrobisz lepiej”).
Jak to naprawić: Jeśli zespół przyzwyczai się do bycia wyręczanym i chronionym przed wszystkim, co niewygodne, to będzie to bardzo ciężko zmienić. Można poprosić kogoś z zewnątrz do zorganizowania sesji coachingu zespołowego, porozmawiać o tym jaka jest otwartość zespołu na konflikt i jak widzą rolę Scrum Mastera. Alternatywnie, można porozmawiać indywidualnie z członkami zespołu (jeśli w szerszym gronie jest trudno uzyskać otwartość), podzielić się swoją obserwacją i zapytać o radę.
Najlepiej jednak zapobiegać - stopniowo ograniczać swoje wsparcie jako Scrum Master i pokazywać jak członkowie zespołu mogą sami sobie radzić z problemami.
4. Zaborcza facylitacja
Wyobraź sobie, że facylitujesz retrospekcję. Moderujesz dyskusje i w pewnym momencie czujesz, że chcesz się podzielić swoimi obserwacjami, jakimś przemyśleniem. Chcesz zwrócić uwagę zespołu na coś, czego wydają się nie dostrzegać. W końcu ty, jako Scrum Master, jesteś trochę z boku i widzisz więcej.
Bardzo łatwo jest, będąc samemu facylitatorem, przejąć w takiej sytuacji stery dyskusji i pokierować ją tak, aby osiągnąć swój własny cel. W końcu kto ma ‘mikrofon’, ten ma władzę 🙂 Tylko wtedy przestajemy być facylitatorem, a stajemy się uczestnikiem - ze swoimi celami, pragnieniami i punktem widzenia. Czasem trudno jest rozgraniczyć nam, w którym momencie zakładamy czapeczkę ‘facylitatora’, a w którym ‘uczestnika’.
Symptomy: Stopniowo, prowadzone przez ciebie spotkania zaczyna wypełniać cisza. Coraz mniej osób się odzywa, a ty dyskusja przypomina po prostu twoją wymianę zdań z kilkoma najbardziej aktywnymi osobami, mającymi przeciwne od twojego zdanie na dany temat. Coraz mniej rezultatów spotkania (np. z retrospekcji) jest podejmowanych przez uczestników, a większość bierzesz ty (bo przecież sam je zaproponowałeś, prawda?).
Jak to naprawić: Jeśli facylitujesz i chcesz jednośnie brać udział w dyskusji, bardzo jasno zaznaczaj te momenty, w których zmieniasz czapeczkę z facylitatora na uczestnika. Możesz to też tak zmienić formę spotkania, aby była spotkanie było bardziej ‘samozarządzające się’ - np. poprzez zastosowanie liberating structures (1-2-4-all chociażby). Wtedy niejako możesz ograniczyć swoją rolę do osoby trzymającej time-boxy. Alternatywnie, możesz poprosić kogoś innego o facylitację (spoza zespołu lub rotować facylitatora wewnątrz zespołu).
5. Pycha
Dopada zarówno tych z dużym doświadczeniem, jak i początkujących. Sam miałem wiele takich sytuacji, gdzie wszystko we mnie krzyczało: “sto razy widziałem już taką sytuację, a wy chcecie popełnić ten sam błąd po raz sto pierwszy!”.
Łatwo jest nam przekonać siebie, że wszystko byłoby lepsze, gdyby tylko ludzie słuchali naszych trafnych rad, albo że jesteśmy w stanie poradzić sobie z każdym problem samemu. Stąd już krótka droga do tego aby poczuć się lepszym od innych, a to z kolei może prowadzić do pogardy - jednej z najbardziej toksycznych emocji.
Symptomy: Ludzie coraz rzadziej przychodzą do ciebie z problemem czy pytają się o twoje zdanie. Wiedzą prawdopodobnie, że dasz im kolejną przemowę, gdzie z profesorskim zacięciem wyjaśnisz dokładnie jak powinno być coś zrobione, bo przecież ten sam problem wystąpił u X innych zespołów. Lub, co gorsza, zaczniesz im zadawać naprowadzające pytania (mając już w głowie rozwiązanie), które jeszcze dobitniej pokaże im, że przecież gdyby tylko chcieli, mogliby sami sobie pomóc.
Jak to naprawić: Nie jest ważne to, że problem wydaje ci się znajomy i instynktownie chcesz sięgnąć po rozwiązanie. Każda osoba, zespół czy organizacja zasługuje na to, aby potraktować ich wyzwanie z otwartym umysłem, bez oceniania. Zainwestuj w nawyk aktywnego słuchania. Wyłącz osąd, zadawaj otwarte, niesugerujące pytania mające na celu zrozumienie przez ciebie problemu (a nie nakierowanie na rozwiązanie).
Jak mawiają doświadczeni Scrum Masterzy: “kiedy zawodzi feedback, włącz aktywne słuchanie.“
6. Nie rozwijanie inteligencji emocjonalnej
Czasem nie zdajemy sobie sprawy, jak ważny jest ten zestaw kompetencji w pracy Scrum Mastera. W skład inteligencji emocjonalnej wchodzą takie kompetencje jak: samoświadomość, samokontrola, empatia, asertywność, budowanie relacji czy zdolność do adaptacji.
W swojej słynnej książce Daniel Goleman poświęca cały rozdział kosztom analfabetyzmy emocjonalnego - zarówno u dzieci jak i później u dorosłych. Większość z nas (przynajmniej z mojego pokolenia lat osiemdziesiątych) nie uczyło się o tym jak ważne jest radzenie sobie ze swoimi emocjami w konstruktywny sposób. W tamtych czasach to raczej iloraz inteligencji był “na topie”. A nadrabianie zaległości jest (przynajmniej u mnie) bardzo długotrwałym i żmudnym procesem.
Osobiście jestem człowiekiem, który uwielbia wszelkiego rodzaju procesy. Nawet interakcje międzyludzkie postrzegałem jak zazębiające się trybiki fascynującej maszyny. Cechy te pozwoliły mi świetnie mapować i usprawniać procesy w organizacjach, a jednocześnie zupełnie nie przygotowały mnie do budowania więzi wewnątrz zespołowych. Rozwijając się jako Scrum Master musiałem najpierw zauważyć swoje braki w tym obszarze - dzięki kilku osobom, które dostarczyły nieoceniony feedback w kluczowych momentach - a następnie, stopniowo, budować w sobie te nowe kompetencje.
Symptomy: Nie jest łatwo samemu takie rzeczy zdiagnozować. Możesz zauważyć na przykład takie sytuacje, jak:
- Mimo twojego zaangażowania, wysokich standardów pracy, dużych oczekiwań wobec siebie i zespołu, ludzie odchodzą.
- Zauważasz wśród zespołu obawę przed przyznaniem się do błędu, poruszaniem trudnych tematów - być może boją się ciebie zawieść lub nie spełnić twoich oczekiwań
- Łatwiej przychodzi ci zauważenie pomyłek, niedociągnięć w pracy (swojej i innych) niż tylko docenienie pozytywnych stron
- Po błędach czy porażkach zdarza ci się długo “mielić” daną sytuację, stawiać sobie wyrzuty i przypisywać to swoim negatywnym cechom charakteru
- Często podejmujesz decyzje pod wpływem chwili (a więc emocji, które w danej sytuacji się wyzwalają)
Jak to naprawić: Nie ma szybkiego sposobu. Dobrze zacząć od zebrania informacji zwrotnej od zaufanych osób i przeczytania kilku pozycji opisujących kompetencje inteligencji emocjonalnej. Następnie wyznaczyć sobie długotrwałe cele rozwojowe i zacząć je realizować. Ja na sobie stosuję kombinacja coachingu, proszenia o informację zwrotną oraz świadomą (i regularną) analizę swoich emocji.
A jeśli nie wiesz od czego zacząć, zacznij od empatii 🙂