Scrum Master – agent zmiany czy niepotrzebny dodatek?

Wiele organizacji chce pracować zwinnie. Wiele organizacji chce wykorzystywać do tego framework Scrum. I wiele organizacji uważa, że ważnym krokiem do zwinności jest zatrudnienie dobrych Scrum Masterów.

Patrząc na sytuację z drugiej strony: często osoby, które pracują (lub chcą pracować) w roli Scrum Mastera, to osoby chcące zmieniać rzeczywistość. To osoby, które widzą marnotrawstwo, nieefektywność, absurdy; osoby przekonane, że można pracować lepiej, bardziej racjonalnie, bardziej efektywnie; osoby dążące do zmiany status quo.

Wydawać by się mogło, że jest to idealna sytuacja “win-win” – mamy organizację, która chce się zmienić i mamy osobę, która chce wprowadzać zmianę. “It’s a match!”. Niestety rzeczywiste spotkanie tych dwóch podmiotów często przypomina nieudaną randkę z Tindera…

Co ja tu będę robił?

Pierwszym sygnałem, że nasza randka może być nieudana, są rozmowy Scrum Mastera z zatrudniającą go osobą na temat celu jego pracy. Jeżeli w tej rozmowie pojawiają się ogólne stwierdzenia typu “zrób nam Scruma”, “zrób tak, żebyśmy byli bardziej zwinni”, “zobacz, co tu da się poprawić” lub cytowany jest tylko Scrum Guide – to najczęściej jest sygnał, że zmiana nie jest przemyślana, nie ma określonego celu biznesowego i raczej nie będzie miała dużego wsparcia ze strony osób zarządzających organizacją.

Kolejnym sygnałem, który zwiastuje średnio udaną zabawę, jest rozmowa o miejsce Scrum Mastera w hierarchii organizacji. Nie zapominajmy, że Scrum Master jest rolą menedżerską. Więc jeśli słyszysz, że zostaniesz przypisany do danego zespołu, dla którego masz być Servent Leaderem i będziesz pod kierownikiem liniowym danego zespołu – to może to być przepowiednia, że w tym związku raczej nie będziesz wysłuchany. 

Inną sytuacją, kiedy na pierwszej randce powinna zapalić Ci się żółta lampka, jest odpowiedź na pytanie “A kto jest sponsorem zmiany? Komu zależy na tej zmianie?”. Jeżeli zobaczysz zakłopotane miny lub ogólnikowe odpowiedzi takie jak “zmiana jest oddolna” czy “wszystkim nam zależy!”, to  możesz podejrzewać, że w późniejszych etapach związku siorbanie przy piciu herbaty i maczanie wąsów w zupie nie będą jedynymi problemami.

Zderzenie ze ścianą

Często takie niedoskonałości widoczne na pierwszej randce nie zniechęcają Scrum Mastera. Przecież to siorbanie herbaty to na pewno z nerwów, a maczanie wąsów w zupie to przypadek. Poza tym druga strona może nie wiedzieć o tym, że tak robi. Ja jej pomogę. Przecież wszystko można poprawić. No przecież kto, jak nie ja?

W ciągu pierwszych tygodni nowego związku jest naprawdę dobrze. Okazuje się, że pewne zmiany na poziomie zespołu daje się wprowadzić w miarę łatwo. Zespół zaczyna pracować w sprintach, uczestniczyć w cyklicznych retrospektywach, korzystać z Backlogu Sprintu, przestaje maczać wąsy w zupie i siorbać. Natomiast wkrótce odkrywamy rzeczy, które mocno wpływają na pracę zespołu – ale są bardzo trudne lub też niemożliwe do zmiany.

Zacznijmy od problemu dość małego kalibru. W pewnej organizacji wykorzystywana była Jira. Dawno, dawno temu ktoś zdefiniował workflow, który obrazował idealny przebieg konwersacji z klientem – zmiana była zgłaszana, kategoryzowana, wysyłana do akceptacji, projektowana, wyceniana i wykonywana. Wszystko to było dokładnie odzwierciedlone w statusach, których było około trzydziestu. Dodatkowo zostały zaimplementowane warunki, które były konieczne do spełnienia na przejściach pomiędzy statusami. Zespół pracując z nad pobocznym projektem wpadł na pomysł, żeby zacząć wykorzystywać epiki, ale tak naprawdę potrzebował tylko 5 statusów oraz możliwości dokonywania dowolnych przejść między nimi. Zdefiniowanie takiego workflow to 10 minut roboty dla administratora Jiry. Ale tutaj rozpoczęło się oburzenie – dlaczego chcecie zmieniać nasz Święty Workflow dla Epików?! On działa od dziesięciu lat, on jest idealny, wszyscy powinni go używać!

