Scrum master… Dużo już o przedstawicielach tego fachu napisano, często niepochlebnie. Nie zna życia ten, kto od developera nie usłyszał nigdy, że scrum master to najmniej trafiona inwestycja w środek transportu karteczek samoprzylepnych albo największy upierdliwiec i tak upierdliwego uniwersum korporacji. Jasne, że nie ma co generalizować, ale w dzisiejszym wpisie postanowiłem podzielić się moimi refleksjami o tym, co może takie kategoryczne sądy uprawomocniać. Bo o tym, że bywają one uprawomocnione, jestem zupełnie przekonany. Piszę poniżej o symptomach, z którymi organoleptycznie zetknąłem się w dotychczasowej pracy, choć jestem pewien, że dałoby się nastukać jeszcze kilkanaście tysięcy znaków.
Będziesz miękki jak miś haribo!
W ten sposób zwykłem mawiać o strategiach tych scrum masterów, którzy wychodzą z założenia, że rama, którą w istocie jest scrum – bo przecież trudno uznać go za dookreśloną w każdym detalu metodę – jest wprawdzie fajna, ale misją przywódcy służebnego jest przede wszystkim dopieścić zespół developerski umiejętnościami miękkimi. Definition of done? Co? Na co to komu, przecież preferuję życie typu YOLO, więc o wiele lepiej będzie opowiedzieć zespołowi na retrospektywie sprintu o FUKO. Skrót przecież równie fajny jak DoD, nie? Która godzina? – zapytuje tester. Zerknąć na zegarek lub telefon byłoby zbyt proste, lepiej odpowiedzieć, że szczęśliwi czasu nie liczą, a droga do szczęścia wiedzie przez niekończącą się ścieżkę mindfullness.
Będę bardziej papieski od papieża!
Jest i druga strona medalu. Mianowicie dogmatycy. Scrum Guide mówi wprost: Role, artefakty, wydarzenia oraz reguły Scruma są niezmienne i choć możliwe jest wykorzystanie tylko niektórych jego elementów, wynikiem takiego postępowania nie będzie Scrum. Scrum istnieje tylko w swojej pełnej postaci i sprawdza się doskonale w roli ramy dla innych technik, metodyk czy praktyk. Jestem zdania, że to uczciwe postawienie sprawy. Twórcy scruma mówią jasno: bierzcie i jedzcie z tego wszyscy, eksperymentujcie, jeśli jednak decydujecie się na odstępstwa od opisanych w przewodniku podstaw, zróbcie nam przysługę i nie posługujcie się już rzeczownikiem scrum. Sęk w tym, że niektórzy scrum masterzy wyciągnęli na tej podstawie zbyt daleko idące wnioski. Otóż dokonali ekstrapolacji wierności założeniom na obszary, o których Jeff Sutherland i Ken Schwaber się nie zająknęli. I się zaczęło… Ciosanie członkom zespołów developerskich kołków na głowach, bo nie docenili piękna historyjek użytkownika, sceny rozpaczy, gdy ktoś śmie twierdzić, że story pointy to wcale nie jedyna droga do postulowanego przez Scrum Guide dodawania oszacowań do elementów backlogu produktu, odstawianie Rejtana, gdy ktoś uczestniczy w daily scrumie w pozycji siedzącej. I tak dalej, i tym podobne.
Chodź no synku, skołczuję cię!
W zasadzie to wariant strategii Będziesz miękki jak miś haribo, na tyle jednak upierdliwy, że godzien osobnego akapitu. Poznałem kiedyś takiego jednego. Lubił przechadzać się korytarzami biura, łowić ofiary i składać im, niczym Don Vito Corleone, oferty, których nie dało się odrzucić. Brzmiały tak: skołczuję cię. Serio. Wprawdzie nie był to scrum master, lecz tragizm sytuacji polegał na tym, że potrafił składać takie oferty również swoim podwładnym, a ci z reguły nie mieli śmiałości odmówić. Scrum masterzy również miewają podobne odchylenia. Coaching, o ile prowadzony poprawnie, może pomóc, ale przecież nie jest jedynym narzędziem scrum mastera. Ba, nie jest nawet narzędziem pierwszego wyboru. Na dodatek często zapominamy o tym, że zwykła rozmowa w cztery oczy w słabo wentylowanej, ciasnej salce biura ma się do coachingu tak mniej więcej jak zwinność do osteoporozy. No i serio, większość problemów naprawdę da się rozwiązać klarowną odpowiedzią, nie piętrzeniem pytań. Zresztą cały ambaras z coachingiem wynika według mnie, między innymi, z niuansów terminologicznych, które niuansami przestają być w zderzeniu teorii z praktyką. Oryginalna wersja Scrum Guide wspomina na przykład w związku z zakresem roli scrum mastera: Coaching the Development Team in self-organization and cross-functionality. Polskie tłumaczenie mówi tymczasem o coachowaniu, przy czym najbardziej rozpowszechnionym tłumaczeniem angielskiego to coach jest trenować, uczyć, instruować. Ale jakże to tak? Scrum master ma mówić, jak ma być? I jak się to ma do owej mitycznej samoorganizacji? Jestem zdania, że bywają sytuacje – i to wcale nierzadkie – w których scrum master ma mówić, jak ma być. Ma wyjaśniać, po co są artefakty, role i wydarzenia, a nie dopieszczać swoje ego pretensjami do przedszkolnej psychologii i prosić zespół, by sam zgadł, dlaczego na przykład powinien zadbać o backlog.
Nie wiem, nie znam się, zarobiony jestem…
Są powody, dla których rola scrum mastera została wyodrębniona, nazwana i opisana. Moim zdaniem nie znaczy to jednak, że granicą obszaru zainteresowania scrum mastera winien być scrum jako taki. Nie jestem zwolennikiem tezy o tym, by scrum master musiał wyrastać z twardego pnia technologicznego, ale coś mi mówi, że o wiele łatwiej pracować z inżynierami oprogramowania, gdy wie się na przykład, że TDD to nie skrót od nazwy organizacji peruwiańskich anarchistów.
Radźta se…
To, że zespół scrumowy prędzej czy później wpłynie na mieliznę, jest pewne. Jako mieliznę definiuję takie ograniczenia, które pozostają poza strefą bezpośredniego wpływu członków zespołu. To są te chwile, w których na retrospektywie pada cierpkie: nic z tym nie zrobimy, za krótcy jesteśmy. To są te chwile, w których na głowy członków zespołu spada balast organizacyjny. To są wreszcie te chwile, w których scrum master patrzy w podłogę albo kwituje słowami: weźcie się w garść, jakoś to będzie. No, będzie. Kiepsko. Nie twierdzę, że scrum master powinien dźwigać na swoich barkach ciężar całego świata, ale przecież jednym z jego zadań jest – cytuję – wspieranie pracowników i interesariuszy w zrozumieniu i stosowaniu scruma oraz empirycznego podejścia do rozwoju produktu. Pracowników, nie tylko członków zespołów scrumowych, specyfika pracy których nie musi być rozumiana i nie będzie od początku rozumiana przez każdego członka i członkinię organizacji. Dlatego scrum master musi czasem pójść w świat.
A Wy? Za co natarlibyście kiepskim scrum masterom uszu?