Uwaga! Pułapka!

Dawno temu, gdy zaczynałem swoją scrum masterską przygodę, wpadłem w pewną – własnoręcznie na siebie zastawioną – pułapkę. Całe szczęście nad wszystkim czuwał świetny mentor, który pomógł mi „zacząć rozumieć” i się z niej cało wydostać. Ostatnio, remontując dom, miałem ogrom czasu na przemyślenia, refleksje, wewnętrzne retrospekcje, etc 😉 Uświadomiłem sobie, że warto podzielić się z Wami pewną obserwacją. Praktycznie w każdej organizacji, dla której do tej pory pracowałem, można było zaobserwować, jak stawiający pierwsze kroki w swojej nowej roli scrum masterzy czy agile coache pakują się w podobną pułapkę do tej mojej sprzed lat.

O co chodzi? Opiszę na konkretnych przykładach.

Przykład 1., w którym to ja nieświadomie wpakowałem się w tarapaty

Zanim zostałem scrum masterem, zajmowałem się programowaniem. Efekt mojej pracy był widoczny jak na dłoni. Każda minuta poświęcona na pisanie kodu miała przełożenie na działający system informatyczny. Nie musiałem nikomu udowadniać, że w pracy rzeczywiście pracuję. Natura ludzka bywa jednak przewrotna i pewnego dnia postanowiłem to wszystko rzucić i… może nie wyjechać w Bieszczady, jak w swojej piosence radził Wojtek Młynarski,

ale… zostać „mistrzem młyna”. Scrum masterem! Na początku ciekawość, pogoń za wiedzą i oczywiście prowadzenie spotkań wypełniały mi szczelnie osiem, a może nawet więcej, godzin każdego dnia. Jednak gdy wszedłem w fazę „młodocianego kierowcy, który ma prawko od miesiąca” i zaczęło mi towarzyszyć wrażenie, że „ogarniam kuwetę”, a może nawet jestem niezłym „miszczem”, przyszła chwila zwątpienia… Kurde, w piątek przygotuję się do retrospekcji, poprowadzę w zespole podsumowanie sprintu i retrospekcję, do której zresztą się perfekcyjnie przygotowałem z tymi wszystkimi kredkami, karteczkami, wycinankami. W poniedziałek poprowadzę zespołowi planowanie, później podrukuję im historyjki z Jiry – kolejny dzionek zleci. Ale u licha co z wtorkiem, środą i czwartkiem? W te dni mam tylko 15 minut pracy! No i zacząłem pakować się w tarapaty – w aktywności, których efekty mogły udowodnić (dzisiaj wiem, że tylko mi, wówczas myślałem, że całemu światu), że rzeczywiście coś w tej „robocie” robię. Drukowałem i rozklejałem jakieś kolorowe plakaty, wymyślałem przedziwne ankiety. Niczym przodownik pracy w czasach słusznie minionych własnoręcznie rozwiązywałem zespołowi kolejne „impedimenta”. Na każdym spotkaniu byłem sekretarzem, który skrzętnie zapisywał wszystko w Jirze. Widać było, że coś robię. Tylko, czy na pewno to, co scrum master robić powinien? Czy dzisiaj zapłaciłbym sobie wynagrodzenie za taką pracę? Hmm… raczej marnie to widzę. Całe szczęście, jak wcześniej wspomniałem, w moim zasięgu był świetny mentor, który dał mi szansę poukładać sobie wszystko w głowie.

Przykład 2., w którym dostałem rykoszetem po koledze, co to zabrnął w ślepy zaułek.

Rozpoczynałem przygodę w kolejnej, tym razem malutkiej firmie. Na pierwszym spotkaniu (było to planowanie sprintu) zespół posadził mnie przed komputerem. Wywiązał się taki mniej więcej dialog:

– scrum master, pisz to wszystko w Jirze!

– hmm, dlaczego chcecie, żebym to ja pisał Wam historyjki w Jirze?

– bo poprzedni scrum master tak robił!

– no, ok, ale to nie znaczy, że ja też tak będę robił.

– no to co będziesz robił?

