Zostałem niedawno poproszony o przedstawienie pomysłów na rozwój dla pewnej grupy z Scrum Masterów. W ramach przygotowań do tego wystąpienia miałem tyle ciekawych przemyśleń, że aż żal się z nimi nie podzielić w tym miejscu z czytelnikami #białko.
Jak się rozwijać jako Scrum Master?
Pytanie postawione przede mną dotyczyła tego, jak Scrum Masterzy mogą się dalej rozwijać i w którym kierunku powinni zmierzać? To jest ogromna różnica w porównaniu do pytania „W którą stronę zmierza rynek oraz nasz scrumowy i agile’owy światek?”. W tym drugim temacie mam pewne przemyślenia, którymi ostatnio dzielę się na liście mailingowej, ale jednak nie będą one tematem dzisiejszego tekstu. Co nie znaczy, że moje przewidywania nie mają wpływu na niniejsze rekomendacje.
Należy zwrócić też uwagę na uwarunkowania lokalne. To co jest dobrym pomysłem dla osób pracujących w dużej korporacji może być średnim pomysłem dla Scrum Mastera pracującego w małym software house. Z kolei samotny Scrum Master albo Agile Coach obsługujący mała firemkę ma inną perspektywę niż jeden z dwudziestu SM-ów i pięciu AC zatrudnionych w większym przedsiębiorstwie.
Niniejsze rady koniecznie dopasuj do swojej sytuacji.
Przygotowując się do wspomnianego wystąpienia, zbierając dane i analizując moje doświadczenia, siłą rzeczy musiałem przemyśleć przyszłość nie tylko Scrum Masterów, ale i potencjalne sposoby na wybicie się i osiągnięcie osobistych korzyści. Udało mi się zgromadzić całkiem pokaźną liczbę wniosków i sugestii. Możecie je wziąć tak, jak zostały one zapisane, możecie też się z nimi nie zgadzać i je zignorować. Wydaje mi się jednak, że większość z tych obserwacji może bardziej pomóc niż zaszkodzić.
Główny kierunek rozwoju… Scruma
Podstawowe pytanie, jeżeli chodzi o dalszy rozwój każdego Scrum Mastera to pytanie o przyszłość Scruma.
Scrum Master jako rola ma tego nieszczęsnego Scruma w nazwie. Nie da się ukryć, że SM bez Scruma nie istnieje. Jest wiele metodyk, podejść i frameworków wykorzystujących podobną rolę. Czasami nawet nazywa się ona tak samo! W dalszym jednak ciągu ponad połowa firm (rzekomo) używa Scruma. Publikowane liczby są bardzo tendencyjne i nie sumują się do żadnych sensownych wartości. Można znaleźć takie wartości jak 56% zespołów zwinnych jest scrumowa (a we wszystkich jego odmianach – ponad 80%). Z drugiej strony SAFe twierdzi, że 36% firm skalujących zwinność używa ich propozycji. Tak czy inaczej, Scrum jest wszędzie, a SAFe się rozpycha.
Nie wszystkie zespoły scrumowe posiadają jednak rolę SM-a. Jeżeli więc swoją przyszłość wiążemy z byciem Scrum Masterem (albo kimś podobnym), to najważniejszym pytaniem jest: Czy Scrum nadal będzie istniał za kilka bądź kilkanaście lat?
Jeżeli obstawiamy, że tak – będzie istniał, to musimy pamiętać, że na rynku jest pełno Junior Scrum Masterów, którzy ostatnich kilku latach pozdawali podstawowe certyfikaty i zaczęli pracować w środowiskach, które raczej mniej niż bardziej przypominają prawdziwy Scrum. W tym przypadku naszym celem rozwojowym powinno być odróżnienie się od wszystkich tych ludzi i pokazanie, że potrafimy dać z siebie o wiele więcej niż typowy Junior Scrum Master.
Z drugiej strony, jeżeli obstawiamy że boom na zespoły scrumowe i Scrum Masterów nie potrwa długo, to musimy zadać sobie inne pytanie: Kogo zespoły i organizacje będą potrzebowały zamiast SM-ów? Jeżeli patrzymy na typowe ScrumButowe zespoły, to w nich SM najczęściej de facto pełni rolę Team Leadera, Project Managera albo Delivery Managera. A czasami po prostu Kierownika Zespołu. To by znaczyło, że taka jest potrzeba rynku.
Najważniejsze pytanie brzmi: czy chcemy być lepszym Scrum Masterem, czy bardziej próbujemy rozwinąć inne kompetencje, które pozwolą nam miękko wylądować na rynku pracy? Na szczęście niezależnie od odpowiedzi na to pytanie, kompetencje i sposób dalszego rozwoju będzie bardzo podobny.
Przydatność SM-a
Niezależnie od tego w jakiej roli widzimy się w przyszłości, musi być to ktoś przydatny dla zespołu i dla organizacji. To znaczy musimy być w stanie jasno pokazać (udowodnić) swoją wartość. Wszyscy muszą czuć, że z nami jest lepiej niż bez nas.
Najbardziej oczywistym sposobem na pokazanie swojej wartości, jest branie udziału w pracach Scrum Teamu. Jeżeli posiadamy jakiekolwiek inne pozascrummasterskie kompetencje, czyli na przykład analityczne, testerskie, programistyczne, architektoniczne, zarządcze, administracyjne, itd. to łatwiej będzie nam pokazać swoją wartość.
W wariancie minimum uważam, że powinniśmy być w stanie pomóc zespołowi w sytuacji wyjątkowej. Wtedy, kiedy pada hasło „wszystkie ręce a pokład”. Jeżeli nie umiemy poprawić prostego błędu, nie umiemy odetkać zablokowanego pipeline’a, nie możemy wesprzeć analizy, nie znamy się na wytwarzanym produkcie i tak naprawdę nie potrafimy pomóc zespołowi w wytworzeniu produktu, to być może warto zacząć od tego. W tekście, w którym porównywałem Scrum Mastera do inżyniera produkcji, sugerowałem, że powinien on/ona znać się na produkcji oprogramowania przez zespół.
Ta znajomość może być powierzchowna pozwalająca na co najwyżej gaszenie pożarów bądź pomoc w sytuacji krytycznej, bądź głęboka de facto sprowadzająca się do tego, że dana osoba jest w 50% na przykład UX Designerem, testerem czy analitykiem, a w drugich 50% Scrum Masterem.
Czy Scrum Master powinien być techniczny?
Kiedyś mówiłem, że wiedza techniczna nie jest dla SM-a niezbędna, ale nie przeszkadza. Teraz jestem bliższy stwierdzeniu, że z kolejnymi latami będzie ona o wiele bardziej istotna. Związane jest to z doświadczeniem osób, które w ostatnim czasie trafiają do tej roli. Kiedyś SM to była osoba „z zespołu”, która po prostu nie mogła wytrzymać patrząc na źle zorganizowane procesy i sposób pracy. Teraz najczęściej są to osoby, które zostały skuszone „zarobkami jak w IT bez wiedzy technicznej”.
Wiele lat temu faktycznie mówiłem, że „najlepsze studia dla SM-a to psychologia”, bo typowy Scrum Master był osobą techniczną. Przez to rozumiem, że zanim pojawiła się na głowie czapka „SM”, ta osoba spędziła miesiące albo i lata rozwijając jakiś produkt czy produkując jakieś oprogramowanie. SM to nie był zawód, to były osoby, które brały na siebie walkę z nieefektywnymi procesami i taką organizację środowiska pracy, żeby „można było się skupić na robocie”. To powodowało, że były to osoby kompetentne zarówno w aspektach technicznych, jak i procesowych. Bardzo często brakowało im jednak umiejętności miękkich, coachingowych, zdolności do facylitacji, i tak dalej.
Teraz sytuacja wygląda odwrotnie. Dziś wielu Scrum Masterów pochodzi z zawodów, które zwykle charakteryzują się bardzo wysokimi umiejętnościami, jeżeli chodzi o pracę w zespole, facylitację i ogólnie umiejętności miękkie. Tym samym osobom brakuje kompetencji technicznych, znajomości procesu wytwórczego, zrozumienia cyklu wytwarzania oprogramowania, itp. Jeżeli w takiej sytuacji miałbym się w czymś certyfikować, to bardziej patrzyłbym na kierunki SDLC, DevOps, DevSecOps, zarządzanie zespołami, management, a także bardziej konkretne zawody jak analityk, programista czy tester.
Oczywiście, nie można uogólniać na wszystkich Scrum Masterów, ale opisany trend jest jak najbardziej widoczny. W związku z tym jeżeli czujesz się „mocny technicznie”, to sugeruję, żeby w pierwszej kolejności rozwijać się „miękko” i odwrotnie. I tak, „Warsztat Scrum Mastera” i znajomość Scruma uznaję za „umiejętności miękkie”.
Co wartościowego wnosi Scrum Master?
Jeżeli zmierzamy w kierunku bycia wartościowym Scrum Masterem, ale niekoniecznie widzimy się jako dewelopera, który w ramach Sprintu realizuje też wymagania czy zadania, to musimy wrócić do korzeni.
Jedną gałęzią Scrum Mastera już wspomniana inżynieria produkcji oprogramowania i zarządzanie. I to zarówno od strony technicznej, jak i procesowej. W małej organizacji mieszać w procesie wytwórczy możemy bez oglądania się na innych. Jeżeli jednak jesteśmy w dużym korpo albo w firmie, która posiada wiele konkretnych procesów, to nikt nam nie pozwoli zmienić tego „co działa od zawsze”. Wiązać się to będzie z udowodnieniem, że posiadamy odpowiednią wiedzę. W tym kierunku patrzyłbym, jeżeli chodzi o poszerzanie kompetencji i zdobywanie wiedzy i doświadczenia.
Nie zapominajmy jednak o drugiej gałęzi naszego scrummasterstwa, czyli ułatwiania pracy zespołu. To co zostało strywializowane do „usuwania impedimentów” i „wspierania pracy zespołu”, kiedyś było „robieniem wszystkiego co tylko się da, żeby zespół mógł w spokoju skupić się na pracy”. To oznaczało przejęcie na siebie wszystkich tych obowiązków, które nie służyły wytwarzaniu produktu, a które były wymagane od naszego zespołu. Dobry Scrum Master od zawsze był leniwy i potrafił większość z tych rzeczy usunąć, żeby po prostu nie musieć ich robić.
Przydatny Scrum Master zlikwiduje te wszystkie spotkania, na które narzekają osoby w zespole. Sprawi, że elementy metodyki nie będą przeszkadzały i odciągały od faktycznego realizowania zadań, a pomogą z marnotrawstwem i wszystkimi rzeczami, które zespołowi najbardziej przeszkadzają. Mowa tu oczywiście można tu o wszystkich rzeczach – od trywialnych dostępów, przez załatwienie pracy zdalnej czy zmianę procesu rozliczania godzin, aż po modyfikację procesu zarządzania wymaganiami czy ściągnięcie analityków na 100% do zespołów.
Tu warto podkreślić, że większość rzeczy które dla wielu Junior Scrum Masterów są fascynujące, jak ciekawe narzędzia i techniki na retro, gry i zabawy wspierające integrację zespołu czy warsztaty na których zużywamy tysiące karteczek, są dla zespołu zawracaniem głowy i właśnie przykładem na marnotrawstwo z jakim Scrum Master powinien walczyć, a nie proponować. Nie odmawiam wartości tym rzeczom, natomiast zanim zaczniemy wdrażać takie elementy, upewnijmy się że absolutne fundamenty są na miejscu. Sprawdźmy, czy Scrum Team jest w stanie efektywnie pracować i wykonywać to, czego się od nich oczekuje, czyli dostarczać wartościowy produkt.
Podobnie rzecz się ma ze Scrum-Masterem-jako-trenerem. Z jednej strony firma może zaoszczędzić tysiące złotych wykorzystując Scrum Masterów do przeprowadzania wewnętrznych szkoleń i warsztatów. Tak przecież powstało #białko – po dziesiątkach szkoleń wewnętrznych podjęliśmy decyzję o wyjściu z autorskimi programami na rynek. Z drugiej jednak strony, Scrum Master musi być ekspertem i w dodatku dobrym trenerem, żeby szkolić zespoły. Potencjalnie to też może być jakiś kierunek rozwoju oraz sposób na pokazanie swojej wartości.
Wartość Produktu
Warto wspomnieć o kolejnej gałęzi, na której Scrum Master może wiele ugrać i w której powinien się rozwijać. Mowa tu o wiedzy domenowej i produktowej. Jeżeli od dziesięciu lat pracujemy w ubezpieczeniach i/lub bankowości to powinno to być naszym wielkim atutem. Taki SM jest w stanie nie tylko facylitować, ale wręcz prowadzić refinement, zadając wartościowe pytania. Taki SM bierze aktywny udział w analizie i wymyślaniu rozwiązań, bo się na tym zna.
Jak inaczej SM ma wspierać Product Ownera w zarządzaniu Backlogiem Produktu, jeżeli nie będąc ekspertem od domeny lub rzeczonego produktu? A jeśli tak, to automatycznie SM powinien potrafić brać udział w pracach analitycznych czy testerskich. Czyli realizować dokładnie to, co padło kilka akapitów wcześniej – być wartościowym członkiem zespołu.
No dobrze, słowo „ekspert” zostało użyte na wyrost. Ale nie da się nie docenić wiedzy domenowej i produktowej. Jeżeli już wylądowaliśmy w jakiejś branży, to korzystajmy z tego! Podobnie jeśli chodzi o sposób działania organizacji. Będąc w 10 różnych software house’ach łatwiej nam będzie trafić do 11-ego, bo staniemy się doradcą-konsultantem, który dokładnie w tym środowisku działał.
Nie zmarnujcie szansy na nabranie wartościowego doświadczenia w miejscu, w którym aktualnie jesteście.
Ekspert od pracy zdalnej
Kolejnym aspektem na liście są techniki i narzędzia wspierające pracę zdalną. Nawet jeśli nastąpi „powrót do biur”, to będą to biura w różnych miastach i w niepełnym wymiarze czasu. Czyli praca zdalna tak czy inaczej zostanie, na pewno od niej nie uciekniemy w zespołach IT.
Jeżeli jako Scrum Master nie znasz rozwiązań na typowe problemy, które pojawiają się w pracy zdalnej, nie potrafisz zorganizować pracy zespołu, nie umiesz wesprzeć narzędziami najtrudniejszych procesów (jak chociażby znalezienie wspólnego terminu na spotkanie), ani nie umiesz wycisnąć 120% z używanych narzędzi jak Teams, Confluence, Sharepoint, Azure DevOps, Office 365 czy Jira, to jest to kierunek w którym zainteresowałbym się w pierwszej kolejności. Może on bowiem pomóc tu i teraz, w Twoim zespole, a jednocześnie jest na tyle ogólnym kawałkiem wiedzy, który przyda się w każdym miejscu i w każdej organizacji.
I mówię (piszę) to całkiem serio. Narzędzia stosowane w większości organizacji są wykorzystywane w zaledwie kilku procentach, a jednocześnie ludzie męczą się z problemami, na które rozwiązania już dawno istnieją.
Administrator… Jiry?
Z tematem narzędzi wiąże się też ciekawa kompetencja, czyli umiejętność administrowania wspomniany narzędziami. Co prawda są organizacje w których „administrowaniem Jirą” należy do osobnego działu, ale są też takie, gdzie jest to temat traktowany po macoszemu. Natomiast nie da się ukryć, że jest to wartościowa wiedza dla wielu organizacji i zespołów. I nie, wcale nie uważam, że Scrum Master powinien administrować Jirą. Ale jeśli rozmawiamy o tym, „jak pokazać swoją wartość” i „jak się rozwijać”, to jest to jeden z potencjalnych kierunków.
Gorąco zachęcam do tego żeby zdobyć sobie licencje, zainstalować wersję trialowe i pobawić się wszystkimi narzędziami, z którymi mieliśmy ostatnio do czynienia w naszej pracy zawodowej. W tym również z narzędziami AI, które nie są obecnie używane w naszej firmie, ale znamy je z rynku (bo się rozwijamy, szukamy i sami z nich korzystamy). Warto przeanalizować możliwości konfiguracji tych tooli i zacząć z nich korzystać na co dzień, a zastosowania będą nam się nasuwały same. W pewnym zakresie możemy też zainteresować się szkoleniami bądź warsztatami, nawet jeżeli wydają nam się one dziwne.
Podobnie dziwna może się wydać sugestia żeby pobawić się najnowszą Jiry w wariancie cloud. Widać silny nacisk naszego „ulubionego” dostawcy na wariant cloudowy, część organizacji się złamie i zmigruje aplikacji w licencji Data Center do chmury. Wtedy konieczna będzie nie tylko migracja, ale też skonfigurowanie czy odtworzenie procesów w nowym środowisku. Osobiście uważam, że Jira Cloud jest o wiele lepsza niż to, co jest zainstalowane w większości korporacji. Warto być ekspertem od tego narzędzia, bo może nam to tylko i wyłącznie pomóc.
Ekspert od zarządzania i skalowania
Jest jeszcze jedna gałąź, w której można odnaleźć dla siebie szansę. To zarządzanie bądź kierowanie więcej niż kilkoma zespołami, rozwiązywanie zależności, tworzenie procesów, czyli krótko mówiąc praca lidera zespołu bądź kierownika, a w niektórych przypadkach także managera. Alternatywnie możemy rozważyć zostanie ekspertem/konsultantem od jakiegoś rozwiązania skalowalnego. Nie da się ukryć, że w tym temacie liczy się obecnie tylko SAFe, więc trzeba dobrze przemyśleć czy jest to kierunek, w którym chcemy iść.
Wydaje się, że próg wejścia na stanowiska kierownicze i managerskie jest jeszcze większy niż na stanowiska techniczne. Nie wystarczy przecież być coachem i facylitatorem, żeby kierować ludźmi albo zarządzać zespołem. Wymagane jest nieco inne doświadczenie, są też wyraźnie inne oczekiwania w stosunku do takich osób. Tym bardziej, że w przypadku Team Leaderów bardzo często wymaga się zarówno wiedzy przedmiotowej, umiejętności do zarządzania zespołem, a także bycia ekspertem w danej dziedzinie.
Tematem pokrewnym, na który łatwiej będzie przeskoczyć niektórym osobom może się okazać zarządzanie projektami. Zanim posypią się kamienie, przypomnę, że patrzymy na rynek i na rzeczywiste potrzeby i sposoby działania organizacji. Tam project managerowie mają się bardzo dobrze. I tak jak kiedyś wiele osób przechodziło z roli PM-a na Scrum Mastera, tak teraz wydaje mi się, że wkrótce możemy zaobserwować trend odwrotny.
Jeżeli mamy odpowiednią wiedzę domenową bądź techniczną możemy pokusić się też o zerknięcie na inne stanowiska managerskie takie jak Delivery Manager, Release Manager, Program Manager, Product Manager, itp. Jakbyście nie zauważyli, to niepostrzeżenie zaczęliśmy wplatać porady dla osób, które w Scruma po prostu nie wierzą. Tak jak zaznaczyłem na wstępie, jeśli chcemy być głównie/tylko Scrum Masterem, to musimy potrafić więcej niż wymaga od nas PSM I. A jeśli rozważamy „plan B” w postaci „bycie kimś innym”, to wtedy nie wystarczy suplementowanie wiedzy i umiejętności, tylko faktycznie musimy stać się kompetentni w innej roli.
Certyfikaty i szkolenia
Gdy słyszę pytanie „W jakim kierunku rozwijać się jako Scrum Master?” większość osób najczęściej oczekuje, że doradzę jakieś szkolenia bądź zasugeruję certyfikaty, które powinno się zdobyć. Nic bardziej mylnego, przynajmniej w moim przypadku. Zespoły które borykają się z ciężkimi procesami w korporacjach wcale nie potrzebują kolejnych warsztatów z milionem post-itów, a potrzebują tego, żeby ktoś ich odciążył. I to Scrum Master ma być tą osobą, która w pierwszym kroku zrobi pewne rzeczy za zespół, uwalniając więcej sił i środków na potrzeby wytworzenia produktu. Dopiero w drugim kroku zadba o to, żeby te nieefektywne procesy i sposoby pracy zmienić.
Wszystkiego rodzaju techniki facylitacji, szkolenia z rozwiązywania konfliktów, warsztaty coachingowe, techniki retro i różnego rodzaju miękkie narzędzia są fajne i przydatne, tak przy dzisiejszym rynku i stanie profesji nie mogę tego z czystym sumieniem polecić. Powtórzę tutaj swoją sugestię: jeżeli jesteśmy „techniczni”, faktycznie idźmy w kierunku szkoleń scrumowych, agile’owych i miękkich. Ale jeżeli nie potrafimy być wartościowym Deweloperem nawet przez chwilę, to najpierw pokryjmy tę dziurę.
W temacie certyfikatów typowo scrumowych, odsyłam do czwartego odcinka agileCastu. W nim, na Waszych oczach zdaję PAL I, a przy okazji omawiam stan branży i sugeruję, które certyfikaty warto zdać. Konkluzja jest oczywista i wynika wprost z fundamentalnego pytania o przyszłość Scruma. Jeżeli wierzymy, że Scrum nadal będzie istniał i rola Scrum Mastera będzie istotna, to powinniśmy się zainteresować tymi certyfikatami, które odróżnią nas od innych osób. A tak naprawdę liczą się tutaj PSM III, PSPO III ze Scrum.org oraz ich odpowiedniki ze Scrum Alliance – CSP-SM, CSP-PO. Wszystkiego rodzaju PAL-EBM, PSPBM i inne są zdecydowanie przereklamowane, nie sądzę żeby ktokolwiek zwracał na nie uwagę w przypadku wyboru Scrum Mastera.
Warto jeszcze dodać, że SAFe – jakikolwiek by nie był – ma dużą część rynku i potencjalnie SAFe’owe SA lub SPC również są rzeczami, które pomogą nam „poznać wroga”, a jednocześnie użytecznie zwiększyć kompetencje. Idąc jeszcze dalej i w zupełnie innym kierunku, możemy rozważyć też uznane certyfikaty coachingowe z ICF lub ICAgile (ICP-ACC).
A co z Agile Coachingiem?
Wiele osób traktuje Agile Coacha jako kolejny etap w karierze Scrum Mastera. Kiedy już poradziliśmy sobie ze zwinnością na poziomie zespołu, a potem kilku zespołów czy całego działu, wiele osób patrzyło na całe organizacje. Szersze spektrum działania, myślenie o procesach i organizacji zespołów oraz pracy na wysokim poziomie – czy to nadal brzmi dobrze?
Tu zaobserwować można podobny, ale dużo mniej wyraźny trend, czyli odwrót od ekspertów zwinności po tym, jak wiele firm i zespołów przekonało się, że to nie jest dla nich bądź „to nie działa”. Oczywiście, w większości przypadków rozwiązania były źle dobrane do potrzeb bądź wybrane metody i narzędzia nie zostały właściwie wdrożone, ale nic to nie zmienia. Coraz częściej słowo „agile” postrzegane jest jako „coś, co się nie sprawdza w prawdziwym życiu”.
Z drugiej strony pamiętajmy jednak, że nasz gloryfikowany Agile Coach od dawna występował w przyrodzie jako… konsultant. To osoba, która doradza firmom jak uporządkować procesy, zespoły i używane do pracy metodyki. Także w chwili obecnej wielu Agile Coachów jest de facto konsultantami, którzy doradzają w sposobie organizacji zespołów, procesu wytwórczego, wdrażania metodyk, itd. Od takich osób oczekuje się wiedzy jeszcze szerszej niż od Scrum Masterów. Poniższy diagram może być sugestią zarówno dla przyszłych Agile Coachów, jak i dla obecnych Scrum Masterów:
Jeżeli widzimy tu dla siebie szansę w przyszłości, to siłą każdego konsultanta jest tego doświadczenie i umiejętność zaadaptowania znanych rozwiązań do sytuacji klienta. Tu przyda się już wspomniane doświadczenie dziedzinowe i domenowe. Czyli mowa tu zarówno o branżach (ubezpieczenia, bankowość, telekomy, aplikacje komórkowe, itd.), jak i modelach działania (wewnętrzne IT, zewnętrzny dostawca, mała firma rozwijająca produkt, software house, itd.).
I tu „niestety” częste zmiany pracy będą jak najbardziej na plus. Jeżeli przez ostatnie 15 lat pracowaliśmy w bankowości i ubezpieczeniach w wielu różnych firmach to świetnie. Natomiast jeżeli przez 15 lat siedzieliśmy w jednym software housie, to wiele osób oceni to doświadczenie jako gorsze. Nawet jeśli ten software house robił zlecenia dla tych samych banków i ubezpieczalni.
Elephant in the room
Na koniec chciałbym poruszyć jedno założenie, które przyświecało wszystkim tym wywodom. Scrum Master musi być kompetentny i znać się na Scrumie tak, jak nikt inny. To znaczy, że musi mieć doświadczenie z działającym „prawdziwym” Scrumem. Nie może być sytuacji, w której Scrum Master gada bzdury niezgodne ze zdrowym rozsądkiem i praktyką stosowania Scruma. Jednocześnie nie powinien przeczyć Scrum Guide’owi. Powinna to być osoba, która wie kiedy i które zasady można nagiąć, a które są absolutnie niezbędne do tego, żeby zespół dobrze funkcjonował.
Bo Scrum Guide to nie jest zestaw porad który powstał „na sucho”, jako przepis do stosowania. Scrum to ujęcie tego, co w karierze jego autorów działało i się sprawdzało, wraz z modyfikacjami jakie zostały dodane na przestrzeni kolejnych lat. Jeżeli zabieramy się za wdrażanie litera po literze wszystkich tych pomysłów, nie rozumiejąc jakie są warunki początkowe konieczne do poprawnego działania, narażamy się na słuszne krytyczne komentarze, a czasami nawet na śmieszność.
Gorąco życzę każdemu, kto para się Scrumem w jakikolwiek postaci, żeby chociaż raz w swojej karierze miał/a do czynienia ze Scrum Teamem prosto z podręcznika. Wtedy można zobaczyć, jak w firmie która naprawdę kieruje się zwinnymi myśleniem, Scrum pozwala rozwinąć skrzydła i efektywnie dostarczać wartościowe produkty. Tego doświadczenia wielu Scrum Masterom niestety brakuje.
W odpowiedzi na to mogę doradzić coś, co już padło w tym tekście, czyli dołączenie do zespołu scrumowego w jakikolwiek innej roli niż Scrum Master. Niech to będzie analityk, tester, programista, architekt, designer, itp. Zróbmy to po to, że móc na własnej skórze sprawdzić, jak ten proces działa i zacząć go usprawniać od wewnątrz, zmieniając te rzeczy, które będą nam faktycznie przeszkadzać. Będziemy o nich wiedzieć, bo odczujemy je na własnej skórze.
Quo Vadis, Scrum Masterze?
Wszystkim chcącym się rozwijać w roli Scrum Mastera polecam wrócić do fundamentalnego pytania i obstawić jedną z dwóch opcji. Jeżeli uważamy, że Scrum odejdzie do lamusa, wtedy musimy wykorzystać swoje doświadczenie w innej roli. Musimy stać się kompetentni w jakimś innym obszarze zawodowym.
Z drugiej strony, jeżeli wierzymy w to, że Scrum i Scrum Masterzy będą przydatni jeszcze przez długi czas, musimy odróżnić się od dziesiątków czy setek Junior Scrum Masterów i potrafić dostarczyć prawdziwą wartość dla zespołów w których pracujemy. Musimy także umieć pokazać tą wartość osobom zarządzającym.
Z jednej strony wszystko, co robimy dla zespołu to powinny być rzeczy, za które będą nam wdzięczni. Niech to będzie możliwość skupienia się na pracy, prostowanie procesów, ogarnianie technikaliów, upraszczanie procedur, praca z zależnościami, synchronizacja z innymi zespołami, pomoc Product Ownerom w priorytetyzacji i zarządzaniu backlogiem, i tak dalej. Ważne jest jednak też aspekt dostarczenia wartości dla organizacji. Tu musimy potrafić pokazać, że nasze działania faktycznie przynoszą określone korzyści. Oczywiście, jeżeli nasze zespoły będą działały sprawniej i lepiej, to będzie to łatwe. Upewnijmy się jednak, co konkretnie znaczy „lepiej”, bo czasami oznacza to „szybciej”, a czasami „lepsze produkty”.
Na pewno bezpiecznym kierunkiem jest rozwijanie zarówno kompetencji deweloperskich (w myśl tego kim jest Deweloper w zespole scrumowym) jak i scrummasterskich. Tak samo warto być kompetentnym technicznie, produktowo i scrumowo. Jeżeli to brzmi jak dużo wymagań i jeszcze więcej pracy, to pamiętajmy, że rola Scrum Mastera to nie jest rola juniorska. Żeby móc wspierać innych, musimy się znać na tym, co oni robią, a w dodatku jeszcze posiadać wiedzę i umiejętności, której oni nie mają.
Kierunków do rozwoju nie brakuje, podzielcie się w komentarzach tym, który wybieracie i dlaczego.