Kolejnym problemem, który może już znacząco wpłynąć na pracę Scrum Mastera, jest brak możliwości modyfikowania środowiska wytwarzania oprogramowania. Jednym przykładem jest tutaj organizacja, w której środowiska testowe były tworzone i utrzymywane poza zespołami, w innym dziale. Dział ten posiadał inny budżet, innego przełożonego i był w ogóle niezależną jednostką. Zespół jedynie mógł zgłaszać problemy, które widzi w tych środowiskach i trzymać mocno kciuki za to, że ktoś je poprawi. Jak łatwo się domyślić, modyfikowanie środowisk testowych było długim procesem, a zanim doszło do realizacji zmiany, trzeba było przekonać do tych zmian szereg osób po drodze. Na pytanie “czy środowisko testowe odpowiadało produkcji?” odpowiedzcie już sobie sami. 

Innym przykładem są narzędzia, które wykorzystywane były do CI. Odpowiedzialność za te narzędzie spoczywało, na jednej osobie w organizacji. Osoba ta nie pracowała w zespole. Była instancją działająca z boku zespołów. Niemożliwe było wprowadzenie jakichkolwiek zmian w CI przez zespół, takich jak podpięcie nowego typu raportów czy wprowadzenie narzędzi do monitorowania jakości kodu. Proces nie był adoptowany do nowych wyzwań. Zespół ma się samoorganizować i ciągle ulepszać, ale jedyną zmianą jaką realnie może wprowadzić to “Lepiej się komunikujemy”. 

Kolejna organizacja rozwijała produkt, którego nowa wersja wchodziła na rynek co sześć miesięcy. Półroczny cykl pracy wyglądał następująco: seria sprintów, stworzenie wersji “release candidate”, a potem “freeze period” i poprawianie błędów. Do firmy dołączył nowy Scrum Master. Rozpoczął od próby zrozumienia i ogarnięcia spraw na poziomie zespołu. Ale kiedy zobaczył fenomen miesięcznego okresu “freeze period”, podczas którego wszyscy deweloperzy zapominają o sprintach, planowaniu, backlogach i w pocie czoła poprawiają błędy nowej wersji systemu, to od razu zadał pytanie: co możemy zmienić, żeby w sprincie robić bardziej ukończony produkt, tak aby miesięczne wygrzewanie produktu nie było potrzebne? Odpowiedź osób zarządzających organizacją brzmiała: “to jest nasz proces wydawania produktu, wypracowaliśmy go przez lata i nie będziemy go zmieniać”. Czyli chcemy mieć Scruma, ale wykreślamy ze Scrum Guide’a zdanie, że celem każdego sprintu jest stworzenie gotowego do użycia i potencjalnego wydania produktu. 

Inny przykład pochodzi z organizacji, która posiadała bardzo duży dług techniczny. Ciężko było nawet określić wielkość tego długu, ponieważ do tego momentu nikt nie zwracał na niego uwagi. Pewnym było, że nie było testów jednostkowych, integracyjnych ani UI. Reszta została owiana tajemnicą milczenia. Wraz z wprowadzeniem zwinnego sposobu pracy stwierdzono, że będziemy wydawać oprogramowanie na produkcję co dwa tygodnie albo i częściej. Jak powiedziano, tak zrobiono. Jedyne, co można było powiedzieć dobrego o tych wdrożeniach to to, że były często. Niestety, po większości z nich napływał szereg zgłoszeń o nowych błędach na produkcji. Planowanie prac i praca w takich warunkach były bardzo trudne. Zespoły miały świadomość, że aby uniknąć takich sytuacjach potrzebne jest więcej czasu, pisanie lepszego kodu oraz rozpoczęcie nadrabiania zaległości. Niestety świadomość ta kończyła się na zespole deweloperskim. Przekonanie kogokolwiek do pomysłu spłacania długu graniczyło z cudem. “Przecież musimy dostarczać NOWE funkcjonalności!”, “Co mnie interesuje dług techniczny – to sprawa zespołu, niech sobie to ogarnie!” mawiał Product Owner oraz wszyscy interesariusze. Scrum Master z kolei był tak nisko w hierarchii, że nikt jego głosu raczej nie słuchał – a na próby zgłaszania problemów wyżej słyszał zwykle odpowiedź: “zajmij się zespołami”. 

