4 marca 2019

Jak zostać Scrum Masterem?

Odpowiedź na tytułowe pytanie obiecałem w artykule Za waterfalla było lepiej. Wspomniałem tam wówczas, że słyszę je zaskakująco często. Przez ostatnio pół roku, które minęło od czasu opublikowania tego tekstu, chyba jeszcze częściej. I to od osób będących dotychczas od IT tak daleko, jak na mapie Nowe Warpno od Wołosatego. Pracujących w zupełnie innych branżach, zawodach…

Pisałem tamże również o tym, że mamy czasy niezwykłej prosperity dla specjalistów branży IT, walczy się o nich, stawki są wygórowane, firmy nie żałują ptasiego mleczka. Duża i wciąż wzrastająca ilość etatów do obsadzenia, stworzyła w tej branży rynek pracownika, zjawisko w naszym kraju dotychczas niezwykle rzadkie.

Nie dziwi więc fakt istnego oblężenia różnego rodzaju dni otwartych w firmach IT, szkoleń, kursów, akademii edukujących, głównie w zakresie programowania, ale i innych umiejętności potrzebnych w świecie wytwarzania oprogramowania. W rozmowach z organizatorami tych wydarzeń słyszę, że wśród uczestników jest coraz więcej praktykujących nauczycieli, księgowych czy przedstawicieli popularnej “budowlanki”.

Wraz ze wzrostem zainteresowania pracą (i płacą) w IT, ale i faktem, że coraz więcej ludzi po prostu w tej branży pracuje, szerzy się wiedza o istnieniu Scruma i agile’a. Co ważne hasła te, jak i praktyka za nimi stojąca, pozbawione są już nimbu tajemniczości, nie są traktowane jak kuriozum rodem z panoptikum zarządzania – coś abstrakcyjnego i absurdalnego niczym kosmiczne jaszczury, reptoidy z któregoś tam poziomu gęstości. Coraz częściej ludzie słyszą o takim stanowisku/roli jak Scrum Master. I coraz więcej osób to intryguje, zaciekawia, czuje, że może jest to coś, w czym byliby dobrzy, w czym mogliby się sprawdzić.

I tu właśnie padają pytania. Jak to wygląda w praktyce? Jak zacząć? Czy to faktycznie dla mnie? Co trzeba umieć?

Spróbuję na nie odpowiedzieć. Od razu ostrzegam – to dość długa opowieść. Niestety, i w tym przypadku – nie ma magicznej pigułki, nie da się też opowiedzieć o tym w kilku zdaniach, nie ma możliwości pójścia na skróty.

Scrum Master z krwi i kości, czyli kto?

Zanim jednak przejdę do szczegółów, kilka istotnych zastrzeżeń.

Mamy ogromne zróżnicowanie ofert i oczekiwań do roli Scrum Mastera, tego, co powinien robić na co dzień, czym się zajmować. Nierzadko, niestety, mamy do czynienia z takimi, które nie mają z pierwotnymi założeniami czy scrumową definicją tej roli absolutnie nic wspólnego.

Innym, mocno wybijającym się ostatnio zjawiskiem, jest zredukowanie roli Scrum Mastera do pracy wyłącznie z zespołami deweloperskimi. Jest to szczególnie widoczne w większych firmach, działających wedle zasad jakiegoś frameworka próbującego okiełznać i zaimplementować agile w dużej skali (np. bardzo mocno oprocedurowanego SAFe), gdzie Scrum Master to po prostu trybik w maszynie. Ktoś wydelegowany do przeprowadzenia w zespole określonych działań i uzyskania konkretnych efektów.

W konsekwencji zdobyć pracę jako Scrum Master jest w dzisiejszych czasach zaskakująco łatwo. Potrzeby rynku są doprawdy ogromne i wcale nierzadko wystarczy odpowiednia ogłada, inteligencja, kultura osobista, podstawowa baza pojęć, aby zostać zatrudnionym na tym stanowisko, mając elementarną wiedzę i nikłe doświadczenie. A jeśli ktoś ma certyfikację (o której później) lub jakąś praktykę, to już w ogóle…

