Co Scrum Master robi przez cały dzień? - Code Sprinters

Co Scrum Master robi przez cały dzień?

Wcześniej czy później każdemu Scrum Masterowi przyjdzie zmierzyć się z koniecznością odpowiedzi na pytanie: „czym ty się właściwie zajmujesz?”. Pytanie to pada po raz pierwszy gdy Zespół Developerski zaczyna stawać się choćby minimalnie samodzielny. To pozwala Scrum Masterowi usunąć się nieco w cień, przy czym to wycofanie się może zostać zinterpretowane jako brak zaangażowania w pracę lub wręcz objaw lenistwa. Drugi raz pada ono, gdy Zespół Developerski jest już na tyle samodzielny, że przełożeni zaczynają podejrzewać, iż misja Scrum Mastera jest zakończona, a rola ta stała się zbędna.

Co powinien robić Scrum Master?

Wedle Scrum Guide: zapewniać, że Scrum jest rozumiany i stosowany. Wymieniona jest tam lista usług, które Scrum Master świadczy dla Zespołu, Product Ownera i organizacji. Niektóre z tych zadań są bardzo konkretne, na przykład facylitacja zdarzeń Scrumowych czy usuwanie przeszkód, które utrudniają Zespołowi dostarczanie działającego produktu. Większość jest mniej precyzyjnie zdefiniowana, bo na przykład nie jest powiedziane jak Scrum Master ma coachować Zespół Developerski w zakresie samoorganizacji i cross-funkcyjności.

Pamiętać wszakże należy, że Scrum Guide nie jest instrukcją wdrożenia Scruma, a jedynie jego definicją. To oznacza, że nie opisuje praktycznych metod i technik, jakimi Scrum Master miałby się posługiwać, świadcząc usługi komukolwiek. W szczególności poza podejściem typowym dla zarządzania w armii (command and control), wszystkie inne narzędzia, techniki i praktyki mogą i powinny zostać zastosowane, o ile okażą się skuteczne.

Pozorne lenistwo

Andy Brandt posługuje się często ciekawą analogią Scrum Mastera do administratora systemów informatycznych i sieci. Dobry administrator najczęściej nie wydaje się zajęty, ma czas pogadać, napić się kawy i pograć w gry, a czasem nawet coś tam podłubie w skryptach. Zarobiony po łokcie administrator prawdopodobnie nie jest mistrzem tego fachu; prawdziwy ekspert z pozoru niewiele robi, ale jego umiejętności okazują się bezcenne, gdy wydarzy się sytuacja niespodziewana. Wtedy pojawia się znikąd i ratuje świat. A gdyby go zwolnić, to choć zdawało się, że niewiele robił, wcześniej czy później wszystko zacznie się sypać.

Podobnie jest ze Scrum Masterem. Nie stoi nigdy w świetle jupiterów, wycofuje się, pozwala innym działać, obserwuje sytuację. Czasami o coś zapyta, choć wcale nie po to, by się czegoś samemu dowiedzieć, ale po to, by zapytanym uświadomić, że coś być może im umknęło. Gdy trzeba, wytłumaczy, skąd w Scrumie są takie a nie inne zasady i czemu służą poszczególne elementy tej metody. Często pomaga w prowadzeniu spotkań, choć nie jako moderator – raczej jako facylitator wspierający moderatora. Bardzo rzadko, w sytuacji kryzysowej, coś faktycznie Zespołowi zarekomenduje lub będzie się czegoś od Zespołu domagał.

Narzędzia Scrum Mastera

Układając w kolejności zastosowania, Scrum Master ma pięć narzędzi:

  1. Zadawanie pytań – aby prowokować do szukania odpowiedzi i dążyć do pełnej przejrzystości.
  2. Uczenie – o Scrumie, technik i praktyk, jeśli są potrzebne.
  3. Facylitacja, a czasami moderacja spotkań.
  4. Aktywne nic-nierobienie – o tym kilka słów za chwilę.
  5. Reagowanie – najczęściej w sytuacji kryzysowej, aby chronić dobro zespołu.

Tylko tyle, i aż tyle.

Ktoś może zaprotestować widząc taką a nie inną listę narzędzi. Przecież jasno jest napisane w Scrum Guide, że ma usuwać utrudnienia z drogi Zespołu. Zadawanie pytań, nauczanie lub facylitacja niewiele w tym pomogą, nie mówiąc już o aktywnym nic-nierobieniu.

Sposób działania Scrum Mastera zależy od organizacji, w której funkcjonuje i od dojrzałości Zespołu. Na początku, gdy Agile i Scrum są nowością dla organizacji, a Zespół dopiero się formuje, Scrum Master może istotnie mieć pełne ręce roboty. Będzie walczył z ograniczającymi Developerów procedurami, organizował sale na spotkania, prezentował w praktyce niezbędne narzędzia i techniki, uczył Scruma (nie tylko Zespół, ale też managerów i wszystkich, którzy tego będą potrzebować).

