Z tego artykułu dowiesz się, jakie konkretne techniczne kompetencje są potrzebne w codziennej pracy Scrum Master. Dodatkowo pokażę jak wykonać pierwsze kroki oraz co jest wymagane na rekrutacji. Poznasz proces, który zajmuje ok 30 godzin nauki. Zaczynajmy!

Czym są umiejętności techniczne Scrum Mastera?

Jak działa internet, czym jest serwer DNS, czym jest HTTPS oraz podstawy szyfrowania. Czy to stanowi podstawę pracy Scrum Master? Zdecydowanie nie, ale część rekruterów postawiło sobie za cel umniejszenie tej roli, a podczas rozmów o pracę, zbicie z tropu kandydata/tki.

Rzeczywistość znacznie różni się od tego co spotykamy na rozmowach, i na tym się skupię. O rekrutacji można przeczytać w podsumowaniu.

Umiejętności techniczne Scrum Master to nic innego jak płynne posługiwanie się narzędziami wspierającymi codzienną pracę zespołu. Przykładowo, nie musimy znać historii Jiry, ani tego czym różni się od innego systemu zadań, natomiast potrzeba nam wiedzieć, że możemy dodawać personalizowane pola do konkretnych typów zadań.

Dodatkowo, jako osoba wspierająca procesy, można oczekiwać, że Scrum Master bez problemu prowadząc spotkanie, wykona diagram przepływu, oznaczy ryzykowne kroki oraz zapyta się o kolejne aktywności. Wszystko ładnie opakuje i upewni się, że każdy ma tę samą wiedzę – czyli może to być podsumowanie zapisane w Confluence, albo wysłane mailem.

Jaki poziom jest wymagany w codziennej pracy

Można powiedzieć, że „to zależy”, jednak ja lubię konkrety. 90% firm, gdzie jest Scrum Master korzysta z jiry, confluenca, czasem można korzystać z tablic online. Codzienność to korzystanie z

• Narzędzie do Daily
• Wizualizacja ryzyk
• Dążenie do Celu Sprintu
• Postęp w realizacji zakresu
• Roadmapa z uwzględnionymi Product Goal
• Narzędzia wspierające PO
  • Big-picture
  • Plany na następny sprint
• Narzędzia wspierające organizacje
  • inne zespoły
  • plan działania poza swoim zespołem

Tak jak widać na powyższej liście, nie mamy tutaj programowania, działania na branchach i tak dalej. Codzienność opiera się głównie na korzystaniu z narzędzi. Z mojej praktyki wynika, że raz na jakiś czas tworzy się nowe narzędzia, tablice, wizualizacje, w zależności od tego jak przebiega praca.

Zazwyczaj są to reakcje reaktywne, czyli podejmujemy kroki, aby ogarnąć rosnącą skomplikowaność procesu, a czasem proaktywne, gdy planujemy dalsze prace. Reaktywne działania podejmujemy gdy pojawia się wiele pytań „gdzie jesteśmy”, „kiedy skończymy” po to, aby zwizualizować sytuację i stworzyć jedno miejsce informacji. Proaktywne, gdy planujemy prace i już na starcie unikamy powtarzalnych pytań.

O co pytają na rekrutacji

O matko! Tak można to skomentować. Możesz mieć #PSM1 i #PSM2 a ludzie i tak będą pytać kim jest Scrum Master, albo ile ma trwać daily. Dlaczego? Bu lubią gadać o Scrum, a drugi powód jest taki, że jest wiele przebierańców, którzy kursami z Udemy, typu ZZZ wykształciło u siebie obraz Scrum Mastera jako niańki zespołu „jak się dzisiaj czujesz”.

Pomijając głupie pytania o wyższości StoryPoint czy godzin, albo o historię Scruma, poniżej prezentuje narzędzia które musisz znać. Jest to bardzo podstawowa lista, która jest kluczowa w procesie rekrutacji, oraz w codziennej pracy. Nie traktowałbym tego jako „rekrutacyjna” checklist, bo ona jest zdecydowanie dłuższa tylko jako niezbędnik narzędzi Scrum Master.

Oczywiście, pojawią się głosy „nie przywiązuj się do narzędzi” „empiryzm nie wskazuje na narzędzia”, natomiast ja się skupiam na sukcesie, efekcie. Kiedy cały zespół programuje, potrzebuje drogowskazów, stakeholderzy potrzebują jasnej informacji – stąd też wynikają pytania rekrutacyjne – jakimi narzędziami wspierasz zespół?

Podsumowując: na rekrutacji jest konieczne odczucie – ta osoba, z którą rozmawiamy, ma podstawy wiedzy narzędziowej, czyli będzie umiała sprawnie poruszać się w gąszczu wymagań.

Narzędzie 1: Systemy zadań: jira, azure oraz długi ogon (monday, clickUp)