Czy coś w tym złego? I tak, i nie… Jest to na pewno jedna z dróg, żeby zobaczyć o co tu w ogóle chodzi, zdobyć potrzebne doświadczenie. Z drugiej strony, często kończy się to realizacją zadań zasadniczo odbiegających od istoty tej roli, a wręcz ją deprecjonujących. Kiedy na prowadzonych przez siebie szkoleniach wprowadzających do Scruma, pytałem audytorium o to, czy wiedzą na czym polega praca Scrum Mastera, zdarzały się sytuacje, że zgłaszały się osoby, które miały już do czynienia ze “Scrumem” w praktyce, a ich, prezentowane z lekkim przekąsem, odpowiedzi, delikatnie mówiąc, wprowadzały mnie w lekkie osłupienie. Przykłady? To taki ktoś w zespole deweloperskim, który robi to, czego nikt inny nie chce robić; Sekretarz zespołu, rezerwujący salki na spotkania, prowadzący notatki ze wszystkich spotkań i prowadzący dokumentację; Dba o to, żeby w Jirze wszystko się zgadzało z tym co robimy; Jak programista ma problem, to Scrum Master jest od tego, żeby ten problem rozwiązać. To taki HR wewnątrz zespołu, dbający o dobrą atmosferę i organizujący różne gry i zabawy.

Nie, to nie są koszmary Kena Schwabera i Jeffa Sutherlanda…  Okazuje się, że można pracować jako Scrum Master długi czas, będąc bardzo daleko od tego, jak to powinno wyglądać.

Wracając do tytułowego pytania, w tym artykule chciałbym przedstawić drogę do tego żeby nie tyle zostać Scrum Masterem, co zostać dobrym Scrum Masterem, Scrum Masterem z krwi i kości. Takim, który wszędzie się odnajdzie i wszędzie sobie poradzi.

Powiedzmy sobie jeszcze jedną rzecz wprost. To wbrew pozorom nie jest lekki kawałek chleba. Szczególnie jeśli mówimy o osobach mocno pracujących z organizacją czy odpowiadających za transformację firmy w kierunku zwinności. To praca ciężka, wymagająca, nierzadko wyczerpująca i stresująca. Wyświechtane “rozwiązywanie problemów” to nie jest bułka z masłem. A problemów tych na drodze Scrum Mastera czeka masa, o różnym kalibrze i wadze, o całkowicie różnej proweniencji –  typowo ludzkich i międzyludzkich, procesowych…

Skąd to wspomnienie o “pozorach”? Otóż często mówiąc powyższe, natrafiam na dziwne niezrozumienie, niedowierzanie. Zauważam, że wiele osób z IT myśli – jakże szybko już wytworzonymi – stereotypami, że Scrum Master to praca lekka, łatwa i przyjemna. Ile to wszak roboty zarezerwować salkę? Takie postrzeganie tej roli to narastające i coraz mocniej niepokojące nas zjawisko, któremu od samego początku działania Młynarzy staramy się przeciwdziałać.

Czas najwyższy przejść do szczegółów i odpowiedzieć zatem na nieco zawężone pytanie – jak zostać dobrym Scrum Masterem.

Czy Scrum Master powinien być osobą techniczna?

To chyba jedno z podstawowych, najczęściej pojawiających się pytań wśród osób myślących o podjęciu pracy w tej roli. Swoją drogę i ciekawe przemyślenia w tym temacie przedstawił młynarz Michno w artykule Nietechniczny Scrum Master, do którego lektury zachęcam.

Moja odpowiedź jest taka sama i brzmi – niekoniecznie. Nie trzeba mieć stricte technicznego wykształcenia, a już na pewno nie trzeba umieć programować. Z pewnością – to pomaga – ale nie jest warunkiem sine qua non.

Zarazem jednak – i trzeba to bardzo mocno podkreślić – bezwzględnie trzeba bardzo dobrze rozumieć na czym polega proces przy którym będzie się pracować, a zatem proces wytwarzania oprogramowania, bo na nim się tutaj skupiamy.

