Blog

Drogi Scrum Masterze!

Jako trener Scruma, doradca i coach zajmujący się Scrumem od lat miałem okazję pracować z ponad tysiącem Scrum Masterów w różnych organizacjach. Widzę pojawiające się stale te same problemy i błędy w rozumieniu tej roli. Dlatego zwracam się do Scrum Masterów tym listem, w nadziei, że wyjaśni on pewne kwestie – i że weźmiesz go sobie do serca.

1. Nie jesteś szefem! Nie jesteś kierownikiem! Nie jesteś brygadzistą!

W szczególności nie jest Twoim zdaniem zapewnienie, że zespół dostarczy („dowiezie”) wszystko, do czego się zobowiązał na planowaniu sprintu. Nie jest Twoim zdaniem odbieranie raportów od pracowników i koordynowanie ich pracy tak, by zdążyć na wyznaczony termin. Nie jesteś również odpowiedzialny za to, by wszyscy ciężko pracowali – w związku z tym nie jest Twoim zadaniem sprawdzanie, czy ludzie się nie obijają ani dyscyplinowanie obiboków. Nie jest też Twoim zadaniem rozdzielanie pracy. ani zapewnianie, że jest ona rozdzielona sprawiedliwie i w sposób, który czyni najlepszy użytek z umiejętności i doświadczenia ludzi w zespole.

Twoja odpowiedzialność to formowanie, tworzenie zespołu, który będzie dbał nie tylko o większość z tych rzeczy, ale i wiele innych spraw niezbędnych, by dostarczyć dobry produkt.

To bardzo duża różnica. Dobrą analogią jest trener drużyny sportowej. Podczas meczu trener siedzi na ławce i nikt nie spodziewa się, że będzie sterował graczami. Jego odpowiedzialnością było stworzenie drużyny, która następnie poradzi sobie na boisku – a nie kierowanie każdym z graczy.

2. Żadne ze spotkań w Scrumie nie jest dla Ciebie. Nie masz być w centrum uwagi na żadnym z nich.

W szczególności Daily Scrum to nie jest codzienny raport dla Ciebie. Jeśli stoisz w środku i wszyscy patrzą na Ciebie kiedy mówią, to robisz to źle. Z kolei przegląd (Sprint Review), to nie jest miejsce na pokazywanie statystyk zespołu i wykresów spalania (burndown). Przegląd polega na pokazaniu działającego produktu klientom. Wspomniałem już, że nie masz być w centrum uwagi? Tyczy się to także przeglądu, nie powinieneś być osobą, która mówi na nim najwięcej. Najlepiej żebyś ograniczał się do moderowania spotkania (czyli zapewniania, że dyskusja będzie skupiona na temacie i efektywna), podczas gdy Product Owner i zespół są gospodarzami i rozmawiają z klientami, użytkownikami itp.

Jeśli masz wątpliwości co do tego, do czego służą Daily Scrum i przegląd sprintu, przeczytaj ponownie Scrum Guide albo przejdź się na szkolenie prowadzone przez wykwalifikowanego, doświadczonego trenera.

3. Nie jesteś także sekretarzem zespołu.

Fakt, że zespół „robi Scrum”, a Ty zostałeś wybrany/nominowany/wrobiony w bycie jego Scrum Masterem, nie oznacza, że automatycznie to Ty masz rysować wykresy spalania, przesuwać karteczki na tablicy i aktualizować wszelkie inne „scrumowe narzędzia”. Możesz robić niektóre z tych rzeczy, jeśli uznasz to za właściwe w danej sytuacji (zwłaszcza pracując z nowym, niedoświadczonym zespołem), ale nigdy nie pozwól na to, by zespół zaczął uważać, że robienie tych rzeczy to jest właśnie Twoje zadanie, Twój obowiązek jako Scrum Mastera.

To mogłoby ich utwierdzić w fałszywym przekonaniu, że wszystkie te narzędzia i wykresy są dla Ciebie – albo dla procesu, dla kierownictwa itp. – podczas gdy, tak naprawdę są one przeznaczone dla nich, dla zespołu, który wspólnie biegnie (sprintuje?) by osiągnąć cel Sprintu. Twoje zadanie to dopomóc im w uświadomieniu sobie właśnie tego.

