Scrum Master Turbo*

O roli Scrum Mastera, bardzo subiektywnie.

Nie przekonuje mnie koncepcja Scrum Mastera przedstawiona w Scrum Guide. Doceniam wagę tej roli, szanuję ideę samoorganizującego się zespołu, wiem jak ważna jest osoba pomagająca w implementacji Scruma, rozumiejąca go, pomagająca stosować jego mechanizmy, ale to i pozostałe obowiązki opisane w Scrum Guide, to zawsze było dla mnie za mało. Zawsze oczekiwałem, od siebie, od Scrum Mastera, od agile, czegoś więcej. Więcej dla zespołu deweloperskiego, więcej dla współpracujących z nim zespołów, więcej dla organizacji. Na pewno można do tego podejść lepiej.

Niedopowiedzenia są groźne

Uważam, że Scrum niesie ze sobą tyleż dobrego ile zagrożeń. Przez to, że charakter roli SMa jest zwięźle opisany, pozornie łatwy do zrozumienia, a bez wątpienia trudny do opanowania, kusi do stosowania skrótów, dając przy tym spore pole do interpretacji. Scrum Guide definiuje tę rolę, przede wszystkim, jako odpowiedzialną za to, żeby Scrum był rozumiany i stosowany. W kolejnym zdaniu dodaje, że realizujemy rolę SMa dbając o to, żeby Zespół Scrumowy stosował teorię, praktyki i zasady Scruma. Podkreślając postawę lidera służebnego, używając parokrotnie zwrotów coaching, wsparcie, pomoc, buduje u wielu z nas przekonanie, że celem i misją Scrum Mastera jest nauczanie Scruma w zespole i organizacji, a warsztat narzędziowy sprowadza się głównie do coachingu. W długiej perspektywie ma to być może szansę zadziałać, a przy dojrzałych, samoorganizujących się, bardzo kompetentnych i czujących odpowiedzialność zespołach deweloperskich, wierzę że taka rola, coacha, consigliere lub czujnego mentora, wspierającego nieco z boku, jest cenna. Kiedy jednak zespoły nie wypracowały jeszcze w sobie tych cech, brak mocnego, trzymającego rękę na pulsie i potrafiącego skutecznie zareagować lidera powoduje, że projekty stają się zagrożone. Zwłaszcza duże projekty, realizowane przez wiele zespołów. Inicjatywy o charakterze projektowym funkcjonują najczęściej pod presją czasu. W związku z czym cierpliwe budowanie dojrzałości, odpowiedzialności, a przy tym pozwalanie na uczenie się zespołów na własnych błędach, to często za mało by istotnie przyczynić się do ich sukcesu.

Skąd taka dziwna nazwa w tytule?

Mając w głowie swoją prywatną wizję, nowego lepszego SMa, zacząłem nazywać go kiedyś Scrum Masterem 2.0. Świetna nazwa. Od razu wywołuje powiew świeżości, nowoczesności, kojarząc się z dążeniem do perfekcji… szkoda tylko że zajęta. Na dodatek rozumiana inaczej niż bym sobie tego życzył. Dobre nazwy są ważne. Krystalizują przekaz. Budzą oczekiwane skojarzenia. Więc może Scrum Master 2.1? 3.0? Scrum Master Pro? Scrum Master Na Sterydach? Po chwili przyszła mi do głowy nazwa Scrum Master Turbo*. Może nie do końca oddaje ideę i z pewnością nigdzie się nie przyjmie, ale za każdym razem wywołuje u mnie uśmiech na twarzy ;]

Zapraszamy na szkolenie

Szkolenia SAFe Scrum Master

Czym zatem różni się Scrum Master Turbo od Scrum Mastera jakiego zna większość z nas?

Różnice o których piszę zgrupowałem w trzy obszary:

• odpowiedzialność
• warsztat narzędziowy
• skalowanie agile

Odpowiedzialność

Firmy sprzedające usługi programistyczne lubią przekonywać zamawiających, że warto im ufać. Coraz częściej podpisywane są tzw. zwinne umowy produkcji oprogramowania, gdzie mamy do czynienia z czymś pomiędzy umową o konkretne dzieło, a umową wynajmu pracowników. Czasem ładnie się to nazywa wynajmem zespołów. Bardzo często dochodzi do sytuacji, w której zamawiający stawiany jest w mało komfortowej sytuacji – nie może oczekiwać konkretnego efektu prac, bo projekt jest realizowany zwinnie, czyli bardziej precyzyjnie planowane są co najwyżej cele sprintów i zakresy, natomiast produkty etapowe, kamienie milowe i efekty końcowe są poza odpowiedzialnością wykonawcy. Nie może również kontrolować jakości pracy programistów, no bo przecież to wykonawca zarządza swoimi ludźmi. W skrajnie niefortunnie przygotowanych umowach zamawiający ma właściwie więcej twardo zdefiniowanych obowiązków (m.in. dostarczanie na czas wymagań, terminowe płacenie za … no właśnie, często po prostu za etaty) niż firma realizująca dla niego projekt (za produkty nie odpowiada, za poziom profesjonalizmu, rzetelność i terminowości prac również niekoniecznie, często niestety odpowiada po prostu za dostępność specjalistów). Opisane dysfunkcje są oczywiście skrajnością, ale jestem przekonany że niejeden czytelnik ma teraz twarz wykrzywioną w gorzkim uśmiechu zrozumienia.