Dlaczego?

To bardzo proste, żeby móc ulepszać ten proces pod każdym względem i w każdym jego aspekcie. Sytuacja, w której możemy w pełni zostawić to członkom zespołu deweloperskiego, którzy przecież jako specjaliści sami wiedzą, co będzie dla nich najlepsze i sami zadbają o permanentny rozwój środowiska, w którym pracują, nie jest niestety tą, z którą najczęściej się spotkamy.

I teraz ważne – w tym całym ulepszaniu nie chodzi o to, że trzeba zaglądać do wytwarzanego kodu, czytać commity, oceniać jakość kodu i wydajność pracy.

Chodzi raczej o to, żeby rozumieć to co się dzieje wokoło, mieć uszy i oczy otwarte i działać proaktywnie, obserwować również sposób pracy, komunikowania się, kwestie techniczne, być dociekliwym, dopytywać, proponować.

Nie da się tego zrobić bez odpowiedniej wiedzy. Trzeba znać cykl wytwarzania oprogramowania, rozumieć i rozróżniać rodzaje testów, wiedzieć czym jest system kontroli wersji, znać słownik i żargon, którymi deweloperzy się posługują, rozumieć na czym polega ich praca, z jakimi problemami i wyzwaniami się wiąże, niezależnie od zajmowanego stanowiska (tester, programista, DevOps). I tak dalej, i tak dalej.

I znów – nie trzeba być specjalistą od Continuous Deployment, Domain Driven Design, Test-driven Development, gita czy monitoringu aplikacji  – ale trzeba umieć zauważyć, że coś nie gra, albo wesprzeć programistę w dobrej organizacji pracy.

Z miejsca nasuwa się jednakże jedno zasadnicze pytanie. Jak taką wiedzę o wytwarzaniu oprogramowania zdobyć, jeśli nie pracujemy w branży, jeśli do tej pory byliśmy od tego wszystkiego daleko?

Nie będę tu sączył truizmów o wszechdostępności wszystkiego w meandrach Internetu. Nie będę dawał dobrych rad typu: zacznij od zatrudnienia się jako tester, bo tu jesteś tego bardzo blisko, a to z tego wszystkiego najprostsze – bo to stereotypy i mity. Każdy musi znaleźć swój sposób. Doszkalać się, znaleźć mentora, rozmawiać z osobami z “branży”. Najważniejsze jednak, żeby za długo nie siedzieć w świecie teorii i opowiadań, a jak najszybciej móc poczuć to w praktyce, nawet z pozycji obserwatora.

Wiele nietechnicznych osób martwi się kwestią autorytetu. Nie oszukujmy się – Scrum Master takowy musi w zespole mieć, inaczej ciężko będzie, aby był słuchany, jego zdanie było brane pod uwagę, a działania były skuteczne. Bez tego nie ma mowy o sukcesie w pełnieniu tej roli. Czy można być zatem autorytetem dla deweloperów, nie potrafiąc programować? Bez wątpienia tak! Owszem, jest trudniej, ale naprawdę w kwestii tej istotniejsze są zupełnie inne cechy, a napisano o tym całe tomy. Trzeba po prostu wnieść wartość do tego zespołu – swoją postawą, swoją pracą, swoją aktywnością, wsparciem. Dla nadal wątpiących można przywołać masę przykładów ze sportu, gdzie trenerzy z sukcesami niekoniecznie mieli doświadczenie jako zawodnicy, uprawiający daną dyscyplinę. Przykładów jest multum, żeby daleko nie sięgać, weźmy piłkę nożną: Carlos Alberto Parreira, Jose Mourinho czy Arrigo Sacchi mają wszak niemałe osiągnęcia. Także – tym się nie przejmujcie

Bycie osobą techniczną pomaga, ale nie jest z pewnością dla Scrum Mastera cechą najistotniejszą. Ba, jest cała masa ważniejszych.

Jakie cechy charakteru powinien mieć dobry Scrum Master?

