Gdy pisałem ostatni artykuł o tym, ile wart jest Scrum Master, powstrzymałem się od rozważań na temat niezbędnego zestawu kompetencji, jakie posiadać musi każdy, kto bierze na siebie tę odpowiedzialność. Pewnie i tak dało się między wierszami wyczytać, jakie mam zdanie na ten temat, ale chciałem poświęcić tej kwestii osobny artykuł.
Będzie to oczywiście mój subiektywny punkt widzenia i nawet nie zamierzam przekonywać nikogo do swoich racji. Okopy, w których umościli się zwolennicy i przeciwnicy tezy o wymogu posiadania kompetencji technicznych przez Scrum Mastera, są zbyt głębokie, bym zdołał wykurzyć z nich kogokolwiek.
Po co jest Scrum Master?
Wedle zapisów, jakie znaleźć można w Scrum Guide, ktoś taki bierze na siebie odpowiedzialność za spowodowanie, by Zespół Scrum, którego jest częścią, posługiwał się metodą w sposób zgodny z jej definicją. Przy czym nie chodzi tu o formalną zgodność, czyli robienie czegoś na pokaz, ale faktyczne działanie w procesie wykorzystującym empiryzm i niezbędne do tego elementy Scruma (zdarzenia i artefakty).
Nie dość na tym: tenże Scrum Master bierze na siebie odpowiedzialność za skuteczność w działaniu swojego Zespołu, co oznacza, że musi zadbać o powstanie środowiska sprzyjającego efektywnej pracy zarówno Product Ownera, jak i Developerów. Brzmi to dość srogo nie bez przyczyny, bo nie jest to wymóg łatwy do spełnienia. Scrum Master ma to bowiem osiągnąć, będąc po prostu członkiem Zespołu, a nie bezpośrednim przełożonym tworzących go ludzi. Ba, musi skutecznie wpłynąć na otoczenie Zespołu (czyli organizację, np. kadrę zarządzającą), jeśli jest to niezbędne dla ograniczenia marnotrawstwa, usunięcia utrudnień czy zwiększenia możliwości skutecznego działania.
W praktyce oznacza to, że Scrum Master pracuje na rzecz swego Zespołu zarówno z ludźmi, którzy ten Zespół tworzą wraz z nim, jak i tymi, którzy na warunki i sposób funkcjonowania Zespołu mają lub mogą mieć wpływ. Również z tymi ludźmi, którzy na co dzień wydają się odlegli i w żadną bezpośrednią interakcję z Developerami lub Product Ownerem nie wchodzą. Mogą np. być decydentami, od których zależy to, w jakim stopniu Zespół będzie w stanie posłużyć się dobrze Scrumem.
Dla pewności podkreślę, że Scrum Guide nie zawiera żadnej listy kompetencji wymaganych od Scrum Mastera. Nie bez przyczyny.
Co musi umieć Scrum Master?
Oczywistą rzeczą jest zrozumienie Scruma i to na poziomie wyższym niż umiejętność cytowania zapisów zawartych w Scrum Guide. Do dokumentu każdy może sięgnąć sam, Scrum Master powinien potrafić wyjaśnić, dlaczego są one takie, a nie inne. Inaczej mówiąc, na pytanie np. dlaczego Daily Scrum powinien odbywać się codziennie, nie wystarczy odpowiedzieć, że „tego wymaga definicja metody”. Równie chybiony będzie pomysł, by wyjaśnić pytającym, że „gdyby mógł się odbywać rzadziej, to nie nazywałby się Daily Scrumem”.
Mniej oczywistą rzeczą jest znajomość innych metod i praktyk zwinnych, bo Scruma nie da się używać bez sięgania po nie. Tak, jak szkielet ludzki nie jest człowiekiem, tak sam Scrum, będący szkieletem procesu (jego ramami, absolutnym minimum), nie tworzy kompletnego procesu, który ma szansę sensownie działać. Choćby dlatego, że aby zrealizować którekolwiek ze zdarzeń zdefiniowanych w Scrumie lub wytworzyć niezbędne artefakty, trzeba wybrać, znaleźć lub wymyślić skuteczny sposób na to. Ken Schwaber i Jeff Sutherland są do tego stopnia złośliwi, że nie dość, iż nie dołączyli do definicji metody instrukcji jej użytkowania, to jeszcze się chełpią, że jest ona celowo niekompletna…
Odkładając żarty na bok, jeśli spojrzy się na wymienione przeze mnie powody, dla których Scrum Master jest w Zespole Scrum potrzebny, widać od razu, że musi on coś (a najlepiej więcej, niż tylko coś) wiedzieć na różne tematy.
Po pierwsze, musi znać podstawy zarządzania produktem, bo bez tego niewiele pomoże Product Ownerowi i niczego go nie nauczy. W to wchodzi również znajomość różnych narzędzi, praktyk i technik, jakie mogą być do tego użyte (i nie, nie wystarczy wiedzieć, czym są historyjki użytkownika oraz story pointy, a Planning Poker nie powinien być jedyną metodą szacowania, jaką Scrum Master zna).
Po drugie, musi rozumieć podstawy pracy wykonywanej przez Developerów, bo bez tego niewiele wsparcia im będzie mógł udzielić, o ile w ogóle zauważy, że jakieś wsparcie jest potrzebne. Ponieważ produkty bywają różne, development pomiędzy Zespołami również różnić się będzie diametralnie. Dlatego Scrum Master Zespołu wytwarzającego oprogramowanie nie potrzebuje podstawowej wiedzy o produkcji mleka, ten z mleczarni nie musi wiedzieć, co to continuous integration. Choć może raczej powinienem napisać, że prawie na pewno nie musi, bo być może Zespół wytwarza oprogramowanie wykorzystywane do zarządzania linią produkcyjną jogurtów…
Scrum Master musi też wiedzieć coś o zarządzaniu organizacją i ludźmi, a najlepiej, by miał w tym jakieś minimalne choćby doświadczenie, np. jako lider Zespołu. Bez tego nie ma szans na dobrą współpracę z organizacją i ludźmi mającymi wymierny wpływ na środowisko, w jakim funkcjonuje Zespół. On nie będzie rozumiał ich potrzeb, oni problemów, z jakimi do nich przychodzi, bo nie będzie umiał ich sensownie przedstawić.
Czwarta kwestia: Scrum Master musi mieć podstawową wiedzę z zakresu zarządzania projektami, bo choć Scrum nie jest metodą projektową, jego interesariusze często będą kierownikami różnych projektów. Bez zrozumienia sposobu ich myślenia i działania, nie pomoże ani im, ani Zespołowi w znalezieniu sposobu na obsłużenie potrzeb projektowych bez okaleczenia lub wyrugowania empiryzmu ze Scruma.
Następną sprawą jest wiedza z szeroko rozumianego obszaru zapewnienia jakości. Bez tego Scrum Master ma nikłe szanse na zrozumienie, czym jest ukończony i wartościowy produkt, a tym samym nie będzie w stanie pomoc w jego wytwarzaniu Developerom i Product Ownerowi. W szczególności chodzi tu o ustanowienie dobrej Definicji Ukończenia, ale również o identyfikację i zbieranie miar związanych z jakością oraz wartością produktu – choć Scrum Master sam nie będzie tego robił, musi tego nauczyć swój Zespół.
Po szóste, Scrum Master musi być dobrym facylitatorem, bo często będzie moderował dyskusje, prowadził warsztaty, spotkania itd. Przyjdzie mu też zmierzyć się z konfliktami, musi więc znać różne techniki i narzędzia, które uchronią od doprowadzenia do jakiejś komunikacyjnej katastrofy.
Mało? Siódmy obszar to przynajmniej podstawowe umiejętności trenerskie, bo bardzo często Scrum Master musi stać się po prostu nauczycielem albo przygotować szkolenie lub warsztat.
Na koniec dodam potrzebę posiadania przynajmniej podstawowej wiedzy o coachingu i umiejętności zorganizowania krótkiej sesji coachingowej ad hoc, gdy zajdzie taka potrzeba. Celowo zostawiam to na koniec, bo wymaga dodatkowego komentarza, który (mam takie wrażenie) wywoła u niektórych osób oburzenie.
Otóż wielu Scrum Masterów skupia się właśnie na tym aspekcie swojej działalności, zapominając o wszystkich pozostałych albo traktując je po macoszemu. A szczerze mówiąc, coaching na niewiele się zda, jeśli podstawowym problemem Zespołu jest niestabilna infrastruktura, tyle że chcąc coś w tej sprawie zdziałać, Scrum Master musi wpierw rozumieć, co to właściwie znaczy.
Będę jeszcze bardziej sarkastyczny i napiszę, że spotkałem wielu Scrum Masterów, którzy naprawdę sporo wysiłku wkładali (i pewnie nadal to robią) w poszerzanie kompetencji coachingowych, jednocześnie mając nikłe lub dosłownie zerowe zrozumienie podstaw pracy, jaką wykonują Developerzy w ich Zespołach. I tak sobie myślę, że po prostu łatwiej nauczyć się dobrze jednej rzeczy, niż poszerzać swoje kompetencje w różnych obszarach. Tyle że nie jest to – moim zdaniem – najlepsza strategia na rozwój Scrum Mastera i zapewnienie sobie warsztatu niezbędnego do wywiązania się z podjętej odpowiedzialności.
„Techniczność” i „nietechniczność” Scrum Mastera
Określenia te usłyszeć można w trakcie dyskusji toczonych najczęściej w organizacjach, które zajmują się wytwarzaniem oprogramowania lub innych produktów mocno opartych o jakąś technologię. „Techniczny” Scrum Master w tym kontekście byłby więc osobą, która ma pojęcie o technologii albo przynajmniej rozumie podstawowe zagadnienia związane z jej rozwojem. Choć są i tacy, którzy powiedzą, iż Scrum Master może być uznany za „technicznego” tylko wtedy, gdy ma praktyczne doświadczenie w pracy Developera. „Nietechniczny” Scrum Master, przez analogię, jest więc kimś, kto nie ma ani wiedzy, ani zrozumienia, ani doświadczenia z rozwojem technologii.
Ten podział zapewne nie jest taki prosty i dlatego dyskusje o potrzebie „techniczności” Scrum Masterów toczą się od lat, są gorące i prowadzą dokładnie donikąd. Jak już wspomniałem na początku, zwolennicy każdej z tez, jakie przy tej okazji da się sformułować, zapadli w okopy i ostrzeliwują się z nich argumentami, nie dopuszczając do siebie myśli, że mogą się mylić.
Wypadałoby teraz napisać, jaka jest moja subiektywna definicja „techniczności” Scrum Mastera, ale tego nie zrobię, bo takowej nie mam. Uważam bowiem, że ta dyskusja jest chybiona od samego początku i dowodzi tak niezrozumienia tego, kim ma być Scrum Master, jak i braku zainteresowania odnośnie do tego, skąd właściwie ta odpowiedzialność w Scrumie się wzięła.
Dawno, dawno temu, gdy Scrum był młody…
…wtedy standardem było, że każdy Scrum Master rozumiał tak technologię, jaka używana była do wytwarzania produktu, jak i podstawy pracy Developerów. Z tej przyczyny, że każdy Scrum Master, jakiego wtedy można było spotkać, był jednocześnie Developerem. Po prostu któryś z Developerów w Zespole Scrum przejawiający większe niż pozostali zainteresowani procesem, samym Scrumem, mający ciągoty do dbania o to, by całość działała skutecznie, stawał się zespołowym mistrzem Scruma. Tak właśnie narodziła się (wyłoniła się) ta odpowiedzialność.
Czy wtedy dyskusja o „techniczności” Scrum Masterów miałaby jakikolwiek sens? Nie, a próba jej podjęcia skończyłaby się w najlepszym razie konfuzją. Oczywiście wiele lat później normą stali się Scrum Masterzy, którzy nie są równocześnie Developerami, ale… no, właśnie – oni wciąż są takimi samymi Scrum Masterami, jak ci pierwsi. Więc na logikę (ja wiem, że ona nie jest modna, ale dajmy bidulce szansę), powinni potrzebować tych samych umiejętności, czyż nie?
Przez wiele lat Scrum używany był głównie (o ile nie wyłącznie) przez Zespoły wytwarzające oprogramowanie i ludzi, dla których programowanie było czymś oczywistym, a często nawet życiową pasją. Więc było jasne, że każdy ówczesny Scrum Master z automatu wnosił w tę odpowiedzialność wszystkie posiadane kompetencje techniczne. A potem z nich korzystał, gdy tylko było to niezbędne.
Czy dziś Scrum Master w Zespole, który wytwarza oprogramowanie, będzie zmagał się z całkowicie innymi problemami, a w związku z tym będzie potrzebował zupełnie innych kompetencji, niż ci pierwsi Scrum Masterzy? Jasne, że nie. Sporo się zmieniło, ale większość problemów będzie podobna, jeśli nie taka sama. Ot, technologia się zmieniła, a i to niekoniecznie aż tak bardzo. Teza, że „nietechniczny” Scrum Master będzie pomocny dla swojego Zespołu w takim przypadku i że np. coachingiem zastąpi brak wiedzy o podstawach budowania oprogramowania, jest dość buńczuczna.
Skuteczny Scrum Master
Unikam mówienia o „technicznych” Scrum Masterach również dlatego, że to bardzo spłaszcza problem, który jest poważny. Scrum Master musi mieć kompetencje takie, jakich potrzebuje do skutecznego działania w konkretnym Zespole, którego jest częścią. W zależności od tego, czym ten Zespół się zajmuje i co ma największy wpływ (pozytywny lub negatywny) na jego skuteczność, różnych działań ze strony Scrum Mastera będzie potrzeba. Tego nie da się zawęzić do prostego wymogu klasy „Scrum Master w IT musi być Developerem”. Nie, nie musi, ale zdecydowanie łatwiej mu będzie sobie poradzić, jeśli będzie.
Dlatego wolę mówić o skutecznym Scrum Masterze, który ma kompetencje niezbędne do udzielenia pomocy Zespołowi (i jego otoczeniu) takiej, jaka jest potrzebna. Umiejętnościami coachingowymi nie da się zastąpić braku wiedzy o narzędziach developerskich, jeśli to z nimi Zespół ma problem. Podobnie jak kodowanie nie na wiele się przyda przy rozwiązywaniu konfliktów.
Jest też i drugi powód, dla którego nie posługuję się terminem „techniczny” lub „nietechniczny” Scrum Master. Nie uwzględniają one żadnych stanów pośrednich, np. „trochę techniczny”, „bardziej nietechniczny niż techniczny” itd. A przecież cała sztuka użycia Scruma polega na ciągłej adaptacji do zmiennych potrzeb. Dlaczegóż więc ktokolwiek miałby prawo oczekiwać od Scrum Mastera, że od razu będzie on w pełni „techniczny”, by sobie poradzić? Rozsądek podpowiada, że taki wymóg jest irracjonalny. Ważna jest przede wszystkim zdolność szybkiego pozyskania wiedzy i umiejętności w tym obszarze, w którym Scrum Master dostrzeże własne braki.
Trzecia kwestia: jakie kompetencje techniczne ma mieć Scrum Master pracujący w Zespole tworzącym oprogramowanie, np. edytor tekstu lub komunikator internetowy, żeby być wystarczająco „technicznym”? Większość osób odpowie, że musi umieć programować, znać standardy techniczne związane z aplikacjami internetowymi itd. Wydaje się to stosunkowo łatwe do ustalenia.
Trudniej będzie, jeśli ten Scrum Master pracuje w Zespole, który za pomocą oprogramowania wspiera pracę działu prawnego firmy zajmującej się wydobyciem miedzi. Czy aby być „technicznym” Scrum Masterem, ma się znać na programowaniu, pracy prawników, czy wydobyciu miedzi? A może na wszystkich tych rzeczach naraz? Z pozoru oczywista etykieta („techniczny”) przestaje być tak oczywista. Odpowiedź na pytanie, co się pod nią kryje, większość osób zaczęłaby w tej sytuacji od frazy „to zależy”.
W kontrze do tego, jeśli mówię o skutecznym Scrum Masterze, to nikt z moich rozmówców nie zaczyna odruchowo przekładać tego na jeden obszar niezbędnych kompetencji, tylko raczej zaczyna zastanawiać się (jeśli nie pamięta albo jeszcze nie wie), czym właściwie taki Scrum Master się zajmuje i co dowodziłoby jego skuteczności. Zdecydowanie wtedy łatwiej kontynuować rozmowę skupioną na merytorycznych kwestiach niż dysputę opartą na silnych przekonaniach, że ktoś musi lub nie musi być „techniczny”…
Primum non nocere
Podsumowując: Scrum Master powinien uzupełniać własne luki kompetencyjne, które sam zauważy lub które wskażą mu inni. Nie musi być wszechwiedzącym ekspertem, a jeśli ma wybierać między wąską specjalizacją lub pozyskaniem mniej wyspecjalizowanej wiedzy, ale za to w wielu obszarach, to zwykle rozsądniej będzie zrobić to drugie.
Nie trzeba przecież być ekspertem, by zauważyć istotny problem lub odkryć powód do podjęcia działań, natomiast całkowity brak wiedzy o czymś czyni zazwyczaj to coś absolutnie nieprzejrzystym. Nie jest dobrze, jeśli Scrum Master skupi się na tym, co robić potrafi, a nie tym, bez czego jego Zespół radził sobie będzie marnie.
Niezmiennie też warto trzymać się jednej z naczelnych zasad etyki lekarskiej, że przede wszystkim nie należy szkodzić. Żeby nie łamać jej zbyt często, trzeba być gotowym na szybkie pozyskiwanie wiedzy lub wsparcia ekspertów, gdy zdarzy się coś, czego Scrum Master jeszcze nie rozumie. I tak dzień po dniu, tydzień po tygodniu, Scrum Master, nawet ten postrzegany przez niektórych jako „nietechniczny”, zacznie działać skutecznie.
Antywzorzec
Na koniec poświęcę kilka zdań Scrum Masterom, którzy wkładają mnóstwo wysiłku w przypominanie wszystkim ludziom, z jakimi pracują, że powinni się rozwijać, wychodzić ze swojej strefy komfortu (nie mogłem się powstrzymać, ha!), że nie mogą gnuśnieć w silosach kompetencyjnych itd. Po czym na pytanie „a czemu ty się nie nauczysz…” (tu w miejsce kropek wstawić można cokolwiek) odpowiadają: „bo ja jestem Scrum Masterem”.
Nie ma nic gorszego niż wymaganie od innych czegoś, czego samemu się nie robi. Piszę o tym, bo zetknąłem się z takimi Scrum Masterami (i niejednym managerem, ale to już osobna historia), którzy byli antywzorcem postawy, jakiej oczekiwali od każdego.
Nie mam na tę tezę żadnego dowodu, ale sądzę, że zaczynem toczącej się dyskusji o potrzebie lub braku wymogu „techniczności” Scrum Masterów było pojawienie się w Zespołach zajmujących się technologią ludzi, którzy w skrzynce z narzędziami mieli wyłącznie techniki coachingowe i wiedzę z zakresu tzw. kompetencji miękkich, i którzy mimo ewidentnej potrzeby, nie zechcieli choć trochę nasiąknąć „technicznością”.
Problem pogłębił się, gdy Scrum stał się tak popularny, że praca Scrum Mastera stała się dla sporej rzeszy ludzi przepustką do dobrze płatnej pracy w branżach takich jak IT, do których wcześniej nie mieli szans się dostać ze względu na powszechny wymóg posiadania umiejętności developerskich. Dziś wiele z tych osób odkrywa, że firmy nie doceniły ich pracy (ciekawe czemu…). Szkoda, że rykoszetem obrywają też Scrum Masterzy, którzy mają potencjał, ale jestem pewien, że to minie – wahadło wychylone za daleko w jedną stronę, teraz poleciało równie daleko w drugą, ale się w końcu uspokoi.
