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.
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ć.