Odpowiadając na to pytanie, znów proponuję sięgnięcie do naszego archiwum, tym razem po tekst Jedenaście atrybutów Scrum Mastera, bazujący na refleksjach popularnego piłkarskiego trenera, Bogusława Kaczmarka.

Idąc tym tropem trochę głębiej, gdybym to ja miał wskazać cechy charakteru, które widzę u najlepszych Scrum Masterów, jakie bym wymienił?

Zacznijmy od najważniejszego. Trzeba lubić ludzi, chcieć i umieć z nimi pracować. Tak po prostu. Tak po ludzku. Praca Scrum Mastera jest bowiem przede wszystkim pracą z ludźmi.  A to nie jest łatwe. Szczególnie, jeśli wymaga ona kwestionowania status quo, wprowadzania zmian, ulepszeń… I tu znów wkraczamy w temat, o którym pisze się dużo i od zawsze, zatem ledwie się po nim prześlizgniemy.

Przede wszystkim pracujemy z deweloperami – to nasza podstawowa misja. A na liście zadań w tym obszarze mamy między innymi: tworzenie zespołów, przekonanie ludzi do pracy zwinnej, pokazanie jej profitów, budowanie motywacji, zaangażowania, stworzenie środowiska, w którym będzie pracowało się wydajnie i z uśmiechem na ustach. To wszystko ogromne wyzwania. A nie wspomnieliśmy o podstawach, jak chociażby wprowadzenie w życie samych zasad Scruma czy agile’a, implementacja scrumowych spotkań, wytłumaczenie tego i zapewnienie, by miało sens, zauważalny przez wszystkich uczestników procesu.

To głównie dla zespołu deweloperskiego Scrum Master jest służebnym przywódcą. Czyli – jak to się niektórzy śmieją – nieumocowanym liderem, nie mogącym w zasadzie niczego nakazać i wyegzekwować. W praktyce oznacza to łączenie ognia z wodą, jeżeli ktoś bowiem ma cechy charakteru, predestynujące go do ról liderskich, przywódczych, to rzadko lubi pozostawać w cieniu, na dalszym planie. A tutaj musi. Nie pchać się na afisz, działać “po cichu”, w sposób wymagający łączenia wielu przeciwstawnych czynników.

Najważniejsze w tym wszystkim jest bycie przykładem, pewnym wzorem do naśladowania, może punktem odniesienia, choć nie sądzę, żeby Scrum Master trafił do kanonu wzorców osobowych czasów nowożytnych. Starając się działać przez przykład lub jako przykład, nie można zapominać jednocześnie o swoich potknięciach, błędach, należy pokazywać, że każdy je popełnia i istotne jest, żeby się na nich uczyć i nie popełniać tych samych w przyszłości. Charyzma, przywództwo, umiejętność inspirowania innych – te cechy bardzo w tym wszystkim pomogą. .

Praca z deweloperami to chleb powszedni scrummasterki, ale – o ile w większości przypadków – pozostanie pierwszym, najczęstszym zadaniem, to na nim ta współpraca z ludźmi się nie kończy, a dopiero zaczyna.

W konsekwencji pracy z zespołami deweloperskim, logicznym jest, że bardzo mocno i intensywnie musimy działać w ramach działu IT. Mądrze współpracować z przełożonymi ludzi, których mamy w zespołach, aby wspólnymi siłami dbać o ich rozwój i motywację. Chcąc tworzyć efektywne środowisko pracy, trzeba blisko współdziałać z osobami zarządzającymi działami IT. Przedstawiać im rekomendacje, wspólnie analizować, co można ulepszyć, zmienić. Czasami trzeba tu będzie ostro się spierać.