To wejście w zespół dobitnie pokazało, że mój poprzednik, wyłoniony na scrum mastera, ze struktur deweloperskich firmy, wpadł w tę samą pułapkę, co ja przed laty. Nie do końca rozumiejąc swoją nową rolę, rzucił się w wir prac, które widać, ale za które niekoniecznie chcemy płacić mistrzom młyna. Jak się później okazało nieszczęśnik zabrnął dalej – pisał dokumentację, testował. Coś przecież po daily trzeba było robić. Zamiast ruszyć z kopyta z uzwinnianiem zespołu, musiałem na początku zbudować w organizacji (począwszy od deweloperów, a skończywszy na zarządzie) zrozumienie roli i wartości, jaką może wnieść do organizacji. Jak już ten etap miałem za sobą, mogłem przystąpić do właściwej pracy. Po jakimś czasie deweloperzy samodzielnie pisali historyjki w Jirze, nie robili tego na planowaniu, a ich treść była dla wszystkich zrozumiała i spełniała Definition of Ready. Dokumentacja była elementem każdej historyjki, pisał ją cały zespół, a testy zaczęły być automatyzowane. I… nie wymądrzając się, w dużej mierze było to zasługą scrum mastera, który nie imał się każdej pracy, tylko systematycznie, skutecznie robił swoją, czasami niewidoczną, robotę.

Przykład 3., w którym byłem już świadomy istnienia pułapki.

Znowu zaczynałem przygodę z nową firmą – tym razem ogromną instytucją finansową. Zatrudniono kilkoro agile coachów z rynku, natomiast duże grono zostało wyłonione z wewnętrznych struktur w ramach rekrutacji wewnętrznych. Koleżanki i koledzy stawiali pierwsze kroki w zwinnym świecie. W trakcie wspólnej pracy dane mi było przeprowadzić z nimi szereg rozmów indywidualnych, podczas których, po jakimś czasie, zaczęło wychodzić jak na dłoni, że początkowy entuzjazm i pęd zaczynają wyhamowywać i pojawiają się wątpliwości przechodzące w stan lękowy – „co ja tak właściwie powinnam / powinienem robić po daily?”. Dużo rozmawialiśmy o roli agile coacha, o wartości, jaką wnosi do organizacji, o tym kiedy tę wartość może wnieść a kiedy nie, co może i powinien robić, a czego unikać. Niektórym udało się pomóc przejść przez problem niemalże bezboleśnie, niektórzy musieli się sparzyć na własnej skórze – taka natura ludzka.

No dobra. Koniec z przykładami. Po co i dla kogo ja to wszystko tutaj piszę?

No to po kolei:

– jeśli stawiasz pierwsze kroki w nowej roli scrum mastera lub agile coacha, to na bank za chwilę zaczniesz zadawać sobie pytanie, co tak właściwie powinnam / powinienem robić? Przypomnij sobie wówczas ten post i zauważ, że to nie jest tylko Twój indywidualny, odosobniony przypadek. Z tym problemem zmaga się spore grono naszych koleżanek i kolegów po fachu. Fajnie, jak masz pod ręką kogoś doświadczonego, kto może Ci pomóc przejść przez ten proces. Jeśli nikogo takiego nie ma – szukaj w lokalnej społeczności Agile, pisz do nas https://doagile.pl/kontakt/ albo np. przeczytaj świetny artykuł „Co robi Scrum Master” Tomka Wykowskiego https://procognita.pl/post/co-robi-scrum-master-376

– jeśli z niejednego zwinnego pieca chleb już jadłeś, a wokół Ciebie są osoby stawiające pierwsze kroki – zaopiekuj się nimi. Pomóż im zrozumieć. Podsuń tego posta do poczytania. Fajnie, jeśli pokażesz na swoim przykładzie, na czym Ty niemal poległeś, zaczynając z agile.

– jeżeli jesteś „wielkim szefem” i planujesz uzwinnić swoją firmę, to miej na uwadze to, co napisałem, proszę. Jeśli do roli scrum mastera powołasz kogoś z wewnątrz swojej firmy i nie zapewnisz mu / jej odpowiedniego wsparcia osoby doświadczonej (nie teoretyka) – to tylko stracisz kasę. Mimo szczerych chęci, ten samotny agent zwinności z dużym prawdopodobieństwem wpadnie w pułapkę, którą tu pokazałem. Ty będziesz myślał, że zatrudniasz scrum mastera, a w rzeczywistości będziesz miał znerwicowanego sekretarza i gościa „podaj, przynieś, pozamiataj” w zespole. Takie podejście narobi więcej szkód niż pożytku. Scrum master nabawi się nerwicy, zespół doświadczy złych praktyk i wyrobi sobie negatywną opinię o tym całym agile, a Ty będziesz żył w Matrixie, dumnie rozpowiadając wszem i wobec, że Twoja firma jest zwinna i nawet masz scrum mastera.

– jeżeli nie kwalifikujesz się do żadnej z wyżej wymienionych grup czytelników… wybacz. W sumie mogłem Cię ostrzec na początku 😉