Select Page
Andrii Glushchenko

Scrum Master a Transformacja Agile

by | sie 19, 2018 | Scrum |

W tym poście, chciałbym podzielić się z Wami swoimi przemyśleniami na temat pozyskania i kształcenia Scrum Mastera w warunkach transformacji dużej organizacji. Widziałem dużo postów na temat roli Scrum Mastera, co robi i tak dalej, ale nie widziałem postów jak się pozyskuje Scrum Mastera oraz kształtuje się jego rola w korporacji w okresie transformacji. 

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 background’u jako QA (chyba jest to must, inaczej nie dasz rady kontrolować Zespółu Deweloperskiego :) ), ani żadnych innych predyspozycji, żeby zostać Scrum Masterem (np doświadczenie w Project Managemencie :)) . Uwaga, sarkazm. Nie uważam, że dla Scrum Mastera to MUST HAVE 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ń, nie wiedziałem po czym poznać, czy robię dobrą robotę. https://www.scrum.org/resources/blog/zombie-scrum-symptoms-causes-and-treatment 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 wytworzenia złożonych produktów w złożonym otoczeniu, który niesie w sobie swoje wartości (Courage, Focus, Respect, Openness & Commitment). Bez adaptacji 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 na swoim przykładzie, całemu otoczeniu. Jako wielki fan komiksów Marvel oraz DC, i im dłużej pracuję jako Scrum Master — tym bardziej ta rola mi przypomina Superbohatera. Tylko uwaga, Superbohaterowie też są różni. Dla mnie, Scrum Master to nie Tony Stark, którego widać wszędzie oraz on sam siebie zawsze chwali, tłumacząc na inny język — 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 to tak naprawdę on wszystko uratował. Dla Batmana najważniejszym jest, żeby Gotham się rozwijało i było lepszym miejscem. Tak samo i dla Scrum Mastera, zależy mu na tym, żeby produkt był coraz lepszym oraz sposób działania Zespołu Deweloperskiego oraz całej organizacji się ulepszał. Scrum Master robi bardzo dużo dla organizacji, przy czym 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 jak 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. Ja nie raz słyszałem frazy 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 adaptacji Scruma, oczywiście niesie to ze sobą zmiany i opór jest naturalnym zjawiskiem. I jak sądzisz, czy łatwym zadaniem jest sprzedać zmianę ludziom, którzy już wiele lat pracują w środowisku, gdzie praktykowane jest podejście centralnego planowania długofalowego, które ma na celu zapobiec jakimkolwiek zmianom?    Jak Ci wiadomo, Scrum Master w swojej pracy koncentruje się na trzech obszarach: na obszarze Product Ownera, Zespołu Deweloperskiego oraz na poziomie całej Organizacji. Tak tak, praca nad Organizacją to must dla Scrum Mastera 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? Spróbuję to opisać. 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 tobą a zwycięstwem. Prawdziwi koneserzy gier komputerowych, zyskają pełną satysfakcję tylko przy warunku skończenia gry na najwyższym poziomie złożoności oraz kiedy zaliczą wszystkie zadania poboczne. Myślę, że dla każdego Scrum Mastera, uczestniczenie w transformacji — jest analogiczne do gry z poziomami i “bossami” w świecie gier komputerowych. Jest to niesamowite wyzwanie. W świecie realnym, transformacja organizacji nie wygląda tak romantycznie jak to się może wydawać. Niestety nie jest to 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 “sence 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 adaptować 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, 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. Jak już wspominałem wyżej, pewnie wiesz do kogo należy obowiązek tłumaczyć dlaczego organizacja powinna się zmieniać? No, do Scrum Mastera. 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, my tam 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? Co on w ogóle będzie robił przez cały dzień? A 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 działań: #1 Ochotnicy Organizacja zadaje pytanie pod hasłem: “My tutaj mamy transformację, będziemy wdrażać Scrum. Kto chce zostać Scrum Masterem?” Jak tylko mówisz “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żby raz przeczytała całego Scrum Guide’a. Z reguły, za wielu chętnych od razu nie ma, dlatego każdy 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 O ile pierwsza opcja nie przyniosła oczekiwanego skutku, to od razu dostajemy “Agile Center of Exellence” z rękawa. Pamiętacie? Organizacje korzystają z Waterfall’a. A kto jest główną gwiazdą Waterfall’a? No 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ć w nadgodzinach.” . 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 na rolę Scrum Mastera? Proste, wychodzą z takiego założenia: ” Jesteś dobry PM’em, 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 PM’a, 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 już dawno ukształtowanym mindsetem command & control. https://www.scrum.org/resources/blog/zombie-scrum-symptoms-causes-and-treatment   PM już się przyzwyczaił, że dopóki nie wydasz komuś rozkazu, nie przypiszesz taska — to nic nie zostanie zrobione. PM nie rozumie wartości Scruma, PM nie rozumie na czym polega pętla inspect & adapt, PM nie rozumie 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ę. PM nie rozumie Scrum’a. Gdzie on widział Scrum w działaniu? Był chociaż na szkoleniu? Dla niego ten cały Scrum wygląda jako podział dużego projekty na mniejsze odcinki (Sprinty) i Scrum przypomina mu coraz bardziej etapy w PRINCE 2. I po tym wszystkim, on 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. No dobra, to nie temat tego posta i jest jak jest. 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 Scrum’a nie zostanie przekazana. Rotujący 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ć. Logicznym jest, że tłumaczy zasady gry oraz podpowiada jak grać lepiej osoba, która najlepiej zna tą grę. Tłumacząc na język prosty, Scrum Masterem powinna być osoba, która najlepiej Scruma zna. Zatrudnienie Scrum Mastera oraz Agile Coacha z zewnątrz jest bardzo dobrym rozwiązaniem, tylko trzeba zrobić odpowiednie otoczenie dla niego. 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 też będzie pracował 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ć. 

Jak 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, 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 wykorzystywali Project Management i Waterfall od czasów “kiedy koszulę w zębach nosiłeś”. Scrum Master powinien zadawać niewygodne pytania, powinien zmieniać status quo. Scrum Master również powinien być bardzo dojrzałym 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, jak pytają mnie, po czym można poznać prawdziwego Scrum Master’a, moja odpowiedź — to mindset oraz charakter. Można znać Scrum Guide’a na pamięć, ale dopóki go nie zrozumiesz – i tak nie będziesz potrafił odnaleźć siebie w Scrumie.