Dalej, trzeba zbudować jak najlepsze relacje z Product Ownerami swoich zespołów (ale nie tylko). To kolejne poważne i trudne zadanie. Bez dobrej współpracy na linii Scrum Master <-> Product Owner, nie ma jednak mowy o sukcesie Zespołu Scrumowego. Na czym tu należy się skupić? Dobrze ustalić wzajemne oczekiwania, codziennie kooperować, dbając o rozwój zespołu i obszaru… I znów, i w tej relacji Scrum wyznacza tu Scrum Masterowi role wiodącą  – o czym często zapominają nawet starzy scrumowi wyjadacze, w Przewodniku po Scrumie mamy zapisane, iż służebne przywództwo Scrum Mastera dotyczy Zespołu Scrumowego, a nie tylko deweloperskiego! To Scrum Master powinien wychodzić z inicjatywą, znaleźć miejsca, w których powinien być wsparciem, pomocą. Nie powinien jednocześnie dominować, stawiać siebie w roli ważniejszego, mądrzejszego, próbować podporządkowywać sobie Product Ownera. Z drugiej strony – nie może też być bierny, wycofany, co jest częste, jeśli rolę Właściciela Produktu pełni osoba doświadczona, z dużo większym stażem czy w firmie, czy całościowo, zawodowym. A o tym czy i na ile powinien orientować się w kwestii rozwijanego produktu czy szeroko pojętego biznesu, za chwilę.

Po Product Ownerze do gry wchodzą pracownicy wszystkich działów będący zaangażowani w sam proces wytwarzania oprogramowania (UX, Graficy, treści) czy dział HR w firmie – naturalny sojusznik zmian związanych z kulturą organizacyjną. W końcu – w wielu firmach Scrum Masterzy pracują bezpośrednio z Zarządem czy właścicielami. A tu poprzeczka idzie wysoko w górę, wymagania i wyzwania robią się coraz poważniejsze.

Jak to podsumować? Może tak – jeżeli Scrum Master jest w firmie nierozpoznawalny, jeżeli widząc go ludzie zastanawiają się kto to jest i co tutaj robi – jest to jednoznaczny sygnał, że nie spełnia należycie swojej roli. Dlaczego? Nie, nie chodzi tu o splendor, rozpoznawalność. Skromność i pozostawanie w cieniu są w tej roli bardzo ważne. Sęk w tym, że działając nawet tylko na poziomie Zespołu Scrumowego, konieczne będzie rozwiązywanie problemów, usprawnianie procesów w różnych, czasami kompletnie zaskakujących miejscach organizacji. Dodatkowo, jeśli mówimy o procesie transformacji agile, ważne jest aby każdy w firmie wiedział o co tu chodzi i kto za to odpowiada.

Zarazem świat daleki jest od ideału, a dobrymi chęciami wybrukowane jest piekło. Nie wszędzie będziemy witani z otwartymi ramionami.

Kontestując zastaną rzeczywistość, chcąc coś zmieniać, natrafiać będziemy często na niechęć, opór, sprzeciw, a nierzadko pojawią się konflikty. Rola Scrum Mastera, szczególnie w kontekście pracy z organizacją, wymaga często wsadzania nogi w drzwi, a następnie wchodzenia oknem po tym, jak ktoś przez wspomniane drzwi nas wyrzucił. Nawet najszlachetniejsze intencje niesienia pomocy mogą być odebrane przez innych jako wchodzenie z buciorami nie tylko w drzwi do ich pokojów, ale i ich kompetencje, wręcz ich podważanie.

Działania tego typu wymagają dużego taktu, wysokich umiejętności interpersonalnych i zdolności komunikacyjnych, w końcu – dyplomacji. Przydają się otwarta i chłodna głowa, duża cierpliwość, wytrwałość, ale upór. Nie ośli upór, ale upór w rozumieniu wierności sobie, zasadom i “walkę” o realizację tego, w co wierzymy, w to – co ufamy – że sprawi, że będzie lepiej.

Co jest potrzebne żeby to wszystko wcielić w życie? Po pierwsze – cechy i działania zgodne z wartościami Scruma.

Potrzebna jest odwaga – do podejmowania decyzji, ale i otwartej, szczerej komunikacji, a także rozwiązywania niełatwych sytuacji. Umiejętność powiedzenia “nie”, asertywność.