4. Nie jesteś liderem technicznym. Ani architektem.

Być może jesteś świetnym programistą z ogromnym doświadczeniem, także w pracy z tym produktem, ale to, że jesteś teraz Scrum Masterem nie daje Ci żadnej władzy decydowania o tym, jak produkt będzie zaprojektowany i zaprogramowany. W szczególności nie jest Twoim obowiązkiem jako Scrum Mastera robienie przeglądów kodu lub (co gorsza) zatwierdzanie kodu lub projektów, odpowiadanie na techniczne pytania, czy podejmowanie jakichkolwiek technicznych decyzji. Tak postępując jako Scrum Master, bardzo szybko zdegenerowałbyś tą rolę do roli typowego, tradycyjnego „lidera technicznego”, utrudniając skutecznie zespołowi zdrową samoorganizację.

Scrum nie zabrania pełnienia jednocześnie i w tym samym zespole roli Scrum Mastera i dewelopera. Jeśli tak się zdarzy, musisz bardzo starannie wyważyć te dwie role i zadbać o to, by było całkowicie i absolutnie jasne w każdej sytuacji, czy w danej chwili wypowiadasz się i działasz jako Scrum Master, czy jako jeden z deweloperów. Zwykle okazuje się to w praktyce dużo trudniejsze, niż na pierwszy rzut oka – właśnie dlatego to nie jest zalecany model. Szkoda, że wiele firm uczyniło z tego wręcz standard, w ten sposób pozbawiając się w wielu przypadkach korzyści, jakie mogłyby im dawać dobrze działające zespoły scrumowe.

5. Nie jesteś rzecznikiem zespołu. Ani przekaźnikiem informacji dla zespołu.

Jak było to podkreślone powyżej, Scrum Master wspomaga zespół w rozwoju i chroni od zakłóceń tego procesu popychając zespół ku lepszej i mądrzejszej pracy. Nigdy jednak nie wykonuje pracy za zespół. A wbrew temu, co niektórzy mogą na ten temat sądzić, praca deweloperów – programistów, testerów, analityków i innych – nie polega na klepaniu kodu przy komputerach popijając napoje o dużej zawartości kofeiny. Przeciwnie, duża część tej pracy to komunikowanie się, najlepiej twarzą w twarz nie tylko w zespole, ale także z innymi zespołami, Product Ownerem, użytkownikami, klientami i innymi interesariuszami i w ogóle wszelkimi ludźmi, z którymi coś trzeba ustalić. Jakże często analizując taki czy inny problem okazuje się, że pojawił się on dlatego, że ktoś z kimś nie pogadał, zamiast tego wysłał maila i zapomniał – albo co gorsza przyjął coś za „oczywiste” bez pytania.

Ponieważ komunikacja zespołu z innymi jest tak istotna, jako Scrum Master masz dbać o nią, a więc monitorować co się dzieje, być na bieżąco i w razie potrzeby zachęcać do niej. Masz też dbać o to, by proces nie „przeciekał”, a więc by przypadkiem w efekcie zespół nie zaczynał wykonywać jakiejś dodatkowej pracy poza backlogiem i wiedzą Product Ownera. Nigdy jednak nie masz jej zastępować i przekazywać informacji do i z zespołu.

Jeśli więc jest tak, że każdy kto chce się od zespołu czegoś dowiedzieć albo do niego przekazać, przychodzi z tym do Ciebie, to znaczy, że robisz to źle. Przestań natychmiast utrudniać komunikację swojemu zespołowi zanim wyrządzisz naprawdę duże szkody.

Podsumowanie

Oczywiście, można by wytknąć jeszcze parę częstych nieporozumień, ale myślę, że te są najważniejsze. Jeśli któryś z powyższych punktów nie jest dla Ciebie oczywisty to proszę, przemyśl, czy dobrze pełnisz swoją rolę i czy to, co wydaje Ci się zapewne normalne (a może nawet standardowe w Twojej organizacji) jest rzeczywiście dobre. Czy – innymi słowy – rzeczywiście jesteś Scrum Masterem, czy tylko masz taki tytuł w sygnaturce.

Pozdrawiam,
Andy Brandt