.st0{fill:#FFFFFF;}

Nieoczywiste obowiązki Scrum Mastera 

 16 listopada, 2021

Artur Komendatskyi

Co przychodzi wam na myśl, kiedy ktoś pyta o obowiązki Scrum Mastera? Czy jest to „prowadzenie wydarzeń Scrumowych” albo „pilnowanie zasad Scrum Guide”? Czy może „rozwiązywanie problemów zespołu”? Wymieniłem te trzy, bo, w moim doświadczeniu są to najbardziej rozpowszechnione odpowiedzi na to pytanie. Ośmielę się postawić tezę, że najważniejsze obowiązki tej roli są często przeoczone. Dlatego nazywam je „nieoczywistymi”.

 

Ostatnio poruszałem temat zarobków Scrum Masterów. Jeden z wniosków tamtego tekstu był taki: „Jeżeli ktoś uważa, że SM nie powinien zarabiać dużo, to zazwyczaj wywodzi się z tego, iż nie widzi wartości w tej roli.” To prawda, że wiele ludzi uważa, że SM to ktoś, kto przeprowadza Daily, Planowanie Sprintu i „zmusza ludzi do Retro”. Rozwijałem ten temat głębiej w tekście o Pseudo-Scrum Masterach. W rzeczywistości SM ma wiele innych, trudniejszych obowiązków, które potrafią być bardzo korzystne dla firmy. Spójrzmy zatem na te obowiązki.

 

Transformator organizacji

Zacznę od obowiązku, który w teorii powinien być oczywisty, choć w praktyce wcale tak nie jest. Dlaczego? Bo jeśli zajrzymy w Scrum Guide’a, znajdziemy tam wpis o tym, że Scrum Master służy trzem stronom: Developerom, Product Ownerowi oraz Organizacji!

W jaki sposób SM służy całej organizacji? Przez propagowanie podejścia zwinnego. Znaczy to, że SM wspiera transformację zwinną w firmie. Można to robić przez prowadzenie szkoleń i warsztatów, mentoring mniej doświadczonych Scrum Masterów albo udzielanie praktycznej pomocy innym zespołom.

Niestety, w praktyce często to wygląda jak prowadzenie jednego na pół roku warsztatu z klockami Lego. Jest to zabawne spędzanie czasu, ale nikomu nie pomaga. Żeby propagować Agile nie wystarczy powtarzać ludziom cytatów ze Scrum Guide’a. Pamiętajmy, że Scrum jest środkiem a nie celem. Celem jest komercyjny sukces naszych produktów. Zarówno Agile, jak i Srum jako jego implementacja, powstał, żeby wesprzeć osiągnięcie tego celu.

Waterfall przyniósł do branży tworzenia oprogramowania mnóstwo anty-wzorców, które przeszkadzają w tworzeniu wartościowych produktów, a są nadal bardzo rozpowszechnione. Na przykład:

  1. Developerzy ciągle „dowożą” feature’y, które są „prawie gotowe” („Przecież kod jest, trzeba tylko dodać testy i zdeployować!”), a potem muszą poświęcać czas na naprawianie bugów, które powstają przez taki tryb pracy.
  2. Czas marnuje się na niepotrzebnych spotkaniach, bo ktoś powiedział, że są obowiązkowe.
  3. Delievery Manager naobiecywał klientowi wszystko „na wczoraj” i teraz próbuje namówić Developerów do nieodpłatnych nadgodzin.

Myślę, że każdy czytelnik bez problemu potrafi przedłużyć tę listę. Scrum Master powinien pomóc tych anty-wzorców się pozbyć. W pierwszej kolejności – swojemu zespołowi, a potem – reszcie firmy. To właśnie jest propagowanie Agile.

 

Trener zespołu

Słowo trener od razu wywołuje skojarzenia ze sportem. Słusznie, bo rola trenera w stosunku do prowadzonego przez niego sportowca ma dużo wspólnego z tym, jak SM ma się do zespołu. Jeśli popatrzymy na przykład na boks, to zobaczymy, że trener nie wykonuje pracy sportowca za niego. Zawodnik musi sam wykonać pracę na worku czy gruszce refleksyjnej, sparingi, różne ćwiczenia dla kondycji, itp. Również trener nie wyjdzie zamiast niego walczyć w ringu – to też robi sam zawodnik. Od czego więc jest trener?

  1. Pomaga zawodnikowi odkryć mocne oraz słabe strony i dostosować do nich swój styl.
  2. Wybiera odpowiednią strategię przygotowywania do występów.
  3. Pomóc w radzeniu się sobie z emocjami, które powstają przy spotkaniu trudnego przeciwnika(albo porażki)

Często utalentowany sportowiec nie osiąga nic, bo podejmuje złe decyzje. Dobry trener jest przewodnikiem, który pomaga mu wybrać odpowiedni szlak. Nic dziwnego, że nierzadko wielu legendarnych sportowców dzieli między sobą tego samego trenera. Angelo Dundee wyszkolił 16 mistrzów świata (najbardziej znanym spośród nich jest Muhammed Ail), a Manny Stewart – aż 41 (m.in. Lennox Lewis, Wladimir Klitschko, Thomas Hearns)!

Potrafię mówić (i pisać) o swoim ulubionym sporcie zdecydowanie za dużo, także wracam do Agile. Możemy mieć najbardziej kompetentnych Developerów, a produkt i tak poniesie klęskę – czy to przez brak odpowiedniej wizji, czy przez niepotrzebne ulepszanie kodu w nieskończoność, czy przez coś jeszcze. Opisałem ten problem bardziej szczegółowo w postach o Developerach Zwinnych oraz o wartości oprogramowania.

Scrum Master jest trenerem zespołu pod tym względem, że pomaga zarówno Developerom, jak i Product Ownerowi osiągnąć potencjał jako zespół. SM prowadzi ich w kierunku, gdzie będą zostawać coraz to lepsi w dowożeniu oprogramowania o wysokiej wartości.

 

Motywator zespołu

Agile Manifesto twierdzi, że „najlepsze produkty są tworzone przez samozarządzające się zespoły o wysokim poziomie motywacji„. I tak wyszło, że większość zespołów nie ma tego poziomu, a wywodzi się to często ze wspomnianych wyżej anty-wzorców. Ludzie frustrują się, kiedy muszą wykonywać niepotrzebną według nich pracę i brać udział w niepotrzebnych według nich spotkaniach. Irytuje ich, gdy muszą godzić się z bezsensownymi zasadami organizacji, kiedy są kontrolowani przez managerów lub kiedy z ich opinią nikt się nie liczy. Nierzadko ludzie nawet nie zgłaszają problemów, bo nie wierzą, że da się coś zmienić.

Scrum Master jest zobowiązany do stworzenia środowiska zaufania, gdzie Developerzy i inni uczestnicy Scruma mogą otwarcie powiedzieć, kiedy coś im dolega. Musi też pokazać, że przeszkody da się pokonać, a niekorzystne procesy – zmienić. Musi zadbać o to, żeby nie było żadnego mikromanagementu i żeby zespół pracował jako drużyna specjalistów, w której każdy jest wartościowy. W taki sposób SM zwiększa motywację zespołu, a razem i jego efektywność.

 

Wieczny uczeń

Tego obowiązku nie ma w Scrum Guide, jednak empiryzm udowadnia, że jest bardzo ważny. Powtórzę jeszcze raz błędne postrzegania co do roli Scrum Mastera – osoba od wrzucania „ceremonii” w kalendarz i prowadzenia wydarzeń Scrumowych (sekretarka, administrator). Jeśli SM rzeczywiście Sprint po Sprincie robi co raz to samo, to jest to zły SM. Dlaczego? Nic się nie zmienia, bo zespół nie rozwija się. Czyli SM nie wykonuje swego obowiązku jako trener.

Jeśli SM jest dobry, jego zadania w konkretnym zespole muszą się zmieniać przynajmniej co parę sprintów. SM uczy zespół czegoś i potem oni sami to robią. Pomaga im rozwiązać jakiś problem – i tego problemu już nie ma. Zespół ewoluuje i napotyka na jakościowo nowe wyzwania i SM jest po to, żeby z tym pomagać. Analogicznie wygląda proces transformacji firmy – firma dojrzewa i jej problemy się zmieniają. Dlatego SM musi ciągle pracować nad własnym rozwojem zawodowym. Musi być jak minimum o krok dalej w dojrzałości zwinnej niż ludzie, z którymi pracuje, bo inaczej robi się niepotrzebny dla nich. Nie Scrum Master w ogóle, a ten jeden konkretny SM który przestał się rozwijać i teraz już nie ma nic do zaoferowania.

Artur Komendatskyi


6 lat doświadczenia w IT, PSM I-II, PAL I, starszy inżynier oprogramowania, Scrum Master zespołów zwinnych, Agile Leader

Your email address will not be published. Required fields are marked

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}