Jak napiszesz, coś o Jira na pewnych grupach, od razu otrzymasz informację, że to nie jest zwinne narzędzie. Ale narzędzie nie jest w stanie ustawić zwinności. To bardzo bardzo ważne, w kontekście komentarza Jeff Sutherlanda poniżej. Czy coś więcej trzeba mówić?

Jak już głupotki mamy za sobą, a jeszcze nie masz doświadczenia w Jira, Azure, Monday, ClickUp, polecam następujące kroki.

1. Stwórz konto testowe w JIRA
2. Stwórz nowy projekt – Sprint
3. Dodaj zadania, utwórz tablicę

I można powiedzieć to tyle, natomiast, cóż to za umiejętność? Zrobienie konta. Dlatego tutaj wypisuję checklistę spraw, które Scrum Master wspierający zespół pracujący na narzędziach zadań umieć

• Szacowanie zadań i generowanie wykresu spalania
• Zmiana przepływu statusu w zadaniu
• Stwórzenie tablicy Kanban „poza sprintem”, np. bugi
• Wizualizacja postępu realizacji długu technologicznego
• Planowanie na dwa sprinty do przodu
• Uruchomienie współbieżnych sprintów
• Identyfikacja zadań „wiszących”

Kiedy spełnisz tę checklistę na własnych projekcie, możesz uznać, że znasz Jirę na tyle aby móc wspierać zespół. Oczywiście warto „pod ręką” mieć przewodnika podróży, mentora/kę, osobę która pomoże w trudniejszych przypadkach, a uwierz mi, pierwsze 3 miesiące z nowym dla Ciebie zespołem są najtrudniejsze.

Podsumowując: czy to jira, czy azure, czy clickup, czy monday – powyższa checklista jest uniwersalna, a wymienione aktywności powtarzają się w kolejnych firmach + każda organizacja ma swoje udziwnienia.

Narzędzie 2: Tablice zadań: zasady działania, Kanban

Tablica z 3 kolumnami To do / Inprogress/ Done to nie Kanban. Kanban to metoda do tworzenia narzędzi, a tablica Kanban jest jednym z efektów procesu wizualizacji. Problemem głównym jest mieszanie różnych procesów na jednym narzędziu.

Wyobraź sobie perspektywę klienta oraz developera. Zupełnie różnie spojrzenie na pracę, klient chciałby zobaczyć postęp w ramach funkcjonalności, developer, w kontekście zadań. Znów PO/PM, kontekst wymagań, ryzyk.

Jako SM potrzebujesz zrozumieć potrzeby i tak zastosować narzędzia, aby spełniały wymogi wizualizacji procesu – o tym właśnie jest Metoda Kanban. Sprawdź proszę dwa poniższe materiały gdzie wprowadzam w świat Kanbana.

Narzędzie 3: Procesy: draw.io

Słowa są abstrakcyjne, wysoko poziomowe, wymagają kontekstu. Diagram powinien się sam wyjaśniać. Z pomocą przychodzi narzędzie draw.io – darmowy program do wizualizacji procesów. Posiada wiele szablów, które można ze sobą mieszać. Oczywiście tak jak tablice online, draw.io możesz wykorzystać do wielu innych celów.

Scrum Master jak widzi pewien rozmyty proces, np. usuwanie zaległych błędów, albo podejmowanie decyzji co powinniśmy robić, powinien reagować i szukać usprawnienia. Słowna komunikacja jest szybka, ale ulotna. Poprzez wizualizację procesów. Zachodzi tutaj posiadanie kompetencji facylitacji spotkań, agenda, uczestnicy, oczekiwany efekt.

Pamiętaj, że dobry proces powinien

1. Sam siebie wyjaśniać
2. Wskazywać ryzyka procesowe
3. Uwzględniać wejścia do systemu
4. Informować o zmianie statusów
5. Pokazywać miejsca do uproszczenia
6. Ujawniać dodawaną wartość w procesie
7. …i tak dalej

Jednym słowem – diagram ma do nas gadać. Zachęcam do skorzystania z draw.io, oraz przeróżnych odpowiedników, i stworzyć procesy wytwarzania oprogramowania, codefreeze, wydań, dyskusji z klientem.

Narzędzie 4: Tablice on-line

Mamy retro – namalujmy statek, czy balonik, czy łódeczkę. Równie dobrze możemy namalować proces, albo tablicę Kanban (co możesz zobaczyć w filmiku w akapicie o Kanbanie). Oczywiście można to odebrać jako infantylizowanie, bo czasem wystarczy zapytać – co poprawić, nie ma się co obrażać. Jednak takiej wizualizacji sytuacji nie wykonasz w jira, jest to inna kategoria narzędzi.

Tablice online to obowiązek, i tutaj nie możemy się ograniczać do „miro, bo miro jest dobrze”, to tak jak z butami, moje są najlepsze. Poniżej prezentuje 3 obrazki ze strony conceptboard, lubię to ich rozwiązanie, co nie oznacza, że jest to najlepsze, co może być.