Niezbędne jest zaangażowanie. Scrum Master musi mieć w sobie wewnętrzny ogień, szwung, wysoką umiejętność samomotywacji. To właśnie on jest spiritus movens zmian w organizacji, stąd obligatoryjną cechą jest absolutna samodzielność w działaniach, proaktywność, wychodzenie z inicjatywą. Pomaga dobry zmysł obserwacji i wbudowany sonar, wykrywający wszelkie przeszkody, marnotrawstwa, nieefektywne miejsca w firmie. Scrum Master nie może być bierny, wyczekiwać na zadania, podstawione na tacy cele.

Scrum Master musi być otwarty. Na słuchanie, na różne opinie, pomysły, inicjatywy. Konieczne jest poszanowanie, empatia, zrozumienie innych. Zgoda na to, że świat nie kręci się wokół nas i naszych pomysłów, poszanowanie innych ludzi, innych opinii, szacunek do  zastanej rzeczywistości (a zatem nie: kiedyś to było do d***, teraz będzie Scrum to zobaczycie jak się pracuje). I w końcu skupienie na założonych celach, na pracy do wykonania.

Do tego wszystkiego przydadzą się na pewno szerokie horyzonty. Wiedza z różnych dziedzin i umiejętność jej wykorzystania w praktyce.

Dużo tego, prawda?

Zapowiadałem, że nie ma lekko. Chcąc być dobrym jako Scrum Master, trzeba nad sobą nieustannie pracować, nieustannie się rozwijać, wzmacniać i budować w sobie te cechy.

Jaka wiedza jest konieczna?

Wcześniej podkreśliłem, że konieczne jest bardzo dobre rozumienie procesu wytwarzania oprogramowania. Jaka jeszcze wiedza jest nieodzowna?

Przede wszystkim trzeba bardzo dobrze rozumieć Scruma, do czego zobowiązuje już sam tytuł. Mieć Master w nazwie stanowiska to nie byle co, nawet jeśli jest to zawężone do jednego frameworka.

Do mistrzostwa w znajomości Scruma jak ulał panuje ścieżka “shu-ha-ri”. Nie ma tu drogi na skróty, kluczowe jest zdobyte doświadczenie. Jednak od samego początku tej drogi musimy być ukierunkowani na jak największy rozwój, na zdobycie bardzo dobrego podłoża teoretycznego, który będziemy mogli konfrontować i kontestować w zastanej rzeczywistości.

Spotkałem Scum Masterów nie znających agile manifesto. Wprowadzono ich do roli na zasadzie wskazania “Przewodnika po Scrumie” i kilku ogólnych wytycznych firmowego specjalisty. Spotkałem też i wielu scrumowych neofitów, wciskających wszystkim wokoło wizję nowego, wspaniałego świata tworzonego na bazie przykazań panów Schwabera i Sutherlanda. Jakież było ich zdziwienie, że większość tego, co ci panowie napisali, już było, a ich przemyślenia i pomysły bazują na ideach sięgających momentami i dwudziestolecia międzywojennego.

Warto nie tylko dobrze znać Przewodnik po Scrumie i całą stronę agilemanifesto.org. To są absolutne podstawy, i owszem – dobra znajomość i rozumienie tych tekstów w początkowych krokach w zupełności wystarczy. Natomiast, żeby być dobrym, trzeba znać konteksty, rozumieć wszelkie mechanizmy tam opisane – dlaczego, skąd to się wzięło, po co, skąd tak, a nie inaczej. Drążyć. Takie poszukiwania mogą nam otworzyć wiele ciekawych dróg.

Nie wolno też być niewolnikiem wspomnianych treści i kurczowo trzymać się reguł w nich zapisanych. W szczególności manifest agile – to drogowskaz, punkt odniesienia, a nie kodeks. Trzeba zatem mieć w sobie wolę eksperymentowania, gotowość do wypływania na nieznane wody. W pracy tej nie ma miejsca na sztampę, rutynę, bierność, działalność wedle szczegółowo rozpisanych zasad. Scrum to przede wszystkim ramy postępowania – framework. Mamy zarysowane pewne ogólne zasady, ale musimy je wdrożyć w życie wedle własnej wizji. I oczywiście – będziecie popełniać błędy, mylić się. Każdy, kto w tej robocie zaczyna, ma na sumieniu jakieś grzeszki, o których z pewnością chciałby zapomnieć. Szerzej o tym możecie przeczytać w moim wcześniejszym artykule: Nie bój się, eksperymentuj.