Co robi Scrum Master, który nie może wdrażać Scruma?

Te sytuacje mają wspólny mianownik – organizacja zatrudnia osobę, która ma wdrożyć zmianę, a potem pokazuje mu (wprost lub w zawoalowany sposób), że zmiana może być wprowadzona tylko w określonych granicach.

Przyszła mi do głowy taka metafora. Jest drużyna sportowa, która gra w koszykówkę. Właściciel tej drużyny podejmuje decyzję, że zmieniają dyscyplinę sportową – zamiast koszykówki będą teraz grać w lidze siatkarskiej. A ponieważ nie do końca wiedzą, jak trenować siatkówkę, to zatrudniają trenera od siatkówki: “przyjdź i naucz nas dobrze grać w siatkówkę”. Trener przychodzi, odbywa kilka treningów z drużyną, a potem idzie do właściciela i mówi: “Wiesz, generalnie fajna drużyna, ambitnie pracują, ale potrzebujemy kilku zmian. Trzeba zmienić wymiary boiska i trzeba byłoby kupić nowe piłki. A, i trzeba zdjąć kosze, i siatkę tutaj powiesić”. Na co pada odpowiedź: wszystko zostaje tak jak było, to jest nasze boisko i nasze piłki, jesteśmy z nich zadowoleni, naucz nas grać w siatkówkę na tym sprzęcie, który mamy.

Co robi Scrum Master, który nie może wdrażać Scruma? Tutaj postawy są bardzo różne. 

Są osoby, które po napotkaniu wyraźnej bariery szybko zmieniają pracę i szukają miejsca bardziej otwartego na zmianę. Tylko… ile takich miejsc jeszcze zostało? Każdy chce być teraz zwinny, a “Scrum Masterów” po jednodniowym kursie na rynku przybywa. 

Są osoby, które przyjmują narzucone ograniczenia i starają się działać wewnątrz nich. Może pojawić się wtedy coś w rodzaju syndromu sztokholmskiego – wtedy kiedy Scrum Master tłumaczy dysfunkcje organizacji i mówi na przykład tak: “Ja wiem, że powinniśmy robić Daily Scrum codziennie, ale w naszej organizacji jest to niemożliwe, bo ludzie mają masę innych spotkań w ciągu dnia, więc robimy sobie dłuższe synchronizacyjne spotkania dwa razy w tygodniu i jakoś to się toczy… W końcu lepsze te dwa spotkania na tydzień niż nic”. Pytaniem, które tutaj mi się nasuwa jest: czy organizacja chciała/chce takiego Scrum Mastera i jaka jest wartość jego pracy dla organizacji?

Są też osoby, które próbują przesuwać granicę i dokonywać zmiany w tym, co na pozór wydaje się trudne lub niemożliwe do zmiany. Na pewno wymaga to dużo motywacji, cierpliwości i samozaparcia. Ale jeśli opór jest duży i jeżeli nie widać żadnych zmian – to często taka osoba realizuje jeden z powyższych scenariuszy i/lub potrzebuje pomocy terapeuty, aby wyjść z wypalenia zawodowego. 

Co możesz zrobić jako Scrum Master w tej sytuacji?

Jeżeli jesteś Scrum Masterem i jeżeli odnajdujesz się w tym opisie, jest kilka rzeczy, które mogą pomóc.

Po pierwsze: uświadom sobie jasno, jak jest. Scrum opiera się na empiryzmie. Jeżeli wszyscy mówią “tak, tak, chcemy się zmieniać”, ale jednocześnie widzisz wielki opór przy próbie zmiany workflow’u w Jirze – to empiryzm mówi: “bierz pod uwagę przede wszystkim swoje doświadczenie, a nie idee, o których słyszysz”.

Po drugie: pomyśl o tym, jakie są obecne granice twojego działania. Co możesz zmienić sam, na co możesz mieć wpływ, a na co wpływu aktualnie nie masz.

Mając te granice, możesz zastanowić się, czy praca w takich ograniczeniach jest dla ciebie satysfakcjonująca. Będziemy wydawać nowe wersje systemu co pół roku. Będziemy mieli system legacy, w którym nie da się pisać testów jednostkowych. Będziemy mieli kontraktora, któremu zlecamy całe zadania. Tak jest i szybko to się nie zmieni. Czy chcesz pracować z taką organizacją?

