Już kilka lat temu stanowisko Scrum Mastera zaczęło być postrzegane jako prosta i łatwa ścieżka dostania się do mlekiem i miodem płynącego świata IT. Ostatnio na LinkedIn zobaczyłem nawet hasło “Zostań Scrum Masterem, nie trzeba umieć programować”. Czyli wystarczy przeczytać książkę i zdać godzinny test online i można już zarabiać olbrzymie pieniądze.
No chyba jednak nie sądzę.
Zanim więc postanowisz rozpocząć karierę Scrum Mastera, chciałbym Ci przybliżyć oczekiwania względem tej roli.
Scrum Master jako trener zespołu
Każdy efektywny zespół sportowy ma swojego trenera. Osobę, która wprawdzie nie biega za piłką, ale obserwuje jak członkowie zespołu to robią. Czy są zgrani, czy współpracują ze sobą, czy ich taktyka jest skuteczna. Podobną rolę w Scrumie pełni Scrum Master. Jest mentorem, pomagającym zespołowi i całej firmie być bardziej efektywnym. Dlatego zatrudnianie Scrum Mastera bez doświadczenia w iteracyjnym tworzeniu oprogramowania jest jak wybór na trenera kogoś, kto nigdy nie grał w piłkę. Można, ale trzeba mieć świadomość konsekwencji – co się traci, a co się zyskuje. Oczywiście są firmy, które w ogóle nie interesuje takie doświadczenie, ale zastanów się, czy tam się nauczysz jak w rzeczywistości powinien wyglądać Scrum. Jeżeli zespoły i cała organizacja nie widzą wartości ze Scrum Masterów, to albo się ich po jakimś czasie pozbywają, albo akceptują ich obecność, traktując jako zło konieczne lub jako sympatycznych współpracowników, mających czas na głupoty i biegających po biurze z kolorowymi karteczkami i pisakami. W najlepszym przypadku zrobią ze Scrum Mastera sekretarkę odpowiedzialną za rezerwację sali, zdobycie przekąsek i “ogarnięcie Jiry” albo chłopca na posyłki. Jeżeli taka rola Cię zadowala, to prawdopodobnie nie musisz czytać dalej. Wiedz jednak, że fora internetowe są pełne wpisów sfrustrowanych Scrum Masterów, którzy nie są brani na poważnie przez kolegów z pracy.
Cztery obszary działalności Scrum Mastera
Oczywiście samo doświadczenie z tworzenia oprogramowania nie wystarcza, żeby być efektywnym Scrum Masterem. W rzeczywistości jest on odpowiedzialny za cztery obszary:
- jak sobie radzi zespół,
- jak sobie radzi Product Owner,
- jak sobie radzi organizacja,
- jak wyglądają praktyki inżynieryjne.
(Jeżeli chcesz zobaczyć na co powinien zwrócić uwagę Scrum Master w każdym z tych obszarów, to przeczytaj Listę Kontrolną dla Scrum Masterów.)
Z mojego doświadczenia wynika, że na polskim rynku większość Scrum Masterów skupia się na zespole, a tylko niewielu pamięta, żeby wspierać swojego Product Ownera i organizację. Najmniej zaś skupia się na praktykach inżynieryjnych. W ankiecie, którą przeprowadziłem ostatnio na LinkedIn, na pytanie “Czy Wasz Scrum Master widział Wasz kod?”, ponad 60% osób odpowiedziała “nie”.
Z jednej strony wynika to z faktu, że aby znać zwinne praktyki inżynieryjne dobrze, trzeba ich używać na co dzień. Ludzi, którzy mają tą wiedzę i jednocześnie chcą się nią dzielić jest po prostu niewiele. Z drugiej, właśnie z tego mitu, że Scrum Master nie musi się znać na programowaniu.
Praktyki inżynieryjne Agile
Tymczasem, żeby iteracyjnie dostarczać oprogramowanie, zespół musi zmienić swoje praktyki inżynieryjne. Jeżeli produkt ma działać na koniec Sprintu, to musi zostać przetestowany. O ile w Waterfallu mogliśmy wykonać wszystkie testy ręcznie, to w krótkiej iteracji nie ma już na to czasu. Dlatego, jeżeli chcemy się upewnić, że oprogramowanie nie zawiera błędów, to musimy zautomatyzować testy. A to wcale nie jest takie proste zadanie, o czym przekonało się już wiele zespołów, których wynik kilkumiesięcznych projektów “automatyzacji testów” w całości wylądował w koszu. Czy w takiej sytuacji nie przydałby się im mentor, który pomoże im uzyskać użyteczne testy? I czy taka osoba nie zdobędzie zaufania i szacunku zespołu?
To samo dotyczy pozostałych praktyk inżynieryjnych wspierających iteracyjne tworzenie oprogramowania, takich jak ciągła integracja (Continuous Integration, CI), ciągłe dostarczanie (Continuous Delivery, CD), refaktoring (Refactoring) czy ewolucyjna architektura (evolving architecture). Zespół z pewnością skorzysta z pomocy osoby, która ma doświadczenie w tych praktykach.
Zrozumieć jak powstaje oprogramowanie
Czy to oznacza, że ja mogę pokazać zespołowi dowolną praktykę inżynieryjną? Nie, ale staram się je znać i rozumieć jakie są konsekwencje ich stosowania, lub braku. Żeby pomóc zespołowi, muszę wiedzieć jak powstaje oprogramowanie, co powoduje dług techniczny i dlaczego zadanie oszacowane na osiem godzin tyle nie zajmie. Bez tej wiedzy, z jednej strony nie jestem w stanie efektywnie pomagać zespołowi, z drugiej, nie mam szans przekonać ich, że wiem o czym mówię. Co najczęściej skończy się zignorowaniem tego co powiem. Natomiast jeżeli nie mam wiedzy w jakimś obszarze to będę szukał kogoś, kto może nam pomóc, czy to wewnątrz firmy, czy też na zewnątrz.
Jak zacząć?
Mam nadzieję, że udało mi się Ci pokazać, że rola Scrum Mastera nie jest taka prosta jak ją malują i że wiedza, jak powstaje oprogramowanie jest Scrum Masterowi niezbędna. Jeżeli tak, to pora się zastanowić jak je zdobyć. Oczywiście nic nie zastąpi doświadczenia. Scrum Masterzy, którzy kiedyś pracowali jako testerzy, czy deweloperzy, mają lepsze zrozumienie całego procesu i łatwiej im się wczuć w sytuację zespołu, gdy ten powie, że czegoś się nie da. Nawet jeżeli jesteś już na tym stanowisku, to nic nie stoi na przeszkodzie, żeby zakasać rękawy i spróbować własnych sił. Oczywiście, dużo bezpieczniej dla wszystkich będzie, jeżeli spróbujesz pair programingu (czyli siądziesz z jedną osobą z zespołu), lub mob programmingu (czyli siądziecie całym zespołem nad jednym problemem). W ten sposób rozwiniesz swoje kompetencje, zrozumiesz, z czym boryka się zespół, a przy okazji pokażesz mu swoją chęć zdobycia tych umiejętności. Zarówno pair jak i mob programming można z powodzeniem praktykować zdalnie.
Oprócz tego, zainwestuj w edukację. Zapisz się na kursy i warsztaty, które pokażą Ci jak tworzyć oprogramowanie. Kup książki. Oglądaj prezentacje. Dołącz do meetupów. Dostępnych możliwości jest naprawdę mnóstwo.
Na koniec pora odpowiedzieć na pytanie z tytułu tego wpisu. Czy Scrum Master musi umieć programować? Moim zdaniem nie musi, ale powinien przynajmniej umieć przeczytać kod. No chyba, że Twój zespół nie zajmuje się tworzeniem oprogramowania. Wtedy musisz umieć przenieść zwinne praktyki inżynieryjne w Wasz kontekst.
Jeżeli zaciekawił Cię temat rozwoju Scrum Mastera, to przeczytaj o modelu Shu-Ha-Ri.
