Na piętnastu stronach Scrum Guide’a – podstawowego dokumentu opisującego ten framework – roli Scrum Mastera poświęcona jest jedynie jedna strona. Na tej stronie znajdziemy kilkanaście punktów opisujących, w jaki sposób Scrum Master (albo pisząc krócej: SM) wspiera Właściciela Produktu, Zespół Deweloperski i całą organizację oraz przeczytamy definicję, iż SM to „servant-leader” zespołu. Tylko tyle.
Osobiście mam poczucie, że wyobrażenie o sposobie działania SM wśród znanych mi deweloperów jest bardzo różne. Niektórzy wyobrażają sobie SM jako osobę, która organizuje spotkania, inni jako osobę która usuwa przeszkody z drogi zespołu, inni jako kierownika-bez-prawa-do-podpisywania-urlopów, jeszcze inni jako osobę, która chodzi i sprawdza czy wszystkie zadania są wpisane w odpowiednie miejsca. Te wyobrażenia często mocno bazują na tym, co usłyszeliśmy o roli SM albo na tym, jakich SM w swoim życiu spotkaliśmy. A bazowanie na wyobrażeniach może łatwo doprowadzić do nieporozumień…
Może więc warto poświęcić kilka akapitów na przybliżenie tej roli?
Na początku – edukacja
Wyobraźmy sobie taką sytuację: pewna organizacja planuje nowy projekt, przydzielanych jest do niego kilkunastu czy kilkudziesięciu deweloperów i zapada decyzja „będziemy pracować w Scrumie!”. Zatrudniana jest osoba, która ma pełnić rolę Scrum Mastera. Co tak naprawdę będzie robiła ta osoba?
Początek pracy SM jest dość prosty – przede wszystkim musi zadbać o to, żeby wszystko, co jest zawarte we framework’u Scrum, znalazło swoje odzwierciedlenie w rzeczywistości. Czyli musi zadbać żeby zespoły deweloperskie miały odpowiednią wielkość i posiadały wszystkie kompetencje potrzebne do rozwoju produktu. Musi ustalić z Właścicielem Produktu, gdzie będzie przechowywany Backlog Produktu i zapewnić, że wszystkie zadania zostaną w nim zapisane. Musi ustalić długość sprintów i zadbać o zorganizowanie planowania, przeglądu oraz retrospekcji sprintu. Kiedy jest już zaplanowane wszystko, czego wymaga Scrum Guide, czasami SM dodaje do tego jeszcze dodatkowe elementy, które wydają mu się potrzebne – mogą być to na przykład spotkania Backlog Grooming lub Scrum of Scrums.
Zwykle zaplanowanie tego, jak będziemy pracować, odbywa się jeszcze przez rozpoczęciem prawdziwej pracy w projekcie. Wkrótce nadchodzi „dzień zero”, zespoły deweloperskie spotykają się i dostają zadanie – od dzisiaj pracujecie nad nowym projektem. Wtedy ważnym elementem pracy SM staje się edukacja – wytłumaczenie członkom zespołów deweloperskich, w jaki sposób mają one pracować.
Ilość czasu poświęconego na działalność edukacyjną oczywiście zależy do tego, jak bardzo członkowie zespołu deweloperskiego są oswojeni ze Scrumem. Jeżeli pracują po raz pierwszy w ten sposób – pracy jest sporo. Ale jeżeli dla deweloperów jest to kolejny projektu Scrum’owy – z reguły wystarczy powiedzenie, że „o dziewiątej rano mamy Daily Scrum Meeting” i wszyscy wiedzą, co powinni podczas niego robić.
Proces edukacyjny to nie tyle wykłady i prelekcje, co przede wszystkim reagowanie na codzienne zdarzenia i wyjaśnianie dlaczego pewne rzeczy robimy tak, a nie inaczej.
Sytuacja 1 (wszystkie opisane w tym artykule sytuacje wydarzyły się w rzeczywistości…)
Sprint w zespole X kończył się przeglądem o godzinie 11-tej. Podczas porannego spotkania okazało się, że jedno z zadań jest zaimplementowane, natomiast nie powstała do niego i nie została zatwierdzona dokumentacja techniczna. Jeden z deweloperów zapytał: „czy możemy teraz zamknąć to zadanie, a tę dokumentację napiszę po południu?”. SM zna tego dewelopera i wie że jak ta osoba coś obieca, to dotrzyma słowa. Widzi również, że zespołowi bardzo zależy na zakończeniu wszystkich zadań w sprincie. Co SM powinien zrobić w tej sytuacji?
Ważną rzeczą w tym procesie edukacyjnym jest nie tylko przekazanie wiedzy, ale również przekazanie wiary w to, że ten proces działa. Budowanie w członkach zespołu poczucia, że ten rodzaj pracy ma sens!
Z reguły Scrum Mater jest odpowiedzialny za prowadzenie pierwszych spotkań. Oczywiście nie musi tego robić, ale w praktyce na początku projektu bardzo często to właśnie SM zaprasza ludzi na spotkania i moderuje ich przebieg.
Ponieważ sprinty są krótkie i powtarzalne, ten proces edukacyjny z reguły przebiega dość szybko – pierwszy sprint jest odkrywaniem nowego świata, ale każdy kolejny jest powtórzeniem poprzedniego, także dosyć szybko następuje stabilizacja i zespół wie, w jaki sposób ma działać. I tak naprawdę wtedy kończy się prosta i łatwa część zabawy – a zaczyna się prawdziwa praca…
Im dalej, tym trudniej
Cała trudność w pracy SM polega na tym, że nie jest on odpowiedzialny tylko za to CO jest zaimplementowane w ramach framework’u Scrum, ale jest on przede wszystkim odpowiedzialny za to JAK jest to zaimplementowane. Cały Scrum Guide opisuje podstawowy framework: zdarzenia, role i artefakty – ale to właśnie odpowiedzialnością SM jest sprawienie, żeby cały ten mechanizm działał efektywnie! I nie ma jednego sposobu ani techniki sprawiającej, że działanie zespołów jest efektywne – zawsze zależy to od otoczenia, w którym pracujemy.
Tak naprawdę dużą częścią pracy SM jest obserwowanie tego, jak działa zespół, co dzieje się wokół niego i wdrażanie akcji naprawczych. Jednym z aspektów tej działalności jest usuwanie przeszkód – jeżeli cokolwiek sprawia, że zespół nie może osiągnąć swojego celu, to SM powinien być pierwszą osobą, która zwróci na to uwagę i postara się o usunięcie tej przeszkody. Oczywiście nie we wszystkich sytuacjach SM jest odpowiedzialny za usunięcie tej przeszkody – ale zawsze musi on dążyć do tego, żeby sytuacja została rozwiązana.
Sytuacja 2
Podczas spotkania Daily Scrum zespół narzeka, że musi pracować na stacjach wirtualnych, których wydajność jest kiepska. Praca jest możliwa, ale kompilacja aplikacji trwa kilkanaście minut, co oznacza że deweloperzy tracą sporo czasu czekając na wyniki. Większość osób w organizacji przyzwyczaiła się do tego, że na wirtualkach pracuje się mało wydajnie i wyznaje zasadę „zawsze tak było, więc tak być musi”. Co w tej sytuacji powinien zrobić SM?
Innym polem działania SM jest chronienie zespołu deweloperskiego. Scrum Guide definiuje to bardzo łagodnie: „Scrum Master pomaga także osobom spoza Zespołu Scrumowego zrozumieć, które z ich interakcji z Zespołem Scrumowym są pomocne, a które nie”. A w praktyce chodzi o to, jeżeli ktoś w organizacji zacznie nam przeszkadzać, to trzeba wziąć go na bok i delikatnie aczkolwiek stanowczo powiedzieć mu, że nie jest to miejsce dla niego. Często nie jest to proste, zwłaszcza gdy przeszkadzająca osoba to np. jeden z dyrektorów…
Sytuacja 3
Quality Manager stwierdził, że potrzebuje sprawdzenia jakości pracy wykonywanej przez jeden z zespołów. W celu wykonania tego sprawdzenia zorganizował pod koniec sprintu spotkanie dla większości członków zespołu. Podczas tego spotkania dla każdego z zadań wykonywanych w tym sprincie omawiane było, jaki jest rezultat tego zadania i jak zostało dla niego spełnione Definition of Done. Co powinien zrobić SM w tej sytuacji?
Dobrze jeżeli SM jest nie tylko reaktywny, ale potrafi również aktywnie proponować usprawnienia procesu wytwórczego. Bardzo do tego przydaje się wiedza i doświadczenie z innych projektów. Dobrze też jeżeli SM potrafi zainspirować członków zespołu do szukania i wdrażania usprawnień w codziennej pracy.
Z boku widać więcej
Ciągłe usprawnianie nie dotyczy tylko kontaktów ze światem zewnętrznym, ale też wewnętrznej pracy zespołu. Jeżeli w zespole jest jakaś dysfunkcja czy brak – powinno być to przedmiotem uwagi Scrum Mastera.
Sytuacja 4
Zespół wziął do sprintu cztery zadania. Od początku pracy nastąpił podział – część zespołu zaczęła pracować na zadaniem #1, druga część zespołu zaczęła zadanie #2. Po połowie sprintu zespół nadal pracuje nad tymi dwoma zadaniami i końca tej pracy jeszcze nie widać, natomiast zadania #3 i #4 są cały czas otwarte. Jak powinien zareagować SM?
Innym przykładem wymagającym reakcji może być uprawianie przez członków zespołu „blaming game”, np. widocznej przez wypowiedzi: „mieliśmy wszystko gotowe do Review, ale środowisko zintegrowane nam nie działało, bo Zły i Niedobry Administrator nie otworzył nam dostępów na czas…”
Oczywiście nie oczekujemy od SM tego, że będzie miał magiczne lekarstwo na każde niedomaganie pracy zespołowej – ale powinien jak najszybciej zwrócić uwagę zespołu na problem i zainspirować członków zespołu do znalezienia rozwiązania.
Ten aspekt pracy SM jest szczególnie trudny dla osób, które dzielą obowiązki SM wraz z codzienną pracą w zespole. Dla członka zespołu pewne rzeczy mogą być trudne do zauważenia lub trudne do podniesienia na forum – dużo łatwiej to zrobić będąc obok wykonywanych zadań.
Pułapki, wszędzie pułapki
Na każdego SM czeka też kilka interesujących pułapek. Może być to pokusa zarządzania zespołem np. w formie rozdzielania zadań. Podczas spotkania Daily Scrum SM może zacząć podpowiadać członkom zespołu kto co powinien zrobić. Wkrótce – jeżeli ta sytuacja będzie komfortowa dla członków zespołu – może się okazać, że nikt nie wykonuje zadań bez wskazania przez SM.
Inną pułapką jest brak otwarcia na nowe pomysły lub alternatywne podejścia. Można spotkać SM, który mówi, że jest agile coach’em od dwunastu lat, wszystko ma w małym palcu, wie jak robić sprinty i nie należy mu przeszkadzać. Taka osoba może nie przyjmować żadnych zmian lub propozycji niezgodnych z praktyką wypracowaną przez wiele lat swojej pracy.
Jeszcze inną pokusą jest bycie w środku wszystkich wydarzeń. Mówimy o sytuacji, w której SM nie rozdziela pracy, ale zbiera absolutnie wszystkie szczegóły zadań i monopolizuje kontakty zespołu ze światem zewnętrznym. Zespół uczy się, że cała komunikacja powinna przechodzić przez Scrum Mastera i trzeba powiadamiać go o każdej, nawet najdrobniejszej zmianie. Ten model również nie działa dobrze – budujemy tutaj wąskie gardło.
Scrum Master też człowiek i nieobce jest mu skupienie się na tym, co wychodzi mu najlepiej. Jeżeli będzie to np. konfiguracja narzędzi do wspólnej pracy, to może być tak, że będziemy mieć cudownie skonfigurowaną Jirę, ale za to zawaloną pracę zespołową.
Po czy poznać rasowego Scrum Mastera?
Ze względu na to, że Scrum Master w zależności od okoliczności występuje w różnych rolach i realizuje różne zadania – trudno jest określić idealny profil takiej osoby. To, czego będziemy wymagać od SM, będzie zależało głównie od tego, w jakich warunkach będzie pracował. Może być to np. coaching zespołu, wsparcie Właściciela Produktu, ochrona zespołu czy też wsparcie narzędziowe zespołu… Natomiast niezależnie od okoliczności można wymienić kilka cech, które SM musi posiadać.
Żeby być dobrym Scrum Masterem, trzeba przede wszystkim mieć umiejętność obserwowania pracy zespołu i dostrzegania związków przyczynowo-skutkowych między różnymi zdarzeniami. Scrum Master działa na granicy dwóch światów – świata technologii, którą rozwijamy oraz świata relacji między ludźmi, którzy tę technologię rozwijają. Przyda się wiedza zarówno o ciągłej integracji, jak i wiedza o fazach procesu grupowego Tucman’a.
Scrum Master musi być zorganizowany – jeżeli zapomina o rzeczach, których powinien dopilnowywać, to często w działania zespołu wdziera się chaos.
Dobrze jeżeli potrafi myśleć w kategoriach rozwiązywania problemów. Dobrze jest również jeżeli Scrum Master jest osobą, która lubi zmiany, optymalizacje oraz eksperymenty. Powinna być to osoba, która cały czas szuka nowych i lepszych rozwiązań oraz usprawnień.
Scrum Master nie może bać się wyrażać swojego zdania i konfrontacji z zespołem – czasami są sytuację, w których trzeba szturchnąć zespół i wytrącić go z miłej strefy komfortu.
Dobrze jeśli Scrum Master jest osobą, która podchodzi z entuzjazmem do zadań i potrafi zarazić resztę zespołu podejściem “we can do it!”.
A jaki jest Twój Scrum Master?
Cześć! Pozwolę sobie na kilka komentarzy.
Moim zdaniem, pierwszą rzeczą, jaką SM powinien zrobić w takiej sytuacji jest odpowiedzenie sobie na – cyt. klasyka – jedno, ale to zaj.biście ważne pytanie – czy organizacja, która taką decyzję podjęła rzeczywiście wie, co znaczy SCRUM, Agile i czy jest do takiej pracy przygotowana. Bo jeśli chęć pracy w SCRUMie bierze się z faktu, że Agile jest trendy, jazzy, fuzzy i wszyscy na rynku tak robią, to na 99% wyjdzie z tego scrumfall i wszyscy będą tylko narzekać, jaki ten Agile zły i gdzie go można sobie wsadzić. Agile, to nie zmiana metodologii, to zmiana myślenia, sposobów komunikacji i modelu współpracy pomiędzy członkami organizacji (zespołami, ludźmi). Jeśli organizacja nie jest szczerze zainteresowana zmianą, to szkoda czasu i wysiłku na wprowadzanie wszystkich artefaktów scrumowych, bo w samej organizacji nie zmieni to niczego.
Jeżeli zespół nie ma żadnego doświadczenia z Agilem (a o takiej sytuacji wspominasz kilka linijek poniżej cytowanego przeze mnie fragmentu), to moim zdaniem „dzień zero” to trochę za późno na edukację. Czy nie lepiej wziąć zespół na mały „team building” przed rozpoczęciem projektu i wtedy zaznajomić ich z podstawami przy piwku i grillu? Przynajmniej PO i stakeholdersi nie będą się czepiać, że pierwszy sprint się kończy a żadnych efektów nie widać;)
To zależy, co zespół ma wpisane w Definition of Done. Jak rozumiem, dokumentacja techniczna jest jednym z jej elementów. Więc opcji jest kilka – od wytłumaczenia jak ważne jest DoD i dlaczego powinno się jej przestrzegać, po wyedukowanie zespołu, że mają sobie pomagać – by w takiej sytuacji X nie został pozostawiony sam sobie z niedokończonym zadaniem.
Mater znaczy, że chodzi o kobietę?:)
Jest – to jak zespół ocenia swoją pracę podczas retro.
Jeżeli zespół na coś narzeka, to chyba jest to problem – więc pytanie, co powinien zrobić SM jest właściwie retoryczne w tej sytuacji…
Sytuacja 3 – z opisu nie bardzo rozumiem, o co tak na prawdę chodziło, natomiast zainteresowało mnie jedno:
To co, QM podzielił zespół na część lepszą i gorszą? Jednych lubie i uważam, że się znają, więc zaproszę na spotkanie a innych można olać? I SM się na to zgodził?!
Pozwolić zespołowi robić to, co zespół robi najlepiej – pracować, jeśli SM uważa, że coś można w sposobie pracy zmienić, powinien zaprezentować zespołowi różne opcje – by zespół mógł wybrać najbardziej odpowiadające mu podejście.
Moim zdaniem to nie jest „blaming game”, tylko stwierdzanie faktów. Taki bloker powinien być jasno sygnalizowany PO i stakeholderom, bo to nie wina zespołu, że ktoś inny dał ciała. Pytanie, czy SM mógł temu zapobiec?
To taka osoba jest zwyczajnym zadufanym w sobie dupkiem i powinna być izolowana od każdej formy zarządzania kimkolwiek:)
Taki SM chyba nie wie, na czym polega Agile…
Na pytanie jaki jest mój SM niestety odpowiedzieć nie mogę, bo sam pełnię tę rolę. W swojej pracy staram się dbać o zespół, by pracowało im się jak najlepiej. Mam to szczęście, że Zespoły z którymi do tej pory pracowałem, to wspaniali ludzie, zaangażowani w to co robią – i to tak, że nie wahają się klęknąć nawet gdy stoją po szyję w szambie:) Ale czy to rzeczywiście zasługa ich SMa? Niech się sami wypowiedzą;)
Moim zdaniem, pierwszą rzeczą, jaką SM powinien zrobić w takiej sytuacji jest odpowiedzenie sobie na – cyt. klasyka – jedno, ale to zaj.biście ważne pytanie – czy organizacja, która taką decyzję podjęła rzeczywiście wie, co znaczy SCRUM, Agile i czy jest do takiej pracy przygotowana.
Co w takim razie jak „nie jest gotowa”? Czy walczyć dalej? W swojej karierze widziałem już przykład wprowadzania SCRUM tam gdzie go być nie powinno. SCRUM to narzędzie, czasem nadaje się lepiej do realizacji projektu, a czasem nie.
W mojej perspektywie nadaje się dużo lepiej tam gdzie wiadomo ile jest czasu i peniędzy do wydania, a mniej wiadomo co jest do zrobienia, bo nie ma czasu na przeciąganie startu prac developerskich – tak tak, teraz pewnie wszyscy mnie zbesztają, że jak to tak, a no takto.
Nie twierdzę, że nie należy się napinać, ale należy robić po kawałku i budować produkt po kawałku, oczywiście nie do końća wiadomo co się dostanie finalnie, czy to będzie fajne czy nie fajne, ryzyko zbłądzenia jest duże, ale przynajmniej wiadomo, że robi się to co się dało zrobić i zaczyna się prace ASAP, a nie po 5-10 miesiącach ciężkich analiz bez developmentu, gdzie czas zwrotu z winwestycji oddala się nieubłagalnie. Łatwiej jest też rozwijać w SCRUM jeden produkt, a nie kilka, no i podejście hybrydowe też nie działa – tzn. robimy projekt SCRUM, a wszystkie zmiany potrzebne do okoła poza SCRUM.
Dzięki za Twoje komentarze, do niektórych z nich się odniosłem:
Moim zdaniem, pierwszą rzeczą, jaką SM powinien zrobić w takiej sytuacji jest odpowiedzenie sobie na – cyt. klasyka – jedno, ale to zaj.biście ważne pytanie – czy organizacja, która taką decyzję podjęła rzeczywiście wie, co znaczy SCRUM, Agile i czy jest do takiej pracy przygotowana.
Pod całym tym akapitem w pełni się podpisuję!
Może tylko z jedną małą uwagą: często jest tak, że organizacja jest zainteresowana zmianą, ale boi się opuścić bezpieczną strefę komfortu. Z jednej strony jest komunikat „zmieniaj rzeczywistość, bo potrzebujemy robić więcej/szybciej/lepiej”, a z drugiej strony jest bardzo mocne przywiązanie do stosowanych metod. Wtedy mamy jeszcze jeden wymiar pracy SM – pracę z organizacją i przekonywanie, że rezygnowanie z pewnych przyzwyczajeń może przynieść benefity. I być może jest to jeden z najtrudniejszych wymiarów pracy…
Jeżeli zespół nie ma żadnego doświadczenia z Agilem (a o takiej sytuacji wspominasz kilka linijek poniżej cytowanego przeze mnie fragmentu), to moim zdaniem “dzień zero” to trochę za późno na edukację. Czy nie lepiej wziąć zespół na mały “team building” przed rozpoczęciem projektu i wtedy zaznajomić ich z podstawami przy piwku i grillu?
Jeżeli tylko jest to możliwe – to dobrze jest zrobić edukację wcześniej. Natomiast czasami bywa tak, że zespół zjeżdża się dopiero w „dniu zero”, wcześniej nie ma możliwości zebrania go w jednym miejscu. Natomiast zamiast edukacji przy piwku zdecydowanie preferuję edukację przy klockach LEGO – http://www.lego4scrum.com/
To co, QM podzielił zespół na część lepszą i gorszą? Jednych lubie i uważam, że się znają, więc zaproszę na spotkanie a innych można olać? I SM się na to zgodził?!
SM nie jest strażnikiem kalendarzy zespołu – bywa że niezależnie od bieżących zadań ludzie są zapraszani na różne spotkania (które są ważne i sensowne). A między nimi może się też zdarzyć destrukcyjne. I czasami bywa tak, że trzeba reagować post factum…
Na pytanie jaki jest mój SM niestety odpowiedzieć nie mogę, bo sam pełnię tę rolę. W swojej pracy staram się dbać o zespół, by pracowało im się jak najlepiej. Mam to szczęście, że Zespoły z którymi do tej pory pracowałem, to wspaniali ludzie
Mam takie prywatne doświadczenie, że dobre zespoły i dobrzy SM przyciągają się :-)
A jaki jest Twój Scrum Master?
Niestety nie pracuję w SCRUM, ale jeżeli bym pracował, to chciałbym, żeby mój SM był taki, żeby wogóle nie było czuć jego obecności i potrzeby jego istnienia.
Niestety nie pracuję w SCRUM, ale jeżeli bym pracował, to chciałbym, żeby mój SM był taki, żeby wogóle nie było czuć jego obecności i potrzeby jego istnienia.
W sytuacji, w której zespół pracuje efektywnie i nie ma żadnych przeszkód – to tak właśnie powinno być. Scrum Master jest trochę rolą samoeliminującą się – jeżeli wszystko jest OK, to powinien być jak najmniej widoczny.
Ale jeżeli występują jakieś dysfunkcje, czy to wewnątrz zespołu, czy to w jego otoczeniu – to wówczas Scrum Master powinien zrobić wszystko, żeby je usunąć. I wtedy czasami jest bardzo widoczny, bo zdarza mu się burzyć święty spokój zespołu albo organizacji…
Dzień dobry!
Poszukuję doświadczonego specjalisty na stanowisko Scrum Mastera do Gliwic – stawka od 12 000 PLN.
Osoby, które chciałby poznac szczegóły zachęcam do kontaktu na adres e-mail: katarzyna.wagner@connectis.pl
Pozdrawiam serdecznie
Katarzyna Wagner