Po trzecie: buduj koalicję popierającą zmianę. Nawiązuj relacje, rozmawiaj o pomysłach, pytaj inne osoby o zdanie – nawet jeżeli nie są one zaangażowane w prace twojego zespołu.

Po czwarte: nastaw się bardziej na maraton niż na sprint. Jeżeli uda się coś wprowadzić szybko i sprawnie – tu super. Ale zmiany w dużych organizacjach przypomina eksperyment z kropli paku – dni mijają jeden za drugim i na pozór nic się nie zmienia. Dopiero kiedy spojrzymy na pracę z perspektywy czasu, widać że pewne rzeczy jednak wyglądają inaczej niż pół roku temu.

Po piąte: nie bierz na siebie pełnej odpowiedzialności za zmianę. Jeżeli organizacja zatrudnia cię jako agenta zmiany, ale sama nic nie robi w tym kierunku – to jest trochę tak, jakby otyła osoba zatrudniła osobistego trenera do ćwiczeń, ale sama nie miała wcale zamiaru tych ćwiczeń wykonywać. Nawet najlepszy trener nic nie zrobi w tej sytuacji.

Po szóste: zadbaj o siebie, o swoje zdrowie i o własną motywację. Dobrym pomysłem są okresowe rozmowy z kimś, kto będzie mógł spojrzeć z boku na to, co robisz i co się dzieje w całej organizacji. Pamiętaj, że martwy Scrum Master to bezużyteczny Scrum Master. Wypalony Scrum Master też nie będzie skuteczny.

Jak możesz pomóc Scrum Masterowi w tej sytuacji? 

Jeżeli jesteś menedżerem w takiej organizacji, a pod twoimi skrzydłami widzisz przygasającego i przytłoczonego Scrum Mastera – proszę zrób coś. Tutaj również jest kilka konkretnych rzeczy, które możesz zrobić. 

Nawet jeżeli twój Scrum Master wygląda jak chodzący optymista, silnie wierzący w to co robi i walczący o każdą zmianę – ale jest jedyną osobą, która dąży do zmian, to jest duże prawdopodobieństwo, że prędzej czy później po prostu się spali. On jest również człowiekiem i czasami potrzebuje pomocy.

Czasami wystarczy rozmowa z nim. Może tych rozmów będzie musiało być więcej. Pomóż mu określić granice, w których warto aby się poruszał. Zaplanuj z nim działania, które pomogą te granice przesunąć. Pomóż mu te działania wdrożyć w życie. 

Powiedz mu czego oczekujesz. Wypowiedz to normalnymi słowami. Nie używaj sformułowań i określeń z Scrum Guide’a. Powiedz, co chcesz osiągnąć. Nawet jeżeli uważasz, że to nie ma związku ze zwinnością. Przynajmniej będziecie grali w otwarte karty. 

Zaproponuj, że kilka zmian spróbujesz wprowadzić razem z nim. Jeżeli Scrum Master w Twojej organizacji traktowany jest jak przystawka do zespołu, to spróbuj to zmienić. On prawdopodobnie tego sam nie zmieni. Spróbuj przeforsować umiejscowienie go wyżej. Jeżeli nie wiesz, w jaki sposób to zrobić – spróbujcie razem!  

A jeżeli dopiero stoisz przed decyzją czy zatrudnić Scrum Mastera, a już wiesz, że sytuacje tu opisane są wysoce prawdopodobne, to zastanów się. Zamiast zatrudniać Scrum Mastera zacznij może od szkolenia kadry menedżerskiej oraz deweloperów? Poszukaj sojuszników i sponsorów zmiany, aby umocować tę zmianę w organizacji. Zastanów się, czego faktycznie będziesz od niego wymagał. Pamiętaj, on jest po to by zmieniać, a zmiany zawsze są trudne! Jest po to, abyś ty oraz twoja organizacja osiągali lepsze wyniki. Nie jest przystawką do zespołu, którego praca kończy się na facylitacji kilku wymaganych spotkań i zadbaniu, aby członkowie zespołu byli uśmiechnięci. 

Na zakończenie…

Zaczęliśmy od metafory związku Scrum Mastera z organizacją jako randki, na którą się umawiamy. Jest sporo podobieństw między tymi dwiema sytuacjami.

Pierwsze wrażenie często może być mylne. 

Żeby coś dobrego powstało, obie strony muszą chcieć i muszą się starać.

A kiedy coś w związku nie wychodzi, zawsze jest miejsce do tego, żeby porozmawiać o tym i spróbować coś zmienić. To może się udać – ale tylko, jeżeli chcą tego obie strony.