W każdej sytuacji, w której mamy ograniczone możliwości rozliczania zespołów deweloperskich z dowożonych efektów prac nasze zaufanie do tak zwanej odpowiedzialności zbiorowej (a może raczej rozmytej) jest mocno ograniczone. Wtedy czujemy się dużo pewniej, jeśli możemy liczyć na to że w zespole jest lider, który ma duże poczucie odpowiedzialności, radar ustawiony na ryzyka i przejmuje inicjatywę jeśli widzi że zespół jest na kursie kolizyjnym, a nie widać przesłanek że sam sobie z tym poradzi. Nie czas wąchać róże, gdy płoną lasy. Przestrzeń na rozwój, naukę, możliwość popełniania błędów musi istnieć, ale priorytetem powinno być zawsze dowożenie celów projektów. W takiej sytuacji coaching to za mało, potrzebna jest trafna ocena sytuacji i działanie. Trudno oczekiwać od Scrum Mastera, że podejmie działania takie, jakie podjąłby Kierownik Projektu, bo nie ma zazwyczaj takiej siły sprawczej, ale może z kolei, i powinien, analizować, sygnalizować, przypominać, upominać, trąbić na alarm, a kiedy trzeba eskalować. Rzecz w tym, żeby w takich sytuacjach był bardziej “leader” niż “servant”, powinien działać wtedy, gdy inni udają że nie ma problemu, albo zamiatają go pod dywan.

Warsztat narzędziowy

Scrum Master Turbo musi być kimś więcej niż trenerem, coachem i konsultantem. Sukcesy realizowanych projektów będą mocno uzależnione od jego umiejętności facylitacji, zdolności komunikacyjnych, warsztatu analitycznego i znajomości narzędzi do zarządzania projektami/zadaniami. To on wspiera Product Ownera w definiowaniu wymagań i ich mapowaniu, to on pokazuje zespołowi, jak je dekomponować i jakich technikami szacować. Scrum Master jest odpowiedzialny za poprawność implementacji procesów i narzędzi, więc rzadko kiedy znajdzie się lepsza osoba, do wsparcia Product Ownera w pielęgnowaniu backlogu produktu. Prawdopodobnie nikt inny nie podniesie alarmu, kiedy w Jirze/Asanie/Redminie zrobi się bałagan. Do niego będzie też należało definiowanie i monitorowanie wskaźników. Scrum Masterzy, jakich każdy chciałby mieć w swoich zespołach muszą posiadać nie tylko wiedzę i doświadczenie, ale też sprawność w posługiwaniu się projektowym orężem. Podwijają rękaw i idą w ogień, kiedy zespoły załamują ręce przygniecione ilością danych w excelu, zawiłości map procesów, kiedy trzeba zmierzyć zjawiska pozornie niewymierne. Są mistrzami w używanych przez daną organizację narzędzi do zarządzania zadaniami – potrafią dostosować Redmine pod swój zespół, przez sen są w stanie pisać zapytania JQL, konfigurować workflow, atrybuty obiektów i konstruować dashboardy. Z nieludzką cierpliwością potrafią przedzierać się przez gąszcz zadań, historyjek, funkcjonalności, epików i zaprowadzać porządek tam, gdzie panuje chaos. Biorą markera w dłoń i podsumowują czytelnie spotkanie, podczas którego uczestnicy gubią się już w zawiłościach zależności i nie pamiętają po co przyszli.

W arsenale ma też narzędzia miękkie, działające w obszarze postaw, wartości, interakcji międzyludzkich, nimi też powinien sprawnie się posługiwać. Zarządzanie konfliktami, słuchanie ze zrozumieniem, facylitacja spotkań, o tych narzędziach Scrum Mastera nie możemy zapominać.

Skalowanie agile

Waga roli Scrum Mastera rośnie jeszcze bardziej, kiedy mamy do czynienia z agilem w skali. Gdy do poziomu zespołów dochodzi poziom programu, w którym mamy ograniczoną możliwość podejmowania działań synchronizacyjnych z bezpośrednim zaangażowaniem wszystkich zespołów w jednym czasie, kluczowej roli nabiera to, w jaki sposób zespoły reprezentowane są “na zewnątrz”. Żeby takie spotkania jak planowanie iteracji na poziomie programu, Scrum of Scrums, czy retrospektywy programu przynosiły realną wartość, Scrum Masterzy reprezentujący swoje zespoły w programie, ale też reprezentujące program na poziomie zespołów, muszą bardzo dobrze orientować się w bieżących pracach deweloperskich, ich postępach, efektach i problemach na jakie natrafiają. Muszą także sprawnie poruszać się w zagadnieniach programowych i produktowych, takich jak wizja całościowego rozwiązania, roadmapa rozwoju, harmonogram wdrożeń.