Zaryzykowałbym tu porównanie do gry w szachy, gdzie sprint byłby odpowiednikiem jednej partii. Mamy do dyspozycji ograniczony czas, będąc otrzaskani teoretycznie wiemy czego się spodziewać na samym początku (w pierwszych kilkunastu ruchach), ale potem musimy radzić sobie sami, próbując osiągnąć sukces bazując na wyczuciu, doświadczeniu. Nieustannie myśleć, przewidywać dalej niż krok do przodu. I wychodzić ze swoistego chaosu “gry środkowej” do stabilnych, przewidywalnych końcówek, gdzie mając przewagę, wystarczy nie popełnić błędu.

Na początku trzeba dużo czytać (blogi – jak najbardziej, ale i książki, bo takowych w tym temacie nie brakuje) i korzystać z szerokiego spektrum dostępnych niemalże w całym kraju (a przynajmniej w największych miastach) spotkań lokalnych zwinnych społeczności, uczestniczyć w lokalnych wydarzeniach, konferencjach. Możliwości jest naprawdę mnóstwo i wszystko tu zależy od naszych chęci.

Bardzo ułatwia też – praktycznie na każdym poziomie jaki osiągniemy – posiadanie mentora. Kogoś, z kim możemy podzielić się swoimi spostrzeżeniami, wątpliwościami, pomysłami, przemyśleniami, kto pomoże na początku drogi i wprowadzi w arkana pracy w tej roli.

Czy Scrum Master powinien znać się na biznesie?

Sporo czasu poświęciłem na omówienie kwestii znajomości przez Scrum Mastera technikaliów. A co z aspektem biznesowym, co ze wsparciem Product Ownera?

Moim zdaniem, wkraczamy tu już na ścieżkę oznaczoną przypisem: dla zaawansowanych. Owszem, nietrudno wprowadzić raczkującego Product Ownera w zasady i mechanikę Scruma, być jego przewodnikiem w zrozumieniu wytwarzania oprogramowania wedle tych zasad.

Ale wsparcie w codziennej pracy, rozwijaniu obszaru, zarządzaniu backlogiem, to już wyższa szkoła jazdy, wymagająca odpowiedniej wiedzy i doświadczenia.

Na początek trzeba być świadomym, że i w tym obszarze czekają nas ważne zadania. I, że im więcej w tym obszarze wiemy, im bardziej możemy pomóc, tym lepiej.

Co z certyfikatami?

Czy warto się certyfikować, to kolejne z pytań, na które musimy sobie odpowiedzieć. Choć, patrząc na wiele spośród ogłoszeń o prace, wydaje się, że jednoznacznie twierdząco, to jednak odpowiedź na to pytanie jest trudna.

Na chwilę obecną mamy dwie główne organizacje i dwa główne nurty. Pierwszy, w Polsce chyba popularniejszy i szerzej znany, spod szyldu scrum.org, oferuje gros certyfikatów, przyznawanych po uzyskaniu określonego wyniku w teście zdawanym on-line. Jedyne co jest potrzebne, aby do nich przystąpić, to uiszczenie opłaty. Certyfikaty z serii Professional Scrum Master mają trzy poziomy – na początkowych wymagane jest przede wszystkim: wykucie “na blachę” całego Przewodnika po Scrumie, dobra znajomość angielskiego i świadomość, rozeznanie w różnego rodzaju brzydkich sztuczkach w testach, typu podwójne negacje.

Z kolei organizacja Scrum Alliance przyznaje certyfikaty na innych zasadach. Na poziomie pierwszym, wystarczy wziąć udział w kursie przeprowadzonym przez szkoleniowca akredytowanego przez tę organizację. Do kolejnego etapu wymagane jest z kolei co najmniej roczne doświadczenie i kolejny kurs. Co więcej, certyfikaty tej organizacji ważne są tylko przez dwa lata – wymagane jest wnoszenie opłaty członkowskiej i wykazanie zdobycia nowej wiedzy, przykładowo poprzez udział w określonych konferencjach czy szkoleniach.

