3 błędy Scrum Masterów i jak je naprawić
Bycie Scrum Masterem może być naprawdę trudnym zadaniem.
Jeśli dajesz zespołowi zbyt wiele porad i pomocy, zespół wkrótce przyzwyczai się do tego, że Scrum Master wszystko mu podaje. Jeśli jednak dajesz zespołowi zbyt mało pomocy, rozwija się on wolniej, niż mógłby. Rozwiąż kilka problemów za zespół, a wkrótce będzie się od Ciebie oczekiwać rozwiązania każdego problemu. Jeśli jednak nie rozwiązujesz problemów zespołu, członkowie zespołu w pewnym momencie przestają nawet informować Scrum Mastera o swoich przeszkodach i problemach.
Scrum Masterzy chodzą po cienkiej granicy i łatwo popełniać błędy. W tym artykule opisano trzy błędy, które Scrum Masterzy często popełniają, i dla każdego z nich zaproponowano krótkie rozwiązanie.
1) Pozwalanie, by praca przelewała się do następnego Sprintu
Pierwszym błędem jest moim zdaniem jeden z najgorszych nawyków, jaki może rozwinąć zespół: przenoszenie pracy z jednego Sprintu do następnego.
Dzieje się to, gdy zespół nie kończy wszystkich Product Backlog Items zaplanowanych na Sprint i po prostu przenosi tę pracę do następnego Sprintu.
Żeby nie być źle zrozumianym: od czasu do czasu zdarza się, że zespół nie ze wszystkim skończy. W rzeczywistości jest to nawet dobry znak, gdy czasami tak się dzieje. Oznacza to bowiem, że zespół stawia sobie ambitny plan i nie planuje zbyt mało pracy na Sprint z obawy przed nieukończeniem wszystkiego.
Jednak Scrum Master nie powinien traktować jako drobnostki sytuacji, gdy zespół nie kończy zaplanowanych prac, bo inaczej Sprinty stają się sztucznymi i pozbawionymi znaczenia granicami. Zespoły powinny odczuwać lekką presję, gdy zbliża się koniec Sprintu. Zespół powinien myśleć: „Och, Sprint kończy się jutro. Muszę dziś naprawdę skupić się i skończyć."
Jeśli przenoszenie pracy do następnego Sprintu jest problemem w Twoim zespole, istnieje kilka rzeczy, które możesz zrobić:
Po pierwsze, musisz pozbyć się tego złego nawyku. Zachęć członków zespołu do planowania następnego Sprintu w taki sposób, aby definitywnie ukończyć wszystkie prace. To znaczy, że powinni podejść do tego spokojnie i zaplanować następny Sprint z pewną ostrożnością. Jeśli wszystko pójdzie dobrze, można włączyć więcej prac do Sprintu.
Możesz też spróbować sprawić, że zespół poczuje się trochę winny, gdy nie wszystko zostanie zrobione. Nie chodzi o to, żeby ktoś naprawdę czuł się źle. Członkowie zespołu powinni mieć tylko takie wyrzuty sumienia jak ja teraz. Bo staram się nie pić już tyle napojów gazowanych. Robię postępy i od tygodnia żadnego nie wypiłem. Ale dziś, kiedy pisałem ten artykuł, jakoś miałem na to ochotę. Więc pozwoliłem sobie na jeden. Nie czuję się przez to źle, ale jutro zdecydowanie nie chcę pić kolejnego, żeby nie wpaść z powrotem w stare nawyki.
2) Prowadzenie Daily Scrumów
Drugim błędem, który często obserwuję u Scrum Masterów, jest przejmowanie przez nich prowadzenia Daily Scrumów. Oczywiście Scrum Master powinien uczestniczyć w Daily Scrumach i sam składać aktualizacje. Jednak Scrum Master nie musi prowadzić spotkania, wciąż wzywając członków zespołu do uczestnictwa itp.
Scrum Master powinien wyjaśnić zasady i cel Daily Scruma, poprowadzić pierwsze dwa-trzy spotkania i zachęcać ludzi do uczestnictwa. Potem jednak powinien pozwolić, by zespół sam prowadził Daily Scrumy.
Aktywności Daily Scruma nie są szczególnie trudne. Nie jest potrzebny żaden „policjant" regulujący wszystko, bo gdyby Scrum Master prowadził spotkanie w ten sposób, dyskusja skupiałaby się zbyt mocno na Scrum Masterze.
Lubię zaczynać z nowym zespołem w taki sposób, że zdecydowanie sam moderuję pierwsze spotkania. Potem mówię tylko „Ok ludzie, czas zaczynać" i może pytam, kto chce zacząć. Ale wkrótce przestaję nawet to robić.
Po kilku spotkaniach zaczynam ostentacyjnie patrzeć na zegarek, gdy nadchodzi czas rozpoczęcia spotkania. W razie potrzeby chrząkam wystarczająco głośno, aby wszyscy rozumieli, co się dzieje. A potem po prostu stoję cicho, dopóki ktoś nie powie: „Myślę, że powinniśmy zaczynać". Po kilku dniach patrzenia na zegarek i chrząkania idę o krok dalej i patrzę tylko na zegarek, gdy nadchodzi czas rozpoczęcia. I znowu po kilku dniach przestaję nawet to robić. Po prostu stoję i czekam, aż spotkanie się rozpocznie.
Oczywiście nie milczę przez całe spotkanie. W pewnych okolicznościach muszę kogoś coachować, by podawał więcej szczegółów, albo uprzejmie kogoś przerywam i sugeruję, czy nie lepiej byłoby zająć się szczegółami po Daily Scrumie.
Wyobraź sobie, że ja (lub inna obca osoba) byłbym na Twoim Daily. W takim przypadku nie powinno być możliwe samym obserwowaniem ustalenie, kto jest Scrum Masterem w zespole. Oczywiście od czasu do czasu zdarzy się, że Scrum Master powie coś, co powiedziałby tylko Scrum Master. Nie powinno to jednak zdarzać się stale.
3) Doprowadzanie zespołu do wypalenia zawodowego
Nie jestem wielkim fanem większości terminologii Scrumowej, ale termin Sprint jest szczególnie problematyczny. Gdy biegnę sprintem, szybko się męczę i muszę regularnie robić przerwy. To dość kiepska metafora dla zespołu.
Sprint się kończy i zaczyna następny. Zespoły nie powinny zaczynać kolejnego Sprintu, gdy wciąż dochodzą do siebie po poprzednim. Zamiast tego powinny pracować w zrównoważonym tempie, które za sprawą Kenta Becka stało się znane jako Sustainable Pace (zrównoważone tempo).
Trzecim błędem, który często widzę, jest to, że Scrum Masterzy często pozwalają swoim zespołom przekraczać to zrównoważone tempo i zmierzać ku wypaleniu zawodowemu. Dobry Scrum Master powinien uważnie obserwować i w razie potrzeby chronić zespół przed wypaleniem.
Wiele zespołów jest nastawionych optymistycznie i ten optymizm przekłada się na ilość pracy, którą planują na Sprint. Scrum Masterzy powinni być czujni i doradzać zespołom ostrożność, gdy podczas Sprint Planningu grozi im wzięcie na siebie więcej zobowiązań, niż zdołali zrealizować w poprzednich Sprintach. Dlaczego? Bo nawet jeśli wszystkie prace w Sprincie da się jeszcze ukończyć, zespół ryzykuje, że rozpocznie kolejny Sprint wyczerpany i z nadmiernym optymizmem co do ilości pracy. W pewnym momencie zespół nie będzie mógł utrzymać zrównoważonego tempa i „wypali się". Dobrym sposobem ochrony zespołu przed taką sytuacją jest tworzenie przestrzeni, w których sami mogą zdecydować, nad czym chcą pracować.
6 x 2 + 1
Chętnie do tego używam metody, którą nazywam „6 x 2 + 1". Odnosi się to do sześciu dwutygodniowych Sprintów plus jednego tygodniowego Sprintu na samym końcu. Członkowie zespołu mogą wtedy sami zdecydować, nad czym chcą pracować w tym ostatnim Sprincie. Niektóre osoby wykorzystują ten czas na osobisty rozwój (czytanie książki, szkolenie wideo itp.). Inne korzystają z czasu na refaktoryzację brzydkiego kodu, który nie został spriorytetyzowany przez Product Ownera. Jeszcze inni mogą próbować eksperymentu, który ich zdaniem mógłby prowadzić do świetnej nowej funkcji. Wszystko to zespół może zdecydować samodzielnie.
Wprowadzenie takiego cyklu może jednak przynieść znacznie więcej korzyści. Na przykład Product Owner zyskuje w ten sposób cały tydzień bez „przerywania" przez zespół. I właśnie to jest często najlepszym argumentem sprzedażowym, żeby przekonać Product Ownera do tego pomysłu.
Ten cykl może być też korzystny dla całej organizacji, gdy konieczne jest podejmowanie zobowiązań, np. „Musimy dostarczyć tę funkcję za 3 miesiące!" 13. tydzień cyklu 6 x 2 + 1 Sprintów może być też użyty jako normalny Sprint, jeśli zespół ma opóźnienia względem terminu. Jeśli zespołowi uda się następnie dotrzymać terminu, zawsze można im zaproponować tygodniowy Sprint do swobodnego dysponowania.
Dowiedz się więcej o tych kwestiach na naszych szkoleniach dla Scrum Masterów i w ciągu trzech dni opanuj tę zwinną rolę oraz naucz się odpowiedzialności jako Servant Leader.
