Blog

Każdy Scrum Master wcześniej czy później będzie musiał odpowiedzieć na pytanie o to, czym zajmuje się każdego dnia w pracy. Po raz pierwszy pytanie to pada, gdy Zespół zaczyna stawać się choć trochę samodzielny, co pozwala Scrum Masterowi usunąć się nieco w cień. Często takie wycofanie się jest interpretowane jako brak zaangażowania w pracę lub wręcz objaw lenistwa – a to prowokuje do zadawania trudnych pytań. Powracają one, gdy Zespół jest już na tyle samodzielny, że przełożeni zaczynają podejrzewać, iż misja Scrum Mastera jest zakończona, a jego obecność w Zespole stała się zbędna.

Czym powinien zajmować się Scrum Master?

Scrum Guide nie odpowiada na to pytanie wprost, ponieważ definiuje Scrum Mastera jako odpowiedzialność, a nie listę czynności czy opis stanowiska pracy. Scrum Master ma doprowadzić do tego, by Scrum był rozumiany i praktycznie stosowany, oraz by Zespół Scrum działał skutecznie. Jak to zrobić? O tym zdecydować musi samodzielnie osoba, która bierze na siebie tę odpowiedzialność. Sposób działania i narzędzia, jakich używa Scrum Master, nie są z góry zdefiniowane i zależą od specyfiki Zespołu, organizacji i możliwości samego Scrum Mastera.

W definicji Scruma wymieniona jest lista usług, które Scrum Master świadczy dla Zespołu Scrum, Product Ownera i organizacji. Nie należy jednak tej listy traktować jako opis stanowiska czy obowiązków pracownika będącego Scrum Masterem. Po pierwsze, nie jest to lista kompletna, a jedynie przykładowe działania lub problemy, nad którymi Scrum Master musi się pochylić. Po drugie, Scrum Guide nie wskazuje praktycznego sposobu świadczenia tych usług. Po trzecie, odpowiedzialność za coś nie oznacza automatycznie konieczności bezpośredniego działania, ale raczej obowiązek doprowadzenia do tego, by niezbędne czynności zostały podjęte.

Inaczej mówiąc, każda z przykładowych usług, które określa Scrum Guide, powinna być dostępna dla Zespołu, Product Ownera i organizacji, ale niekoniecznie Scrum Master osobiście musi te usługi świadczyć.

Wróćmy na moment do Scrum Guide. Nie jest instrukcją wdrożenia Scruma, ani nawet nie jest Scrumem – jest jedynie jego definicją. Określa odpowiedzialności (w tym Scrum Mastera), ale nie nakazuje ani nawet nie wskazuje praktycznych metod i technik, jakimi ktokolwiek w Zespole Scrum miałby się posługiwać. To oznacza, że poza podejściem typowym dla zarządzania w armii (ang. command and control), wszystkie narzędzia, techniki i praktyki mogą i powinny zostać zastosowane przez Scrum Mastera, o ile okażą się skuteczne. A jednym z takich narzędzi jest powstrzymywanie się od działania po to, by dać przestrzeń do działania innym.

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 tylko podłubie w skryptach. To wystarczy, by wszystko działało, więc wydaje się, że administrator niewiele robi. Jego umiejętności okazują się bezcenne, gdy wydarzy się sytuacja niespodziewana – wtedy wybudza się z letargu i ratuje świat. A gdyby go zwolnić, uznając, że „za mało robi, więc jest zbędny”, wcześniej czy później wszystko zacznie się sypać i organizacja odkryje, że ta niewielka ilość pracy, jaką administrator wykonywał, była jednak kluczowa.

Czy administrator zarobiony po łokcie jest mistrzem swego fachu? Raczej nie, ponieważ zamiast poświęcić czas na „leniwe” monitorowanie działających usług i sieci po to, by szybko zareagować, jeśli będzie to potrzebne, ten administrator biega od awarii do awarii, od problemu do problemu.

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 by zapytanym uświadomić, że coś być może im umknęło. Gdy trzeba, wytłumaczy, skąd w Scrumie wzięły się 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 logicznej kolejności ich stosowania, 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 – pomoc w działaniu i podejmowaniu decyzji, w tym (czasami) moderacja spotkań.
4. Aktywne nicnierobienie – czyli obserwacja połączona z gotowością do natychmiastowego działania (o tym kilka słów za chwilę).
5. Interwencja – 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 Scrum Master ma usuwać utrudnienia z drogi Zespołu. Zadawanie pytań, nauczanie lub facylitacja niewiele w tym pomogą, nie mówiąc już o aktywnym nicnierobieniu.

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ż kierowników i wszystkich, którzy tego będą potrzebować).