Oba typy certyfikatów na podstawowych poziomach nie zapewniają i nie gwarantują praktycznie niczego, ani tym, którzy je posiadają, ani osobom, które takie osoby chcą zatrudniać. Żeby zdać egzamin organizacji scrum.org, wystarczy odpowiednie przygotowanie teoretyczne, nie trzeba mieć żadnej wiedzy praktycznej – to kwestia wyuczenia się zasad, niekoniecznie trzeba je rozumieć. Pomijam tu już kwestie możliwości “oszukania systemu” przy egzaminie mającym taką, a nie inną formę. Każdy wie też, że samo uczestnictwo w jakimś kursie nie gwarantuje niczego – to a propos Scrum Alliance.

Wydaje mi się, że znaczenie tych certyfikacji  spada, choć wspomniane organizacje mocno z tym walczą, z czym ciężko się dziwić – głównie z tego żyją, na tym zarabiają. Osobiście jestem zaskoczony jak często i jak ostro twórcy manifestu agile krytykują je przy okazji różnorakich wystąpień, właśnie z powodu komercjalizacji, monetyzacji agile’a…

No dobra, to certyfikować się w końcu, czy nie?

Pierwsza sprawa, taki certyfikat w niczym nie zaszkodzi.

Druga – jeśli dane szkolenie przeprowadza osoba lub firma rekomendowana przez któreś z tych stowarzyszeń – mamy gwarancję jego określonego poziomu.

Trzecie – podkreślmy ten truizm – najbardziej liczy się to, co sobą prezentujemy, co mamy do powiedzenia, jakie są nasze przemyślenia, spostrzeżenia, jakie jest nasze doświadczenie. Ładne emblematy ozdabiające nasze profile w mediach społecznościowych nie wystarczą, aby otrzymać prace jako Scrum Master i być w tym dobrym.

A zatem?

Już sama objętość tego tekstu, pokazuje, że nie ma lekko.

Scrum Master to praca wymagająca. Zarówno pod kątem wiedzy, którą trzeba posiadać i nieustannie poszerzać, jak i – a może przede wszystkim – codziennej postawy, zachowania, konieczności “świecenia przykładem”. Umiejętności komunikacyjnych, charyzmy, umiejętności dogadania się, ale i inspirowania. Trudnej sztuki pracy z ludźmi. To także bardzo dużo wyzwań, setki małych, dziesiątki wielkich spraw, bardzo zróżnicowanych. Do tego, nawet jeśli walczymy w pierwszych szeregach agile’owej armii, koniec końców musimy pozostać w roli drugoplanowej, splendor i chwałę zostawiając ważniejszym od nas. Żeby firma dobrze funkcjonowała, musimy mieć zapewnione dobre decyzje biznesowe (Product Owner) i ludzi, którzy przekują je na działające oprogramowanie wysokiej jakości (zespół deweloperski). To o nich, a nie własne ego, trzeba zadbać w pierwszej kolejności.

Nie można zapominać o odpowiedzialności jaka na nas spada. Odpowiedzialności – nie przede wszystkim za proces, ale za ludzi, z którymi pracujemy. Nie możemy wchodzić w tę rolę nieprzygotowani, działać w sposób nieuporządkowany, niepewny, bo możemy tylko i wyłącznie zaszkodzić. Firmie, ludziom i całemu… agile’owi, o czym więcej pisałem we wspomnianym Za waterfalla było lepiej.

Zarazem praca w tej roli jest po prostu fascynująca, niezwykle ciekawa, zróżnicowana, wymagająca szerokiej wiedzy z wielu dziedzin, bardzo rozwijająca. Mimo, że na papierze daje niewiele prerogatyw, w rzeczywistości oferuje, jak mało która, realne, spore wpływy, możliwości zmiany otaczającej rzeczywistości na lepsze.

#ScrumMaster