Cały czas musi jednak pamiętać, że jego rolą nie jest uzależnienie Zespołu od omnipotentnego Scrum Mastera, który jak buldożer spycha wszystko z drogi zespołu zanim jeszcze w ogóle coś stanie się problemem. Chodzi o coś dokładnie odwrotnego.

Aktywne „nic-nieróbstwo”

Aby Zespół stawał się coraz bardziej samodzielny, musi uczyć się jak radzić sobie z problemami i utrudnieniami, które nie przekraczają jego możliwości. To oznacza, że Scrum Master powinien najczęściej wstrzymać się z działaniem i dać szansę Developerom, by samodzielnie z czymś sobie poradzili. Oczywiście powinien ich obserwować i w miarę potrzeb coachować (pomagając odkrywać możliwości), a dopiero jak nie ma innego wyjścia, samemu zacząć działać.

Takie postępowanie powoduje, że z czasem ilość interwencji Scrum Mastera się zmniejsza, albo – wolę określać to w ten sposób – samodzielność Zespołu rośnie. Co więcej, nie jest to wzrost liniowy: najczęściej nauczywszy się radzić sobie z jednym problemem Zespół dużo efektywniej poradzi sobie z kilkoma kolejnymi, bo zyskuje pewność siebie i zrozumienie, że to jego odpowiedzialność. Scrum Master „niańczący” Zespół i próbujący aktywnie przeciwdziałać problemom, zanim one w ogóle staną się znane Zespołowi, działa na jego szkodę.

Aktywne „nic-nieróbstwo” bywa trudne zwłaszcza wtedy, gdy trzeba poradzić sobie z presją otoczenia. Wielu Scrum Masterów nie potrafi radzić sobie z… ciszą. A bywa przecież tak, że na spotkaniu zapada milczenie, nie bardzo wiadomo, kto miałby się wtedy odezwać. Wytrzymanie presji tej ciszy, czasami kilkuminutowej, bywa bardzo trudne, ale warto to zrobić. W końcu przecież ktoś się odezwie, choćby po to, by zapytać Scrum Mastera „co teraz?”. A to już pozwala przejść choćby do coachingu.

Wszyscy muszą być zajęci?

Oczywiście we współczesnych organizacjach panuje wciąż przekonanie, że ktoś nie zajęty pracą w sposób widoczny nic nie robi. Scrum Master nie siedzący przy klawiaturze, nie wiszący na słuchawce telefonu ani nie biegający od spotkania do spotkania zapewne obija się w pracy. A przynajmniej taka bywa percepcja, i automatycznie prowokuje to do zadawania kłopotliwych pytań.

Warto zatem wyjaśnić wszystkim zainteresowanym jakie są narzędzia Scrum Mastera i w jaki sposób z nich korzysta. Warto też wyjaśnić, dlaczego niekoniecznie Scrum Master pierwszy powinien rwać się do działania, choć nic nie zwalnia go z odpowiedzialności (accountability) za to, by Zespół potrafił pracować w Scrum.

A gdy już Scrum Master wydaje się niepotrzebny…

Dojrzały Zespół Developerski wydaje się nie potrzebować Scrum Mastera, choć w praktyce nie zdarza się to przesadnie często. Zawsze może wydarzyć się coś, z czym niekoniecznie bez pomocy servant leadera Zespół sobie poradzi (znów przypominam analogię do administratora systemów i sieci). Warto też uświadomić sobie, że dojrzałość nie jest stanem stabilnym, który się osiąga raz i na zawsze. Wiele czynników może spowodować, że nastąpi regres w rozwoju (choćby zmiany osobowe lub rozpoczęcie pracy z innymi technologiami i produktami).

A przede wszystkim będąc dojrzałym nie wolno przestać się rozwijać! Zawsze można się stać jeszcze bardziej dojrzałym, niż już się jest. Scrum i Agile w swej istocie opierają się o założenie, że proces usprawniania i doskonalenia nigdy się nie kończy. W tym kontekście stwierdzenie, że Scrum Master może realnie okazać się zbędny, wydaje się mocno nierozsądne.

Przekonanie, że dojrzałe Zespoły nie potrzebują Scrum Mastera, często bierze się również z braku świadomości, że pracuje on nie tylko z Zespołem, ale również z Product Ownerem i całą organizacją. Z ironią można stwierdzić, że jeśli przełożeni Scrum Mastera tego nie wiedzą, to niezbyt dobrze wykonał pracę w zakresie edukowania organizacji. Gdyby zadbał o coś więcej niż rozwój Zespołu, sugestie o zbędności utrzymywania roli Scrum Mastera raczej by nie padły.

LinkedIn

SZKOLENIA ZWIĄZANE Z TEMATYKĄ ARTYKUŁU


O autorze: Rafał Markowicz
Scrum Master z wieloletnim doświadczeniem, w branży IT od 2001. Praktyk Agile, ekspert w zakresie inżynierii testów i zapewnienia jakości. Pracował jako analityk systemowy i biznesowy, jest doświadczonym developerem, managerem i konsultantem.

Inne artykuły tego autora