Tak, Scrum Master (a dotyczy to praktycznie w tym samym stopniu Agile Coacha) musi się tłumaczyć przed całym zespołem i firmą z tego co robi – w tym sensie, że musi wytłumaczyć pozostałym członkom zespołu swoją rolę, swoje zadania, swój dzień pracy. Zwłaszcza, jeśli zespół czy firma są nowi w temacie albo nieprzekonani – wtedy nieznajomość roli SMa prowadzi do uproszczenia „nic nie robi, jest niepotrzebny”. I nie ma co jako Scrum Master brać do siebie tego, że zespół będzie sceptyczny do naszej roli albo nisko oceniał pracę takiego SMa (zwłaszcza tą niewidoczną) – jak nie rozumieją to trzeba wytłumaczyć, a jak nie widzą efektów pracy, może trzeba unaocznić.
Dosyć często rekomenduję zespołom na retrospektywie ćwiczenie z ról w zespole i wzajemnych oczekiwań. Zespół Dev, PO i Scrum Master wzajemnie każda rola do każdej roli (czyli Product Owner – SMowi i DevTeamowi, SM – Product Ownerowi i Devteamowi, a Dev Team SMowi i PO oraz dodatkowo też sam sobie) wypisują jakie mają oczekiwania od danej roli. Jeśli wiadomo, że coś nie gra, można te oczekiwania wypisać w formule 4L (http://agilecoaching.pl/pomysl-na-retrospekcje-sprintu-technika-4l/ – Jacek opisał to jako technikę na podsumowanie sprintu, w moim wariancie proponuję by podsumować jakiś dłuższy okres czasu – np. kwartał, ostatni etap projektu – by efekty ćwiczenia dotyczyły bardziej generalnych kwestii a nie incydentalnych zdarzeń albo pomijały wyjątkowo lepsze momenty w ostatnim tygodniu). Wybieramy najważniejsze punkty, każda z ról dokonuje refleksji i wybiera 1-2-3 rzeczy, które zmienią w następnym sprincie, by zrealizować oczekiwanie, które jest niespełnione. Lista oczekiwań może stać się jakąś formą kontraktu wzajemnego całego zespołu (przykładowo coś w stylu „od PO oczekujemy – decyzyjności, przygotowanego backlogu, wyjasnienia kontekstu; od SMa oczekujemy – usuwania problemów, sprawnych spotkań, …; od zespołu oczekujemy – słowności, wzajemnej pomocy, precyzji, komunikowania otwarcie jak jest, …”). Jeśli jest taka możliwość, warto do tego ćwiczenia zaprosić innego SMa albo Agile Coacha, żeby Scrum Master danego zespołu mógł się skupić na nim jako pełnoprawny uczestnik a nie jako jego jednoczesny moderator.
Inna rzecz, jaka często mi też wychodzi gdy pracuję ze Scrum Masterami jako mentor, to pomysł, by ujawnić zespołowi jakieś cele, do których SM dąży (i pewnie warto się razem z całym zespołem na nie zgodzić). Zerowym krokiem w tym temacie jest oczywiście posiadania pomysłu na kierunek rozwoju zespołu (i tu wraca nieśmiertelne i bardzo często stosowane przeze mnie pytanie w pracy 1-na-1 „jaki masz plan na swój zespół?”). Jeśli SM nie ma skonkretyzowanego planu, niech ma chociaż kierunki, do których dąży we wpływaniu na zespół, PO i resztę firmy. Te cele fajnie jak by były konkretne, najlepiej mierzalne – dzięki temu będzie można komunikować do zespołu postępy w ich osiąganiu. To może być gotowość backloga (np. na ile sprintów mamy gotowy backlog, czy zdarza się nam brać niegotowe rzeczy na planning albo do sprintu), ilość błędów na produkcji, jakieś wskaźniki szybkości pracy (lead time, cycle time, częstość wdrożeń), jakieś miękkie wskaźniki satysfakcji współpracy w zespole, może zadowolenie klienta zewnętrznego jeśli mamy taki kontekst. Jak rzetelnie do tematu się podejdzie, to przekonać można nie tylko swój zespół ale i całą firmę, a potem z tym materiałem bez problemu dostaniemy się z wystąpieniem na konferencję 😉
Na innym poziomie ogólności pewnego rodzaju atak na osobę Scrum Mastera czy Agile Coacha (podchwytliwe pytania co robi, sugerowanie niepotrzebności, irytowanie się, że jego praca jest mniej warta w porównaniu do innej roli) jest według mojego rozeznania dosyć częstym zjawiskiem. Temat może mieć znacznie bardziej złożone korzenie, ale warto z otwartą przyłbicą stanąć do rozmowy tego typu i podrążyć, dlaczego ktoś ma takie przekonanie o rolach agilowych i wsłuchać się w „zarzuty”. Jeśli to będzie coś z okolicy merytoryki pracy SMa albo braku widoczności efektów – zastosowanie ma w całości zestaw akapitów powyżej i ciągła praca nad rozwojem SMa i usprawnianiem zespołu. Może się jednak zdarzyć, że atak na rolę Scrum Mastera jest w istocie atakiem na całą koncepcję zwinności w danej firmie (której dedykowany SM będzie najczęściej najbardziej widocznym przejawem). Wtedy mamy cały temat komunikowania transformacji, jej efektów, przypomnienia oczekiwań ze strony kadry menedżerskiej, przypomnienia sobie w zespole czy agile nam coś dał z perspektywy czasu. Pod płaszczykiem pytań o sensowność roli SMa mogą też przewijać się kwestie związane z kultem źle rozumianej „efektywności” – postrzeganiem, może bazującym na przeszłości danej osoby czy całej firmy, że wszyscy powinni skupić się w 100% na kodowaniu / testowaniu / analitykowaniu, być tym zajęci od rana do wieczora i „nie kombinować, rozmawiać, dyskutować, usprawniać„. Tego typu kultura („bieganie z taczkami, bo nie ma czasu ich załadować” czy „too busy to improve”) może być tematem do zaatakowania ze znacznie wyższego poziomu niż pojedynczy SM czy Agile Coach, bez wsparcia szczytu firmy moim zdaniem się nie uda.
PS. Dobry artykuł na temat tego, co tak naprawdę robi Scrum Master napisała swego czasu Iza Goździeniak.