Scrum Master to agent zmian. Na czym polega jego praca?
Gdybym miał określić, czym zajmuje się Scrum Master, nazwałbym go agentem zmiany, prorokiem, który obwieszcza nowy paradygmat pracy. Jego celem jest odejście od podejścia zarządzania odgórnego, gdzie człowiek jawił się jako zasób w wielkiej inżynieryjnej machinerii. Promuje on wejście w nowy system, pełen życia, samoorganizacji, entuzjazmu, gdzie produkt jest wartością dla świata, manifestacją jestestwa jego twórców.
Zbigniew Jędrzejewski. Agile Coach/Scrum Master w Ericsson. Na co dzień wspiera jako Scrum Master dwa zespoły programistów, które tworzą środowisko testowe dla sieci telekomunikacyjnej. Przeprowadza również sesje team coachingowe, feedbackowe, retrospekcji projektowych dla innych zespołów w organizacji. Aktywnie wspiera innych Scrum Masterów, aby skutecznie, zgodnie z sobą mogli wypełniać swoją rolę. Jest akredytowanym coachem ICF oraz Scrum Masterem (PSM II).
Szkolenia scrumowe czy konferencje agile’owe zawsze napełniały mnie entuzjazmem i nie tylko mnie. Po nich chcieliśmy wszystko zmieniać, czuliśmy pewnego rodzaju bunt, niezgodę na chaos, na ten skostniały system w naszych organizacjach.
Po przyjściu do pracy, pełni werwy, pozytywnego nastawienia i co najważniejsze z głową pełną pomysłów, zaczynamy rozmawiać, dzielić się i próbować wdrożyć idee zwinności w naszych zespołach, w naszej organizacji. Lecz ku naszemu zaskoczeniu, nie jest to takie proste. Nasz entuzjazm nie jest podzielany, nasze argumenty zbijane, a dyskusje po pewnym czasie wyczerpują. Godzimy się na kompromisy w nadziei, że kiedyś spróbujemy z nowym podejściem, zrobimy eksperyment, zaobserwujemy, zbierzemy wnioski. I w praktyce do niczego znaczącego nie dochodzi, nie ma zmiany, o której marzyliśmy.
Spis treści
Po trudach do celu
W mojej karierze było tak z wieloma modyfikacjami, które próbowałem w miękki sposób wdrożyć w swoich zespołach. Jedną z przykładowych zmian był sposób estymowania. Chciałem, aby estymowano wielkość zadania, a nie ile zajmuje jego wykonanie. Niestety, kiedy wprowadziliśmy system punktowy, zespół przeliczał zadania na dni, np. 1 punkt oznaczał pół dnia, 2 – cały dzień, bo tak było prościej.
Tak samo było z rozbijaniem historyjek na mniejsze, czyli po naszemu – przeprowadzanie dobrej granulacji. Część dało się dobrze zgranulować, aby nie wychodziły poza sprint, ale zdarzały się historyjki, które okazywały się never-ending-story i nikt z zespołu nie miał ochoty porozbijać ich na mniejsze, bo uznano to za bezsensowne zadanie – wszyscy przecież wiedzieli, o co chodzi.
Podobnie rzecz miała się z programowaniem w parach, aby zwiększyć synergię w zespole oraz skupienie. Poświęciliśmy na to jeden sprint i na tym się skończyło. Marudzenie niektórych i sabotowanie pomysłu poskutkowało tym, że eksperyment nie przyniósł oczekiwanych rezultatów.
Do dziś jednak wierzę, że da się wprowadzić usprawnienia i to bez wyczerpujących dyskusji, debat, przepychanek słownych. To, że jesteśmy servant leaderami, nie oznacza, że trzeba robić wszystko na miękko, w coachingowym stylu, przedyskutować z każdym, aby zrozumiał, aby był zadowolony. Z takim podejściem czeka nas prędzej czy później wypalenie zawodowe.
Pamiętajmy, jesteśmy przywódcami, a przywódca zna kierunek, drogę i jego misją jest wprowadzanie innych do tego miejsca, w którym sam się znajduje. Zatem jeśli jesteś przekonany/przekonana do zmiany nie pytaj się innych o pozwolenie, po prostu ogłaszaj ją. Najlepiej w następujący sposób: robimy to i to…, ponieważ…
Praca u podstaw
Zaraz ktoś może zarzucić, czy to nie za ostre podejście, nie w stylu agile, gdzie wszystko trzeba przedyskutować i team musi się zgodzić na każdą zmianę. Zgadzam się, jest na to czas i miejsce. Podobnie jak pracownik, zespół jako całość ma swoje etapy rozwoju. Są zespoły dojrzałe, w których należy przedyskutować wprowadzenie nowej wersji, ale są też zespoły na początku swojej drogi agile’owej, gdzie takie dyskusje mijają się z celem. Na tym etapie potrzebna jest edukacja, ogłaszanie zmiany z silnym tłumaczeniem, dlaczego jest to ważne.
Przemawia do mnie model Kena Blancharta z przywództwa sytuacyjnego, który wyodrębnił cztery etapy rozwoju. Stosuję go do całego zespołu. Model ten pozwala określić poziom jego dojrzałości. I tak jak w przywództwie sytuacyjnym, w zależności od rozwoju zespołu przyjmuje różne strategie wprowadzania zmiany. Najprościej jest, kiedy zespół się tworzy i przechodzi tzw. fazę „forming”.
Obecnie jestem w takiej sytuacji: objąłem zespół, który zaczyna pracować w nowym obszarze. Przekładam to na entuzjastycznego debiutanta z modelu Kena Blancharta. Na tym etapie w żadnym wypadku nie pytam się o pozwolenie, jeśli chodzi o praktyki agile’owe. Ustawiam cały proces – daily, refinementy, przeglądy sprintów, estymacje, etc. I tutaj nie ma dyskusji, że czegoś nie robimy. Po prostu wchodzimy do gry i takie są zasady.
Dla zobrazowania procesu podaję przykład z estymowaniem. Wcześniej członkowie obecnie formującego się zespołu nie mieli dobrych nawyków w estymowaniu. Albo w ogóle tego nie robili, albo robili, ale przeliczali to na dni pracy nad zadaniem. Osobiście mam silne przekonanie do estymowania, ponieważ pozwala ono poznać prędkość dostarczania. To się przekłada na odpowiednie planowanie, a to z kolei pozwala product ownerowi dać informację klientowi, kiedy będzie miał swój wyczekiwany feature.
Zatem na refinemencie ogłosiłem, że estymujemy, a potem edukowałem, dlaczego jest to ważne. I po prostu zaczęliśmy estymować. Mam też świadomość, że w zespole są przeciwnicy estymowania, ale na tym się nie skupiam i nawet nie wchodzę z nimi w dyskusję. Szukam sprzymierzeńców, bo tak naprawdę, oni utrwalą zmianę w zespole.
Zatem scrum master jest nie tylko liderem, prowadzącym zespół do przodu, ale także nauczycielem, który nie pozwala mu potknąć się o własne nogi. Musi skrupulatnie analizować, jacy są członkowie zespołu, jak podchodzić do nich indywidualnie i jak pomagać im się rozwijać. Nierzadko zdarza się, że wymaga to pracy u podstaw, ale jak już zaczniemy wdrażać ten karkołomny proces, to później przychodzi tylko satysfakcja.
Zespół gotowy na zmiany
Zaobserwowałem, że kiedy zespół jest na etapie forming, czyli entuzjastycznego debiutanta, to jest otwarty na modyfikacje. Jest to dla Scrum Masterów okno czasowe, którego nie należy przegapić. Wykorzystajmy ten czas na wprowadzenie jak największej liczby zmian, do których jesteśmy przekonani na zasadzie ogłaszania – robimy to i to, ponieważ…
Jeśli przegapimy ten moment, a zespół przejdzie ten etap i stanie się rozczarowanym adeptem. To mocno utrudni nam pracę. Będzie miał swoje nawyki i trudniej będzie je zmienić. Ale również na tym etapie ogłaszamy zmianę na zasadzie – robimy to i to, ponieważ.
Dopiero później odchodzimy od dyrektywnego stylu prowadzenia zespołu. Dopiero wtedy kiedy zespół już jakiś czas praktykuje zwinność, nabywa doświadczenia, zaczyna poznawać korzyści, jakie płyną ze stosowania praktyk agile’owych oraz poznał konsekwencje odchodzenia od nich. Wtedy można powiedzieć, że Scrum Master wprowadził swój zespół w to miejsce, w którym sam się znajdował. Dalej już zarówno zespół, jak i Scrum Master idą ramię w ramię, wzajemnie się wspierają, odkrywają nową drogę. Kolejne są wspólnie dyskutowane, razem odkrywają, co jest najlepsze dla nich wszystkich oraz całej organizacji.
Zatem Scrum Masterzy, nie zapominajmy, że jesteśmy liderami, a lider prowadzi do miejsca, w którym sam się znajduje. Jako agenci zmiany, nie bójmy się ich ogłaszać. Szczególnie jeśli sami jesteśmy do nich przekonani.
Zdjęcie główne artykułu pochodzi z unsplash.com.