LeSS wyróżnia następujące obszary aktywności Scrum Mastera:

• zespół
• Product Owner
• organizacja
• praktyki deweloperskie

Scaled Agile Framework pokrywa te same obszary precyzując przy tym zakres obowiązków Scrum Mastera:

•wsparcie dla liderów lean-agile, pomoc we wdrażaniu podstawowych zasad zwinności i szczupłej produkcji i implementacja mechanizmów SAFe’a

• wsparcie w przestrzeganiu zasad obowiązujących zespoły, takich jak zwinne praktyki deweloperskie, np. wbudowana jakość
• facylitowanie postępów zespołu w realizacji postawionych celów, np. poprzez przedstawianie narzędzi i technik zwiększających przewidywalność, produktywność i zwinność
• wdrażanie w zespołach ciągłego doskonalenia
• facylitowanie spotkań, tych wewnętrznych zespołowych i programowych
• wsparcie dla Product Ownera w pracy z backlogiem i agilem
• usuwanie przeszkód blokujących zespół będących poza zasięgiem samego zespołu
• budowanie efektywności zespołu
• reprezentowanie zespołu w kontaktach z interesariuszami i jego ochrona przed niekontrolowanym zlecaniem prac
• koordynacja z innymi zespołami w ramach realizacji programu
• wsparcie estymowania, np. poprzez nauczanie technik i facylitowanie spotkań

To co zdecydowanie różni SAFe’a i LeSS’a w rozumieniu roli Scrum Mastera, to podejście do koordynacji – LeSS bardzo wyraźnie mówi “Nie koordynuj prac pomiędzy zespołami”, SAFe natomiast zachęca do tego. Bazując na własnych doświadczeniach i obserwacjach, bliższe mi podejście SAFe’owe, uważam że przy produkcji rozwiązań w dużej skali i występowaniu wielu zależności pomiędzy zespołami taka pomoc Scrum Mastera jest potrzebna. Zespół jest w stanie wiele ogarnąć we własnym zakresie na bazie współpracy deweloper-deweloper, ale przy złożonych rozwiązaniach lepiej jest częściowo ściągnąć im ten ciężar z barków i dać więcej przestrzeni na kodowanie. W SAFie tą koordynacją zajmuje się dodatkowo Release Train Engineer, taki Scrum Master Scrum Masterów, zwany też pieszczotliwie Uber Scrum Masterem… jest też zwany Wielkim Facylitatorem (przez nielicznych na szczęście ;] ).

Z własnego, wyskalowanego, podwórka

Najcenniejsze zachowania SMów angażujących się mocno w prace synchronizacyjne zespołu zespołów, jakie ja zaobserwowałem w mojej pracy z agilem w skali, to między innymi:

• bezpośrednia, mocna koordynacja prac paru zespołów, stanowiących część programu, ale realizujących grupę szczególnie powiązanych komponentów – mapowanie zależności, facylitacja wspólnych spotkań, wsparcie w synchronizacji backlogów, identyfikacja, monitorowanie i eskalacja kluczowych ryzyk;
• tworzenie i monitorowanie metryk programu
• tworzenie współdzielonych standardów i nadzór nad ich przestrzeganiem, nie tylko w ramach własnych zespołów

Podsumowując rolę Scrum Mastera w zwinnym zarządzaniu dużymi inicjatywami

Tak według mnie wygląda i zachowuje się Scrum Master, którego chcą mieć zespoły deweloperskie, ludzie odpowiedzialni za zarządzanie produktem, top management i cała organizacja. Taki, którego warto szukać na rynku i za którego warto płacić tyle, ile zazwyczaj słyszę w oczekiwaniach finansowych, na rozmowach rekrutacyjnych. Najfajniejsze w tym wszystkim jest z kolei to, że tacy SMowie istnieją i miałem już przyjemność pracować z takimi (i dalej mam) ;]

Oczywiście Scrum Guide nie zabrania nikomu posiadać te wszystkie kompetencje, realizować takie zadania i prezentować tego typu postawy, niemniej nie uważam, żeby tak widział tą rolę i zachęcał swoich odbiorców do działania w ten sposób. Na szczęście profesjonalni Scrum Masterzy przekraczają w swojej codziennej pracy granice poszczególnych frameworków i dobrych praktyk.

*Jeśli w kontekście nazwy tej roli słowo “Turbo” kojarzy Ci się z gumą Turbo, albo z Power Rangers Turbo, to hańba Ci. Jeśli natomiast bardziej kojarzy Ci się z wypalanymi synapsami i “Mona Lisa Turbo”… to jesteśmy w domu ;]