W pierwszych dwóch artykułach na temat kiepskich Scrum Masterów (część pierwsza i część druga) opisuję dwadzieścia dwa różne objawy, na które warto zwrócić uwagę. Zostało jeszcze jedenaście kolejnych, więc bez dalszej zwłoki, zapraszam do lektury.
Więcej mówi, niż słucha i wszędzie go pełno
Podjęcie trafnych decyzji odnośnie do sposobu działania przez Scrum Mastera wymaga zrozumienia charakteru problemów, przed jakimi stoi jego Zespół. A to ciężko zrobić, jeśli jest się kiepskim obserwatorem i słuchaczem. Kiepski Scrum Master ma tendencję do bycia w centrum uwagi, nieustannie go widać i słychać.
Przy czym niekoniecznie wynikać to musi z dążenia do wykazania, że jest się aktywnym i potrzebnym. Czasami jest to efekt naturalnej skłonności do bycia taką właśnie duszą towarzystwa i wykazywania się skutecznością w rozwiązywaniu problemów, kreatywnością, pomysłowością itd. O ile wszystkie te cechy są istotnie przydatne Scrum Masterom, nieumiejętność powstrzymania się od dominowania nad innymi osobami w Zespole jest zdecydowanie słabością.
A jeszcze gorzej, gdy Scrum Master, który ma świadomość tej swojej słabości, zaczyna się frustrować, że nie ma okazji, by się wykazać, albo wręcz świadomie poddaje się jej, byleby miał okazję zabłysnąć. Wtedy, zamiast pomagać Zespołowi, zaczyna mu szkodzić, bo mniej lub bardziej dosłownie stanie się liderem nie tylko w obszarze Scruma, ale i każdym innym.
Dostarcza wędzone ryby zamiast wędek
Niektórzy kiepscy Scrum Masterzy uzyskali wysoką skuteczność swoich Zespołów w ten sposób, że proaktywnie przeciwdziałają wszelkim problemom, miotają się od lewa do prawa, zapewniając niezakłóconą pracę Developerom i Product Ownerowi. Ta powszechna szczęśliwość trwa oczywiście tylko do momentu, aż Scrum Master pójdzie na urlop – wtedy wszystko się sypie i Zespół sobie przestaje radzić.
Scrum Master ma obowiązek doprowadzić Zespół do skuteczności poprzez jego rozwój, a nie zastępując Developerów i Product Ownera w nim. Zespół, którego skuteczność w znacznym stopniu lub całkowicie opiera się na umiejętnościach i dostępności Scrum Mastera, jest w istocie bardzo kruchy i ograniczony. Ktoś, kto świadomie (choć w dobrych intencjach) tak realizuje swoje obowiązki, jest marnym Scrum Masterem.
Nie potrafi cieszyć się sukcesem innych
Jeśli interesariusze zadowoleni są z produktu, który odnosi sukces komercyjny i rynkowy, pochwały zbiera Product Owner i czasami – choć nie zawsze (to niesprawiedliwe, ale tak niestety bywa) – Developerzy. Scrum Masterów rzadko się chwali, co czasami prowokuje niektórych z nich do szukania sposobu, by jednak wykazać się, by zabłysnąć…
Prawdziwy dramat zaczyna się, gdy ktoś potrzebuje tych pochwał jak kania dżdżu i ich brak zaczyna odbierać jako osobistą porażkę. Czasami wiedzie to do szkodliwego działania, które nastawione jest na uzyskanie choćby chwilowej chwały nawet kosztem Zespołu. Częściej takie osoby – więdnące, jeśli nie są doceniane za indywidualne osiągnięcia – zaczynają frustrować się swoją pracą, a nawet potrafią ją zupełnie znienawidzić.
Ktoś taki mimo najszczerszych chęci będzie w najlepszym razie przeciętnym Scrum Masterem. Nie warto samemu sobie tego robić. Po prostu Scrum Master, by zachować pasję do swojej pracy, musi być tym typem osoby, która cieszy, że mogła pomóc. I być dumnym, jeśli ktoś, z kim pracował, stanie się nawet lepszy od swego Scrum Mastera, przerastając mistrza.
Zbiera miary, których nikt nie rozumie i nie używa
Jest truizmem powiedzenie, że aby podejmować decyzje w sposób empiryczny, należy najpierw ustalić fakty, czyli zebrać dane opisujące rzeczywistość. Każdy Zespół Scrum powinien poszukać takich miar, które Developerom i Product Ownerowi w nim pomogą w skutecznym działaniu.
Zdarza się jednak, że Zespoły gromadzą mnóstwo danych, na które nie patrzy w zasadzie nikt poza Scrum Masterem. Albo wręcz zbierają je dla Scrum Mastera, aby dokonał nad nimi jakiejś swojej magii i obwieścił, co należy robić.
Ten sposób działania Scrum Mastera skutkuje brakiem przejrzystości, bo Scrum Master zaczyna być traktowany jako „szaman od miar”, których bez niego nikt nie rozumie. A jak nie rozumie, to być może nie będzie się nimi przejmował… Nie mówiąc już o tym, że być może Scrum Master źle te dane zbiera i analizuje, prowadząc Zespół na manowce. Albo wszyscy tracą czas na gromadzenie informacji, które są w istocie bez znaczenia – tylko po to, by Scrum Master mógł narysować piękne wykresy.
Skupia Zespół na potrzebach Scrum Mastera
W istocie nic, co Zespół robi, nie powinno być wykonywane na potrzeby Scrum Mastera – dotyczy to nie tylko miar, ale każdego innego działania. Scrum Master ma pomagać Zespołowi, a nie dokładać mu roboty.
Oczywiście Scrum Master może potrzebować czegoś, co ułatwi mu pracę, a co wymaga wysiłku ze strony Developerów lub Product Ownera. I jak najbardziej ma prawo domagać się, by to coś powstało, jednakże pod warunkiem, że przyniesie to korzyści całemu Zespołowi. Jeśli jedynym beneficjentem miałby być Scrum Master, to znaczy, że nadużywa on swego wpływu do tego, by zaoszczędzić sobie wysiłku. Nie tędy droga.
Przy czym ktoś może powiedzieć, że przecież jeśli Scrum Masterowi będzie łatwiej, to i tak Zespół na tym skorzysta. Cóż, nie zawsze tak niestety jest. Niektórzy Scrum Masterzy potrafią zaspokajać swoją kompulsywną potrzebę kontroli nad sytuacją przez zbieranie ogromu danych kosztem wysiłku całego Zespołu – tak, jak pisałem wcześniej. Inni gromadzą „kwity” dowodzące, że są bardzo skuteczni i pracowici – znów nierzadko kosztem Zespołu. A są i tacy, co potrafią celowo wywołać kryzys, by go potem heroicznie (choć w zaplanowany z góry sposób) rozwiązać, a potem chwalić się tym na prawo i lewo.
Zakłamuje rzeczywistość i maluje trawę na zielono
Dążenie do wykazania się skutecznością może przybrać skrajne formy. Są Scrum Masterzy, którzy nie potrafią się powstrzymać od celebrowania sukcesów nawet tam, gdzie ich nie ma.
Czasami wynika to ze źle rozumianego dążenia do poprawy morale w Zespole, co jest o tyle chybione, że brak faktycznych sukcesów w zderzeniu z budowaniem wrażenia, jakby było ich pełno, będzie dawał efekt odwrotny do zamierzonego.
Innym razem wynika to silnego przekonania, że pozytywne nastawienie pozwoli pokonać każdą przeszkodę, z czym co do zasady trzeba się zgodzić, pod warunkiem, że zachowujemy przy tym stały kontakt z rzeczywistością. A niestety zdarzają się kiepscy Scrum Masterzy, którzy do tego stopnia zaczadzili się potrzebą pozytywnego nastawienia za wszelką cenę, że wręcz zabraniają mówić o problemach. Efekt: traktowani są przez Zespoły albo z pobłażaniem, albo z politowaniem, a czasami wrogo, bo ludzie nie lubią braku realizmu.
Popada w manieryzm językowy
Skoro już mowa o oderwaniu od rzeczywistości, jedną z cech niektórych kiepskich Scrum Masterów jest przywiązywanie przesadnej wagi do stosowanego słownictwa. O ile sam zachęcam Scrum Masterów, by w miarę możliwości stosowali prawidłową terminologię, o tyle przestrzegam przed zmuszaniem innych do takiej poprawności za wszelką cenę.
A ma to wiele dziwacznych form. Niektórzy np. zabraniają mówienia o problemach, bo to takie negatywne – zamiast tego należy mówić i pisać o „możliwościach”, jakie się przed Zespołem otwierają. Cóż, problem to problem, a jedyną pozytywną rzeczą, jaką można powiedzieć w tej sytuacji, jest to, że wiedząc o jego istnieniu mamy większą szansę na znalezienie rozwiązania, niż gdybyśmy nie wiedzieli. Oczekiwanie od ludzi, że będą się cieszyć, że jest problem… cóż, to nieporozumienie.
Taki manieryzm może negatywnie wpływać tak na przejrzystość i klarowność komunikacji w Zespole, jak i na relacje między tworzącymi go ludźmi. Scrum Master nie powinien być tym, który generuje dodatkowe ograniczenia lub konflikty, ale ma je usuwać.
Nie ma i nie chce mieć pojęcia o developmencie
Scrum Master nie musi być jednocześnie Developerem w swoim Zespole, choć może nim być. Ten brak konieczności bycia Developerem nie jest równoznaczny z brakiem konieczności posiadania przynajmniej podstawowej wiedzy o developmencie.
Jej brak utrudni lub uniemożliwi zauważenie nieefektywności w pracy Developerów, nie mówiąc już o niemożności udzielenia im sensownej pomocy, gdyby była ona potrzebna. Ba, Scrum Master całkowicie pozbawiony wiedzy developerskiej może mieć kłopot ze zrozumieniem problemu, o jaki Developerzy wprost mu mówią, prosząc o radę, co zrobić w tej sytuacji.
A może być gorzej, gdy Scrum Master z jednej strony domaga się od Developerów, by maksymalizowali swoją wszechstronność i nie trzymali się kurczowo obszarów specjalizacji, w których mają największe kompetencje, z drugiej zaś strony sam odmawiając nauczenia się choćby podstaw developmentu.
Zdarzyło mi się zaobserwować, jak na wytknięcie braku konsekwencji w takim postępowaniu przez Developerów, ich Scrum Master odparował: „bo ja jestem Scrum Masterem i zajmuję się Scrumem, a nie developmentem”. Cóż, wyszło na to, że Scrum – wedle tego Scrum Mastera – nie ma z developmentem nic wspólnego, co byłoby zabawne, gdyby nie było straszne.
Zna tylko Scrum i wszędzie chce go użyć
Scrum Master musi zadbać o poznanie nie tylko podstaw pracy Developerów, z jakim współpracuje, ale potrzebuje też wiedzy o zarządzaniu produktem i różnych technikach, które można do tego wykorzystać, by móc efektywnie pomagać swojemu Product Ownerowi.
Mało tego: Scrum Master powinien znać różne techniki szacowania, prognozowania, zarządzania organizacją pracy, komunikacji, rozwiązywania konfliktów – cokolwiek będzie potrzebne jego Zespołowi.
Nie może też zamykać się wyłącznie w Scrumie, ale powinien znać inne potencjalnie konkurencyjne lub uzupełniające podejścia – w pierwszym rzędzie powinien to być Kanban, bo każdy Zespół wcześniej lub później będzie rozważał sięgnięcie po tę strategię (albo i porzucenie Scruma na rzecz Kanbana).
Im uboższy jest zasobnik z narzędziami, jakimi może posłużyć się Scrum Master, tym mniej może on zrobić dla Zespołu lub organizacji. Tym mniej można też się od niego nauczyć. Kiepscy Scrum Masterzy mają w tym zasobniku zwykle tylko Scrum Guide (zwracam uwagę, że nawet nie Scrum, a wyłącznie dokument opisujący jego definicję).
Nie rozwija się zawodowo
Żeby skutecznie działać jako Scrum Master, nieustannie trzeba się czegoś uczyć, bo rzeczywistość, w jakiej funkcjonuje Zespół, jest zmienna. Do tego nie można być wiecznie Scrum Masterem – kiedyś trzeba pójść w nieco inną stronę, np. zostając Product Ownerem, biorąc na siebie odpowiedzialność za zarządzanie kawałkiem organizacji, prowadząc szkolenia – jest wiele takich potencjalnych dróg rozwoju.
Ktoś, ktoś uwił sobie ciepłe gniazdko w jednym miejscu i nie zamierza się z niego ruszyć, starannie ignorując objawy zmienności środowiska, w jakim funkcjonuje, nie ma szans być dobrym Scrum Masterem. Choćby dlatego, że coraz bardziej będzie odstawał od otaczającej go rzeczywistości, coraz mniej adekwatne będą środki, po które władny będzie sięgnąć, a może w ogóle przestanie nadążać za tym, co się dokoła dzieje.
Poza tym cóż to za agent zmiany, skoro sam jej unika? Jak nakłonić innych do rozwoju i pomóc im w nim, skoro samemu nie jest się w stanie rozwijać, ani nie widzi takiej potrzeby?
Tkwi w nieuleczalnie chorej organizacji, zamiast odejść
Są firmy, w których nie ma możliwości pracować w sposób sensowny, nie mówiąc już o prawidłowym użyciu Scruma. Mają tak wypaczoną kulturę, toksyczną i zakłamaną, że potrzebna byłaby zmiana w skali, która zabiłaby organizację. Być może wciąż warto byłoby to zrobić, a zwłokami użyźnić ziemię pod coś lepszego, niemniej przeciętny Scrum Master nie ma możliwości zdecydowania o tym.
Oznacza to, że są miejsca, z których w pewnym momencie należy odejść, jeśli chce się uniknąć trwałego skażenia. Zostając choćby jeden dzień dłużej, ulegnie się powolnej degradacji, bo aby nie oszaleć, trzeba zacząć racjonalizować jako sensowne to, co sensu nie ma. I robić rzeczy fundamentalnie sprzeczne z tym, co rozsądni i przyzwoici ludzie robić powinni.
Jeśli ktoś jest długo Scrum Masterem w takim miejscu, to albo nie dostrzega jego deficytów, albo z jakiegoś powodu postanowił je zaakceptować, wiedząc jednocześnie, że nie zdoła nic z tym zrobić. Być może zresztą nawet nie zamierza próbować… Tak czy inaczej, kiepski to Scrum Master, skoro nie widzi powodu, by poszukać sobie lepszego miejsca.
Kilka słów na koniec
Opisałem cały szereg różnych postaw, działań i cech kiepskich Scrum Masterów. Jeśli ktoś z czytelników pomyślał z niepokojem „o, ten kawałek to wypisz wymaluj o mnie…” – to dobrze. Ten niepokój sygnalizuje chęć zrobienia czegoś lepiej, otworzenie się jakiejś nowej perspektywy, przyjęcie innego punktu widzenia itd. To zawsze pierwszy krok do rozwoju. Czyli czegoś, co charakteryzuje dobrych Scrum Masterów.
Gorzej, jeśli ktoś w trakcie lektury zauważa sporo stwierdzeń, które pasują do jego postępowania, a jednocześnie fundamentalnie nie zgadza się z wszystkimi moimi wnioskami. Nie uzurpuję sobie prawa do nieomylności i wszechwiedzy na temat Scruma i Scrum Masterów (nie istnieje zresztą nikt, kto mógłby tak o sobie powiedzieć). Niemniej nie mogę aż tak się mylić, by w każdym przypadku wyciągać błędne wnioski, czyż nie? Więc jakby to powiedzieć… być może ktoś taki, o kim pisałem, nie jest najlepszym Scrum Masterem.
Przypominam też, że celem tej serii artykułów jest sprowokowanie Scrum Masterów do autorefleksji i ewentualnych korekt w sposobie postępowania. Nie spodziewam się, by każdy zgodził się ze mną w stu procentach, ale w myśl zasady dla każdego coś przykrego (to tytuł książki A. Sandauera), postanowiłem przeciągnąć prętem po klatce.
A jeśli komuś teksty te pomogą w podjęciu decyzji o rozpoczęciu pracy jako Scrum Master (lub zrezygnowaniu z niej), to dobrze. Jest objawem profesjonalizmu i dojrzałości świadome branie na siebie zobowiązań, ale również rezygnowanie z czegoś, do czego się średnio nadajemy.