Cały czas musi jednak pamiętać, że jego odpowiedzialnością 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 nicnierobienie

Aby Zespół stawał się coraz bardziej samodzielny, musi uczyć się, jak radzić sobie z problemami i utrudnieniami, także tymi, które być może na razie przekraczają jego możliwości. To oznacza, że Scrum Master powinien najczęściej wstrzymać się z działaniem i dać szansę Developerom i Product Ownerowi, by samodzielnie z czymś sobie poradzili. Oczywiście powinien ich obserwować i w miarę potrzeb wspierać (np. coachingowo pomagając odkrywać możliwości), a dopiero gdy 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ść. Natomiast 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 nicnierobienie bywa trudne, zwłaszcza wtedy, gdy trzeba poradzić sobie z presją otoczenia. Wielu Scrum Masterów nie potrafi radzić sobie ze zwykłą ciszą. A bywa przecież tak, że na spotkaniu zapada milczenie i nie bardzo wiadomo, kto miałby się pierwszy 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ś niezajęty pracą w sposób widoczny nic nie robi. Scrum Master, który nie siedzi przy klawiaturze, nie wisi na słuchawce telefonu ani nie biega od spotkania do spotkania, zapewne obija się w pracy. A przynajmniej taka bywa percepcja kierownictwa 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 (ang. accountability) za to, by Zespół potrafił pracować w Scrum – odpowiedzialności zdefiniowanej wprost w Scrum Guide.

Objaw braku skuteczności?

Dojrzały Zespół i organizacja coraz mniej potrzebują aktywnie działającego Scrum Mastera, choć w praktyce nigdy nie stanie się on całkowicie zbędny. To powolne wycofywanie się Scrum Mastera w cień i pozostawanie niewidocznie obecnym (ang. invisibly present) jest czymś naturalnym. Wydaje się więc, że pojawienie się pytania „czym się właściwie zajmujesz?” jest nieuniknione i nie powinno niepokoić. No, nie zawsze. Czasem to sygnał alarmowy. Dlaczego?

Jeśli Scrum Master faktycznie pomógł w zbudowaniu środowiska, w którym może już bez negatywnych konsekwencji ograniczyć się do aktywnego nicnierobienia, to Scrum powinien być świetnie rozumiany zarówno przez Zespół, jak i otaczającą go organizację. Dlaczego zatem mają wątpliwości, czy Scrum Master się nie obija? Dlaczego spodziewają się po nim bardziej aktywnego działania? Nie rozumieją, że na tym etapie bycie niewidocznie obecnym to najlepszy sposób działania? Czy też sytuacja jest zgoła inna i aktywne nicnierobienie pozbawia Zespołu i organizacji niezbędnego i oczekiwanego wsparcia ze strony Scrum Mastera?

Gdy więc padają pytania o to, czym zajmuje się Scrum Master, należy oczywiście na nie odpowiedzieć. A potem zastanowić się (a najlepiej dopytać), dlaczego pytania te w ogóle się pojawiły i użyć tej wiedzy przy podejmowaniu kolejnych działań.

A gdy już Scrum Master wydaje się niepotrzebny…

Dojrzały Zespół Scrum 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. 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.

Poza tym nie można zapominać, że Scrum Guide definiuje Scrum Mastera jako odpowiedzialność, która jest obecna w Zespole zawsze, i której nie da się z tego Zespołu w żaden sposób usunąć. Jeśli więc Scrum Master – konkretna osoba, która wzięła na siebie tę odpowiedzialność – opuści Zespół, kto inny przejmie jej obowiązki. Dlaczego? Bo wciąż Zespół, jako całość, ma obowiązek dbać o efektywność i trzymać się ustalonego procesu. W pewien sposób Scrum Master samoczynnie odtworzy się w Zespole, kiedy będzie to niezbędne, choćby oficjalnie wszyscy twierdzili, że ten Zespół Scrum Mastera nie ma, bo jest mu niepotrzebny.

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 (Developerami i Product Ownerem), ale również z 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 Scrum Mastera raczej by nie padły.