Mural zdecydowanie różni się w posiadanych funkcjonalnościach, tak samo miro działa inaczej. Pracą domową dla ciebie jest poznanie tych narzędzi, zauważnie jakie są różnice i co nam najbardziej odpowiada.

Postaraj się, na każdym wymienionym narzędziu wykonać te tablice

• Retrospektywa: balonik/statek + gwiazda + tabela
• Tablica kanban (zobacz filmik powyżej)
• Roadmapa
• Zależności procesowe
• Głosowanie na pomysły

Narzędzie 5: gitflow

Wchodzimy na wyższy poziom. Właśnie dotykamy IT. gitflow – czyli proces w jakim pracują programiści. Proces, który umożliwia ciągłe wydawanie produktu bez tworzenia procesu „code freeze”.

Po co nam gitflow? Po to, aby zarządzić zależnościami i zmianami w kodzie, aby jeden programista nie musiał czekać na drugiego, aby uspójnić współpracę. Na poniższym obrazku są wyniki google images. Te kropeczki, to kolejne wersje kodu tworzonego przez programistów. GIT – posiada algorytm łączenia zmian kodu w jednym pliku – co ułatwia pracę specjalistów.

To o czym warto tutaj, chociaż wspomnieć to: branche. Czyli odgałęzienia z głównej linii – master. Oznczacza to że, programista kopiuje kod na swój komputer, tworzy branch i pracuje nad nim. Po wysłaniu zmian na serwer inny programista, może pobrać te odgałęzienie i kontynuować pracę.

Więcej na ten temat przeczytasz na dedykowanych stronach, natomiast w świecie IT, przy współpracy z programistami, jest to kluczowe. Często spotykam się, z osobami po kursach PSM1, które nie mają świadomości istnienia tego podstawowego narzędzia, dlatego o tym wspominam tutaj.

Narzędzie 6: Continous Integration

Można by powiedzieć, że jest to element tego co wyżej. Czyli ciągła integracja kodu. Tutaj natomiast chciałbym wspomnieć o szerszym aspekcie, czyli integracja kodu na różnych środowiskach co pozwala nam mieć zawsze gotowy Increment do Releasu. STOP!

Środowiska. To słowo możemy tłumaczyć jako dostępne zasoby (serwery/wirtualki/przestrzenie) do umieszczenia działającego kodu.

• Środowisko dev – czyli stan który jest tworzony.
• Środowisko integration – miejsce, w którym kod jest łączony i testowany pod kątem integralności.
• Środowisko staging/pre-prod – przetestowana wersja gotowa do wgrania na serwer produkcyjny
• Środowisko prod – miejsce gdzie klienci korzystają z produktu

Oczywiście środowiska mogą nazywać się inaczej w zależności od organizacji, natomiast CI oznacza proces, w którym łączony kod wielu programistów jest uruchamiany na zasobach/serwerach. Jest to zaproszenie do kolejnego tematu, jakim jest devOps, ale to może jest temat na kolejny artykuł.

Proces CI zapewnia nas, że ciągle mamy działający kod, który możemy wydać, czyli spełniamy reguły Agile Software Development mówiące o ciągłym dostarczaniu działającego oprogramowania co za tym idzie – kod musi być gotowy do wydania.

Podsumowanie, rekrutacja, cv

Wspomniane tutaj narzędzia, procesy, metody pracy – nazywam narzędziami. Można ich użyć i odnieść skutek. Jest to podstawowa lista – wszak moja książka „Młotek Scrum Mastera” ma ponad 200 stron i jest pełna narzędzi. Znajomość teoretyczna – jest niewiele warta, dlatego użyłem tutaj wiele nazw narzędzi, w nadziei, że klikniesz, stworzysz konto i wykorzystasz.

Zrobienie „demo projektu” powoduje, że już jesteś w elicie osób zainteresowanych Scrumem. Wiele osób, słyszy Jira już wiele lat, ale jeszcze nie stworzyło darmowego konta, ani przykładowego projektu. Posiadając przykłady użycia, możemy tym zagrać właśnie na rekrutacji.

Zbuduj więc swoją bazę, testowych projektów, które potwierdzają Twoją wiedzę na temat narzędzi. Poświęć na każde narzędzie po 5-10 godzin. To pomoże Ci nabyć kompetencje i wpisać je do CV, aby podczas rekrutacji móc zaprezentować to podczas rozmowy, a poczas pracy, efektywnie, bez szukając słownictwa przejść do czynów.

Kończąc, jak zawsze, od 2017 roku, zachęcam do rozwoju, do nauki i podnoszenia swoich kwalifikacji. Jak podoba Ci się ta publikacja – napisz do mnie, ze swoim feedback. Niech Scrum będzie z Tobą! Mateusz