Niektórzy uważają, że obowiązki Scrum Mastera to głównie codzienne spotkania (tzw. „stand up”) oraz co 1-2 tygodnie spotkania podsumowujące (Review i retrospection) i planujące (Sprint Planning), przy których nie trzeba wiele robić poza ich zwołaniem. Można i tak ale uważam iż zgodnie z zasadą iż jeśli już coś robisz to rób to jak najlepiej z pożytkiem dla wszystkich. Dlaczego warto się zaangażować w rolę Scrum Mastera na 100%?
Zacznijmy od początku, po co komu Scrum Master?
Celem prowadzenia projektów w trybie Agile jest lepszy efekt pracy a przez to większe zyski dla organizacji. Tak to widzi biznes, teoretycznie też powinno to oznaczać stabilniejsze i wyższe zarobki dla członków zespołu. Dzieje się tak m.in. dzięki częstym rozmowom zespołu ze sobą i klientem oraz elastycznymi sprintami.
Z ich perspektywy to przyjemniejsza praca i wpływ na to co się wykonuj . a więc większa satysfakcja
Staraj się też dla siebie gdyż szybciej awansujesz, będziesz miał z pracy więcej satysfakcji a inni będą Cię szanować (a może nawet polubią).
Obowiązki Scrum Mastera w dużym skrócie:
0. Start projektu (kick-off) – omówienie zasad Agile i ustalenie manifestu pracy wraz z definicją zakończenia sprintu (DoD) i gotowości do realizacji (DoR)
1. Sprint planning – spotkanie z estymacją zadań, prowadzący je SM może urozmaicić np. planning pokerem, ew. pomaga przygotować Backlog wg. DoR
2. Stand-up’y – prowadzący SM dba o czas 15 min i regułę „wczoraj, dziś, blockery, czy zdążymy”, podsumowuje i urozmaica np. piłeczką głosu / biegami
3. Review i DEMO – prowadzący SM dba aby każdy pokazał co zrobił w sprincie, ew. przypomina PO o odpowiedzi czy tego efektu oczekiwał i co planuje
4. Retrospection – prowadzący SM dla o zaangażowanie zespołu w poprawę ich pracy, np. urozmaicając je i podkreślając co się poprawiło (nie powtarza się)
Poza spotkaniami Scrum Master pomaga usunąć blokady w realizacji sprintu, sprawdza jego postęp używając wykresów spalania (burndown charts) i efektywności zespołu (team velocity)
0. Start projektu (kick-off)
– na początku warto przygotować krótką prezentację o Scrum aby wszyscy się zgadzali co do zasad współpracy (to też w sytuacji gdy Scrum Master dochodzi do projektu w trakcie) lub nieco dłuższą jeśli Product Owner, zespół lub jego poszczególni członkowie nie pracowali wcześniej w Scrumie + taka prezentacja powinna trafić do każdego nowego członka zespołu
– standardowa prezentacja może zostać wzbogacona o elementy stricte z danego projektu żeby zespół od razu wczuł się w jego realia choć i tak Product Owner powinien poprowadzić samodzielnie krótką część takiego spotkania i przez 30 minut opowiedzieć o wizji projektu i kolejnych krokach potrzebnych do jego realizacji w zaplanowanych sprintach na road mapie projektu
– w trakcie spotkania typu kick-off należy utworzyć z zespołem Manifest projektu będący wyrazem oczekiwań jego członków i Product Ownera jako spisaną „umowę” między nimi jak będą współpracować co najlepiej będzie motywować do pracy w trybie Agile; może on być aktualizowany po retrospektywach a nowi członkowie powinni się z nim zapoznać
– każdy z członków zespołu powinien dołożyć coś od siebie przedstawiając się jednocześnie z pozycji swojej roli i doświadczenia oraz wkładu, który mógłby dodatkowo wnieść do projektu (np. niektórzy developerzy mogą się specjalizować w mapach przydatnych w danym projekcie a testerzy biegając rano testować aplikacje pomiarowe w projektach tego typu
– z manifestu niejako wychodzi Definition of Done czyli kryteria akceptacji, które user stories, bugi i taski mają spełniać z żeby zostać uznane za gotowe do wdrożenia, raczej techniczne (głównie chodzi o testy manualne i ich automatyzację oraz testy jednostkowe w kodzie i testy akceptacyjne na środowisku) oraz definition of Ready czyli merytoryczne przygotowanie zadań gotowych do wdrożenia
– w ramach kick-offu Scrum Master i cały zespół może pomóc Product Ownerowi lepiej opisać zgodnie z przyjętymi zasadami i zrobić estymację dla pierwszego sprintu, dzięki czemu będziemy mieli zaplanowaną pracę a Product Owner będzie miał czas i wiedzę do stworzenia kolejnych epików i user stories lub zaplanowania dalszej road mapy jeśli takiej jeszcze nie zrobił
1. Sprint planning – 2-3h
– przed sprint planningiem Scrum Master powinien sprawdzić gotowość Backlogu Produktu do kolejnego sprintu zwracając uwagę Product Ownerowi i ew. pomóc z user stories nie spełniające wymagań stworzonej Definition of Ready lub Scrum Guides czyli standardowym wzorem „Jako [typ użytkownika], chcę aby [coś się stało], żeby [uzyskać efekt]” i pojęciem INVEST czyli wytycznymi user story
– jeśli się tak umówi z Product Ownerem, ewidentnie błędnie nadawane priorytety może samodzielnie zmieniać oraz usuwać dublujące się bądź nieaktualne zadania a także pomóc priorytetyzować Backlog ustawiając zadania z wyższym priorytetem na szczycie listy; jest to szczególnie istotne jeśli Product Owner reprezentuje klienta z innej organizacji niż Scrum Master i Zespół Deweloperski,
– najlepiej żeby w trakcie sprintów cały zespół się angażował w ilości 10% między pracami właściwymi do sprawdzenia przyszłych user stories w ramach Product Backlog Refinement / Grooming i rolą Scrum Mastera powinno być angażowanie członków zespołu do tego w ramach przerwy na kawę itp. bo nikt nie pracuje efektywnie 8 godzin a tak może odprężyć się wciąż wpływając na rozwój projektu
– przed sprint planningiem z reguły odbywa się sprint review i po niej sprint retrospective, które jednak przeprowadzone w 1 dniu mogą znacznie zmęczyć zespół z racji trzech, z reguły 2 godzinnych spotkań więc z racji potrzeby pogodzenia spokojnego wydania nowej wersji sugeruję review w czwartek a retrospektywę i sprint planning w bardziej luźny piątek aby zacząć kolejny nowym sprintem- podczas sprint planningu na początku Product Owner jeszcze raz opisuje ustnie cele sprintu na bazie wcześniej udostępnionych user stories zgrupowanych w tzw. epiki choć czasem w jego imieniu robi to Scrum Master (niezgodnie z regułami Scrum Guides) co najczęściej się dzieje wtedy gdy Product Owner jest reprezentuje inną organizację (jest klientem) niż Zespół Deweloperski (dostawca IT) aby przyspieszyć prace z racji braku pełnej dostępności i zaangażowania Product Ownera ryzykując jednak brak pełnych odpowiedzi i niezrozumienie intencji nawet jeśli wcześniej o taskach rozmawiali
– następnie Zespół estymuje poszczególne user stories zwykle w punktacji 1-100 gdzie obieramy przykładowe zadanie 1 punktowe jako najprostszą wytyczną do estymacji, np. zmiana logotypu i zwykle powyżej 13 punktów rozbijamy zadanie na mniejsze na co powinien zwrócić uwagę Scrum Master, który też monitoruje rozmowę zachęcając członków do zadawania uszczegóławiajacych pytań
– warto zadbać o uatrakcyjnienie tego spotkania np. w formie planning pokera czyli kart do gry z estymacją punktów w której osoba, która wyłoży kartę z najmniejsza i największą wartością powinny odpowiedzieć dlaczego akurat taką podały a gdy na dłuższą metę staje się to nudne Scrum Master może dołożyć żetony jak te z kasyna, które stawiamy na to iż nasza wycena jest odpowiednia
– w pierwszych sprint planningach korygujemy szybkość sprintu tzw. team velocity aby z jednej strony nie przesadzać z ilością punktów story points, które Zespół Deweloperski może zrealizować gdyż nikt nie lubi nie skończonych prac a z drugiej strony Scrum Master nie powinien dopuszczać do sytuacji, że w każdym sprintem trzeba dodać zadania z Backlogu gdyż te zaplanowane już są skończone- zauważyłem iż mimo, że estymowane są punkty złożoności czy poziomu trudności, ang. user stories point complexity, to często te punkty odpowiadają ilości godzin pracy, które ew. mogą być ich podwójną liczbą wobec prac zarówno front-end jak i back-end lub potrojoną z dodatkiem makiet UX i projektów graficznych co Scrum Master może sprawdzić dopisując od razu szacowany czas pracy
– jedną z alternatyw estymacji jest jej uproszczona wersja szybkiego omawiania w punktacji 1-2-3 gdzie punkty są zbliżone raczej do dni niż godzin jak w przypadku planning pokera i punktacji 1-100 gdzie 0,5 punktu może służyć jako niepełny dzień dzięki czemu estymacja jest łatwiejsza ale z drugiej strony mogą umknąć pewne pytania potrzebne do szybszego wykonania zadania (sprawdźmy to)
– osobną sprawą jest pokrycie oprogramowania testami jednostkowymi i automatycznymi manualnymi co też ułatwia refaktoryzację kodu do coraz wyższych wersji danego języka co też zajmuje czas i często jest nawet lepszą opcją niż dodawanie nowych tasków z Backlogu do zakończonego projektu gdyż zwiększa satysfakcję zespołu z rozwijania oprogramowania i swoich umiejętności (motywacja)
– w ramach Backlogu sprintu ważne jest aby zostawić też pewien margines na błędy wychodzące w trakcie używania aplikacji przez realnych użytkowników czego nawet najlepsze testy nigdy nie są w stanie przewidzieć więc z czasem team velocity może się zmniejszyć gdyż poświęcamy 10-20% na rozwiązywanie pilnych problemów na wersji LIVE (im mniej tym więcej czasu na prace rozwojowe)
** Istotne jest rozróżnienie między wynikłymi problemami i zmianami w trakcie sprintu, których nikt nie lubi bo wprowadzają chaos a czasem doprowadzają do failu sprintu, ew. jeśli organizacja nie pozwala na czysty Scrum bez zmian w trakcie sprintu Scrum Master może „handlować” z Product Ownerem taskami na zasadzie „coś za coś” i lepiej to zostawiać na koniec a najlepiej w ogóle nie przyjmować zmian do trwającego sprintu i zacząć od nich kolejny
2. Poranne stand-up’y ~ 15 min
członkowie zespołu w 15 min mówią „co wczoraj zrobiłem, co dziś planuje, jakie mam blockery i czy zdążymy ze sprintem
– sprawdzenie Backlogu sprintu przed standupem w celu zidentyfikowania ew. blockerów, krytycznych błędów i zmian sytuacji o których Zespół może nie wiedzieć (bo dot. osób 3) lub ich nie zauważyć
– spoglądanie na wykres spalania (ang. Burndown Chart) wskazujący ile zadań / story points / czasu zostało w projekcie w porównaniu do równej linii przedstawiającej planowaną efektywność*
– przygotowanie każdego dnia / tygodnia czegoś specjalnego dla zwalczenia nudy jak pałeczka głosu, koło fortuny czy rzucana piłka „kto teraz” o ile zespół to docenia (nie wszystkich to bawi)
– przeprowadzenie 15 min standupu podczas którego członkowie zespołu na stojąco dla przyspieszenia spotkania (pomagają w tym ww. elementy) mówią co zrobili wczoraj i co zrobią dziś
– jeśli pojawił się blocker u kogoś i nie można go szybko omówić na standupie to po nim Scrum Master powinien go wyjaśnić z osobami których dotyczy i pomóc rozwiązać lubzaplanować dalsze kroki
– przydatne jest podsumowanie spotkania kto co zrobił wczoraj i zrobi dzisiaj oraz podkreślenie ew. blockerów jako punkt odniesienia na kolejny standup i notatka dla nieobecnych (i ew. stakeholderów)- uważam za wskazane aktualizacje stanu blockerów w trakcie dnia np. serwer / bitbucket ruszył czy osoba z innego teamu (przy współpracujących zespołach Agile Scale) zrobiła blokujący kogoś task
– po standupie Scrum Master powinien sprawdzić user stories, bugów i tasków w Backlogu Sprintu czy się nie „zawieruszuły” bo ktoś nie odbił tasku na kogoś innego lub nie brakuje im odpowiednich informacji oraz zadbać o odpowiednie ich powiązanie ze sobą i priorytety
– im bliżej końca sprintu tym atmosfera się rozluźnia lub zagęszcza w zależności od pewności co do dowiezienia lub nie sprintu, dobrą metodą jest rozpoczęcie od wyżej estymowanych user stories z racji większego ryzyka iż coś w nich może być niezrozumiałe i wymaga doprecyzowania* w najczęściej używanym oprogramowaniu do Scruma, Jira Agile występuje istotny problem z mierzeniem spalania story points i trzeba trochę się nakombinować aby ten wykres wyświetlić.3. Review (w tym DEMO) – 1-2 h
– przedstawienie przez Zespół developerski kolejnej wersji produktu jest bardzo ważnym wydarzeniem zwieńczającym projekt z którego zespół ma być dumny, Scrum Master może poprzez dbanie o atmosferę pracy, odpowiednie rozpisanie subtasków do user stories i ścieżek testowych może pomóc zespołowi nie tylko w trakcie sprintu ale też przy przedstawianiu DEMA (mają być z niego dumni!)
– aby DEMA nie przedstawiały zawsze te same osoby (lub osoba) z racji większej skrytości niektórych osób wobec innych ani żeby Scrum Master nie wskazywał palcem kto tym razem ma przedstawić DEMO warto na początku wspólnie ustalić, że każdy musi to zrobić i wkreślić na tablicy kto już to zrobił lub iż każdy przedstawia tą część, którą zrealizował aby czuł odpowiedzialność i satysfakcję
– często Sprint Review ogranicza się do przedstawienia DEMA kolejnej wersji produktu i w takiej sytuacji Scrum Master powinien pytać Product Ownera o jego opinię nt. tej wersji produktu nie tylko pod kątem poprawnego wdrożenia wg założeń ale też samego produktu i to też jest moment żeby przedstawić dalszą wizję produktu
– problematyczne wydaje się przedstawianie niektórych typów aplikacji jak aplikacje mobilne i tutaj może się przydać emulator bądź podłączenie komórki pod większy ekran, z kolei za urządzenia dotykowe jak infokioski w galerii w wersji mikro mogą służyć tablety o co powinien zadbać Scrum Master
– istotną rola Scrum Mastera jest motywowanie zespołu też gdy nie uda się dowieźć całego sprintu przez zwracanie uwagi na wykonane części zadań aby ominąć dołującego wrażenia niepowodzenia i zwiększyć morale przez podkreślenie iż zbliżyliśmy się do osiągnięcia celu i wyciągniemy wnioski na przyszłość na retrospektywie żeby być jeszcze lepszym i zgranym zespołem
– Scrum Master nie może pędzić za ilością wykonanych tasków
– powinniśmy z zespołem ustalić jeden stały dzień na DEMO i review oraz późniejszy release nowej wersji LIVE a ze względu na ograniczoną dostępność zespołu w weekend i tym, że nikt nie lubi nadgodzin ani nerwowych telefonów z pracy w weekend, nie należy tego robić w piątek a w środę gdyż daje potencjalnie 2 dni na spokojne dokończenie przedłużonego w razie „W” sprintu lub szybkie poprawki ew. bugów po wejściu na produkcję
4. Sprint Retrospection
– w dużej mierze to od Scrum Mastera jako sugerującego pewne rozwiązania (w porozumieniu z Zespołem Developerskim) zależy kiedy to spotkanie powinno mieć miejsce. Z reguły popularnie nazywane „retro” odbywa się po Sprint Review z reguły w środę lub czwartek jako lepszym czasem to wypuszczenia nowej wersji produktu lub przed Sprint Planning, który odbywa się najczęściej w czwartki lub w piątki dzień po Review ze względu na możliwe zmęczenie zespołu ciągłymi spotkaniami w trakcie jednego dnia. Osobiście preferuję release w czwartek rano, potem
bardziej spokojny jako bardziej spokojny dzień
– najczęstszym problemem w przypadku
nie w piątek (w weekend jest ograniczony support w razie „W”)
może to być rysunek