Dlaczego zostałem Scrum Masterem
Moja przygoda ze Scrumem zaczęła się całkowicie przypadkowo, ponieważ nie miałem ani doświadczenia jako Deweloper, ani backgroundu jako QA, ani żadnych innych predyspozycji, żeby zostać Scrum Masterem (np. doświadczenia w Project Managemencie). Wbrew powszechnym przekonaniom nie uważam, że dla Scrum Mastera to MUST HAVE, żeby mieć doświadczenie jako PM oraz Deweloper. Na ten temat można nawet napisać oddzielnego posta. Poza tym, powiem szczerze, że w pierwszym roku mojego działania jako Scrum Master, ja sam miałem trudności ze zrozumieniem własnej roli. Nie rozumiałem, co dokładnie miałem robić na co dzień, ani po czym poznać, czy robię dobrą robotę.
Weźmy nawet pierwszy obowiązek Scrum Mastera według Scrum Guide:
The Scrum Master is responsible for promoting and supporting Scrum as defined in the Scrum Guide.
To znaczy, że Scrum Master jest przede wszystkim odpowiedzialny za to, żeby Scrum był rozumiany nie tylko jako zbiór spotkań, lecz jako framework do budowania złożonych produktów w złożonym otoczeniu, który niesie w sobie swoje wartości (Courage, Focus, Respect, Openness & Commitment). Bez tych wartości Scrum staje się Zombie Scrumem, o którym już wspominał Barry Overeem. A jak to robi Scrum Master? Proste! Scrum Master odzwierciedla wartości w swojej codziennej pracy, pokazując je na swoim przykładzie całemu otoczeniu.
Im dłużej pracuję jako Scrum Master, tym bardziej ta rola przypomina mi superbohatera. Tylko uwaga, superbohaterowie też są różni. Dla mnie jako wielkiego fana komiksów Marvela oraz DC Scrum Master to nie Tony Stark, którego widać wszędzie i który sam siebie zawsze chwali. Innymi słowy — od prawdziwego Scrum Mastera nigdy nie usłyszycie “przyszedłem tam i po prostu uratowałem projekt”. Dla mnie Scrum Master to prędzej Batman (Bruce Wayne), który robi bardzo dużo, tylko nikomu nie mówi, że tak naprawdę to on wszystko uratował. Dla Batmana najważniejsze jest, żeby Gotham się rozwijało i było lepszym miejscem. Tak samo Scrum Masterowi zależy na tym, żeby produkt był coraz lepszy, a Zespoły Deweloperskie i cała organizacja działały coraz sprawniej. Scrum Master robi dla organizacji bardzo dużo, ale powinien być przygotowany na to, że zawsze zostanie w cieniu, a najlepszą metryką jego sukcesu będzie jakość dostarczanego produktu, zmiana w dotychczasowym sposobie pracy Zespołu Deweloperskiego i sposób działania całej organizacji.
Rzeczywistość Transformacji a Scrum Master
Scrum Masterów w organizacjach często postrzega się jako buntowników. Nieraz słyszałem komentarze typu: “Wiele lat jakoś działaliśmy i wszystko było w miarę ok, a wy tutaj ze swoim Scrumem zawracacie głowę i przeszkadzacie”. Jest to zakorzenione zdanie ludzi, którzy już wiele lat pracują w ekosystemie, do którego się przyzwyczaili do takiego stopnia, że dopasowali do tego cały swój rytm życia. Kiedy organizacja podejmuje decyzję o wdrożeniu Scruma, oczywiście niesie to ze sobą zmiany i opór jest naturalnym zjawiskiem. I jak sądzisz, czy łatwo jest sprzedać zmianę ludziom od lat pracującym w środowisku, gdzie praktykowane jest podejście centralnego planowania długofalowego, które ma na celu zapobiec jakimkolwiek zmianom?
Scrum Master w swojej pracy koncentruje się na trzech obszarach: wsparciu Product Ownera, Zespołu Deweloperskiego oraz na poziomie całej organizacji. Tak, praca z organizacją jest dla Scrum Mastera obowiązkowa i nie wolno w żaden sposób o tym zapominać, szczególnie, kiedy organizacja jest w trakcie transformacji. A czym dokładnie jest transformacja dla Scrum Mastera?
W większości gier komputerowych są różnie poziomy złożoności, różnie checkpointy, różne zadania, pod koniec których jest zawsze zderzenie z “bossem” który stoi między graczem a zwycięstwem. Prawdziwi koneserzy gier komputerowych zyskają pełną satysfakcję tylko pod warunkiem skończenia gry na najwyższym poziomie złożoności oraz kiedy zaliczą wszystkie zadania dodatkowe. Myślę, że dla każdego Scrum Mastera uczestniczenie w transformacji jest analogiczne do gry z najwyższymi poziomami i “bossami” w świecie gier komputerowych. Jest to niesamowite wyzwanie.
W realnym świecie transformacja organizacji nie wygląda tak romantycznie, jak to się może wydawać. Niestety nie jest tak, że wewnątrz organizacji wszyscy razem się zebrali i doszli do wniosku, że warto się zmieniać, dlatego że konkurencja działa o wiele skuteczniej niż my. Często większa część organizacji nie ma “sense of urgency”. Nie ma potrzeby zwiększenia ilości klientów albo obrotów. Nie widać potrzeby biznesowej do przeprowadzenia transformacji.
Zwykle transformacja zaczyna się od IT. Menadżerowie w IT rozumieją, że po to, żeby pozostać w grze, trzeba dostosować się do złożonego i szybko zmieniającego się środowiska. Mają już dosyć zarzutów, że IT nie dostarcza na czas. Dlatego często główny focus transformacji jest skierowany na IT. Według wielu osób IT jest tym miejscem, które powinno się transformować, żeby dostarczać szybciej, taniej i więcej. W ogóle IT jest postrzegane jako swego rodzaju, “black box”, gdzie trzeba po prostu wrzucić jakieś wymagania i polać z góry kawą (żeby pracowało bardziej wydajnie) i na koniec dostaniesz “coś działającego”. Więc kiedy menadżer od IT przychodzi do menadżera z biznesu i opowiada o pomyśle na zmianę, biznes mówi: “Możecie tam u siebie w IT zmieniać, co chcecie, ale musicie dostarczać od razu więcej, inaczej te zmiany nie mają żadnego sensu”. I wychodzi mniej więcej taki “kompromis”.
Pomińmy fazę pomysłów na transformację i przejdźmy już do rozgrywki. Kto ma tłumaczyć, dlaczego organizacja powinna się zmieniać? Oczywiście Scrum Master. Stąd prosta logika — im więcej mamy dobrych Scrum Masterów, tym większa szansa na udaną transformację. I przychodzi czas, kiedy każda organizacja zadaje sobie takie pytanie: “No dobra, chcemy tego Scruma, to znaczy, że potrzebujemy Scrum Mastera. A co on w ogóle będzie u nas robił? A czy to w ogóle praca na full time? Jak on w ogóle będzie kontrolował, żeby Zespół Deweloperski robił, to co trzeba?“ Nie znając odpowiedzi na te pytania, organizacje dochodzą do genialnego wniosku: “A to może po prostu damy dodatkowe obowiązki i tytuł Scrum Mastera ludziom, których już mamy, i to wystarczy, żeby transformacja się rozpoczęła”.
I tutaj zazwyczaj mamy kilka scenariuszy:
#1 Ochotnicy Organizacja zadaje pytanie: “Mamy transformację, będziemy wdrażać Scrum. Kto chce zostać Scrum Masterem?” Jak tylko powiesz “tak”, od razu zostajesz Scrum Masterem. Myślę, że nie jest to idealna opcja, ale nie jest również i najgorsza. Przynajmniej w ten sposób zobaczymy ilość ludzi, która dokonała tytanicznego wysiłku i chociaż raz przeczytała cały Scrum Guide (całe 13 stron;)). Z reguły za wielu chętnych od razu nie ma — chociażby dlatego, że niejeden z nas widział albo słyszał od znajomych o nieudanych implementacjach Scruma. Poza tym na początku, kiedy jeszcze prawie nikt nie rozumie Scruma, jest szansa, że dostaniemy osoby, które podczepiają się do każdej nowej inicjatywy i uważają, że to jest akurat ta rola, gdzie nie ma żadnej odpowiedzialności oraz nic nie trzeba robić.
#2 Project Manager Jeśli pierwsza opcja nie przyniosła oczekiwanego rezultatu, to od razu dostajemy “Agile Center of Excellence” z rękawa. Pamiętacie? Organizacje korzystają z waterfalla. A kto jest główną gwiazdą waterfalla? Oczywiście Project Manager (PM). Człowiek, który może organizować wszystko i zawsze dowozi. Człowiek, który jak tylko wchodzi do pokoju, cała aura wokół niego mówi: “Wio, szybko do roboty! Jesteście tutaj od tego, żeby projekty dojeżdżały na czas. Nie dajecie rady? No to proste rozwiązanie, zawsze możecie zostać na nadgodziny”. Chodzą plotki, że jeżeli wpuścić nagiego PMa do dżungli, to wyjdzie stamtąd z futrem pantery i z kasą na nowy projekt na modernizację dżungli.
W jaki sposób odbywa się rekrutacja PMa do roli Scrum Mastera? Proste, wychodzą z takiego założenia: “Jesteś dobry PMem, ogarniasz całe projekty. A jak potrafisz ogarnąć całe projekty, to ogarnąć Scrum Team uda Ci się na bank” albo: “Aha, ten zespół już ma PMa, to nazwijmy go teraz Scrum Masterem. Jak mamy już Scrum Mastera, to znaczy, że robimy Scruma”. Dość słaba opcja, ponieważ oddajemy rolę, której podstawowym zadaniem jest wytłumaczenie, na czym Scrum polega i jakie są jego wartości, osobie z często już dawno ukształtowanym mindsetem command & control.
Wielu PMów już się przyzwyczaiło, że dopóki nie wydasz komuś rozkazu, nie przypiszesz taska — to nic nie zostanie zrobione. Często nie rozumieją wartości Scruma, na czym polega pętla inspect & adapt, o co chodzi z tą transparencją i dlaczego jest tak ważna. Przecież na statusach to zawsze trzeba pokazywać, że projekt jest na żółto, bliżej do zielonego niż do czerwonego i on da radę. Taki PM nie rozumie Scruma. Gdzie on widział Scrum w działaniu? Był chociaż na szkoleniu? Dla niego ten cały Scrum wygląda jak podział dużego projekty na mniejsze odcinki (Sprinty) i Scrum przypomina mu coraz bardziej etapy w PRINCE 2. I po tym wszystkim taki PM dochodzi do wniosku, że ten cały Scrum nie działa.
#2 Ktoś z Zespołu Deweloperskiego Nie wiem dlaczego, ale często Zespoły Deweloperskie traktuje się jako oddzielny ekosystem, gdzie bardzo trudno się dostać. Nawet na rozmowach rekrutacyjnych często słyszałem pytania: “A jak Pan sobie radzi z Zespołem Deweloperskim?” Nie wiem, dlaczego organizacje myślą, że z Zespołami Deweloperskimi są największe problemy. Mówią, że próg wejścia do Zespołu jest wysoki i zdobycie zaufania jest dość trudne dla nowej osoby. Chyba najmniej bolesne będzie zrobić Scrum Masterem kogoś z Zespołu Deweloperskiego, a jeszcze lepiej, żeby rola Scrum Mastera rotowała między członkami Zespołu Deweloperskiego (np. co Sprint). W takim przypadku, “Scrum Master” będzie się skupiał na poprowadzeniu wydarzeń, a w najlepszym przypadku na jakichś usprawnieniach ze strony technicznej. Ale znów, cała idea Scruma nie zostanie przekazana. Obecny Scrum Master będzie się skupiał na przetrwaniu tego Sprintu, żeby ktoś inny został Scrum Masterem.
#4 Scrum Master z zewnątrz — konsultant albo Agile Coach z zewnątrz mówi nam, co mamy robić, a my mówimy “nie, nie zgadzam się”. Scrum Master jest odpowiedzialny za to, żeby Scrum był zrozumiany oraz poprawnie stosowany. Czyli rolą Scrum Mastera jest wytłumaczyć, czym jest Scrum oraz jak w niego poprawnie grać. Logiczne, że tłumaczy zasady gry oraz podpowiada jak grać lepiej osoba, która najlepiej zna tą grę. Mówiąc prościej, Scrum Masterem powinna być osoba, która najlepiej Scruma zna. Zatrudnienie Scrum Mastera czy Agile Coacha z zewnątrz jest bardzo dobrym rozwiązaniem, tylko trzeba stworzyć dla niego odpowiednie otoczenie. Pamiętajcie, że Scrum Master działa na 3 poziomach: Product Ownera, Zespółu Developerskiego oraz na poziomie całej organizacji. Doświadczony Scrum Master nie będzie zapominał o poziomie organizacji i będzie pracował też nad całą strukturą. Dlatego, żeby to doszło do skutku — Scrum Master/Agile Coach powinien być odpowiednio umocowany. Warto zapobiec sytuacji, w której zatrudnimy Agile Coacha, a później nie będziemy go słuchać.
Po czym poznać prawdziwego Scrum Mastera?
Podsumowując ten post, chciałbym podzielić się własnymi przemyśleniami na temat jakich Scrum Masterów warto szukać. A zacząłbym od pytania: “Czy każdy może być Scrum Masterem?”. Moim zdaniem nie, nie i jeszcze raz nie.
Bycie Scrum Masterem to ogromne wyzwanie. Musisz walczyć z zakorzenionym mindsetem, z jakąś określoną strukturą, z całym sposobem funkcjonowania organizacji. Uwierzcie mi, nie każdy potrafi to wytrzymać, szczególnie w organizacjach, gdzie dla prowadzenia projektów wykorzystywano Project Management i waterfall od czasów “kiedy koszulę w zębach nosiłeś”.
Scrum Master powinien zadawać niewygodne pytania, zmieniać status quo. Scrum Master powinien też być bardzo dojrzały emocjonalnie, trzeźwo oceniać i reagować na sytuacje. Powinien zawsze być o krok dalej niż otoczenie, po to, żeby prowadzić za sobą całą organizację w okresie zmiany.
Dlatego kiedy ktoś pyta mnie, po czym można poznać prawdziwego Scrum Mastera, moja odpowiedź to mindset i charakter. Możesz znać Scrum Guide na pamięć, ale dopóki go nie zrozumiesz – i tak nie będziesz potrafił odnaleźć się w Scrumie.
