Do napisania posta na ten temat skłoniła mnie dyskusja z ostatnich tygodni w której uczesniczyłem. Plus, dyskusje na temat “Scrum Master zewnętrzny czy wewnętrzny” co jakiś czas pojawiają się w przestrzeni. Pewnie jest to rozważane częściej wśród managementu – czy naprawdę takiej roli (tak, wiem, odpowiedzialności 😉 ) nie może pełnić ktoś z zespołu? W domyśle – bo byłoby taniej, prawda?.
Jest to wątpliwość ekonomiczna jak najbardziej uzasadniona. Zwłaszcza jeśli tenże management (do spółki z ekspercko szacując ^^ co najmniej połową Developerów) styczności ze Scrum Masterami nie miał. Lub co gorsza – napotykał na swojej drodze więcej Scrum Masterów hub niż katalizatorów. Wówczas nietrudno wyobrazić sobie, że efekty pracy tychże Scrum Masterów postrzegają w ograniczonym zakresie i oceniają, no cóż – oględnie mówiąc – chłodno.
Z drugiej strony, management który doświadczył dobrodziejstwa Scrum Mastera – katalizatora, będzie znacznie bardziej skłonny sięgnąć do portfela (firmy ^^) i wysupłać z kiesy budżet. Bo wie, że Scrum Master realnie zdejmuje z niego część obowiązków. i w dodatku (a może przede wszystkim) faktycznie poprawia efektywność zespołu i organizacji jest doskonałym motywatorem do wydawania kasy 🙂
A i zespół, który miał szczęście mieć dobrego Scrum Mastera nie będzie raczej protestował, a raczej przyklaśnie. W sumie to jest całkiem niezłym papierkiem lakmusowym dotyczącym jakości Scrum Mastera i tego jaką robotę robi.
Ale zanim przejdziemy do dalszego ciągu refleksji nad pytaniem “Scrum Master zewnętrzny czy wewnętrzny?” proponuję cofnąć się o krok i zastanowić nad fundamentalnym pytaniem:
Czy to akurat musi być Scrum Master? Nie może być ktoś inny?
Ano może! I pewnie powinien 🙂 i czasem nawet to jest ktoś inny (i fajnie to działa). Może to być świetny lider a.k.a menedżer liniowy. Lider który szczerze i otwarcie mówi “chcę, żeby ludzie w naszej firmie wychodzili ze strefy komfortu i szukali nowych rozwiązań”. Albo “moi ludzie mają eksperymentować, popełniać błędy i uczyć się na nich”. Czasem jest to elastyczny Project Manager z ludzką twarzą, a gdzie indziej – empatyczny Product Manager. Innym razem – ktoś z Operational Excellence, doceniający ciągłą adaptację i uczący eliminacji marnotrawstwa w procesie. Ale z moich obserwacji wynika, że częściej taki ktoś jednak nie jest niż jest.
Bo taki lider to jest urobiony po uszy i przygnieciony rzeczami administracyjnymi (urlopy, timesheety, itp.). A poza tym to ma jeszcze swoje projekty i np. 25 developerów do ogarnięcia. Ten PM to jednak głównie pyta o status i wylicza BCWP 😉 (Budgeted Cost of Work Performed) między jednym mailem eskalacyjnym a drugim, a jego klawiatura wygląd tak 😉
Product Manager bardziej dba o zalewanie klientów ficzerami , a OE o wskaźniki LEANowe i procentowe oszczędności procesowe.
A zespoły (a także organizacja) są zostawione same sobie. I same sobie są. I robią po swojemu, najczęściej jak umieją najlepiej. Czasami to “najlepiej” wystarczy na “dobrze”, “poprawnie” lub “możę być”, a czasami nawet na to nie.
To skąd ten Scrum Master?
I tu cofamy się o kilka dekad, do początków zwinności gdzie Scruma i Scrum Masterów nie było. zdarzały się projekty, które mimo całej masy nieudanych stanowiły chlubne wyjątki.
I pewne ich elementy zaobserwowane także w innych udanych projektach (i jednocześnie – niewidziane w tych położonych) sprawiły, że ktoś zaczął kombinować, że w tym szaleństwie jest metoda. Na początku na czuja. Gdzie ten czuj musiał być całkiem spoko, skoro w pewnym momencie zaczęło wykształcać podejście zwinne. A następnie pojawił się Manifest Zwinnego rozwoju oprogramowania (Agile Manifestęo) i cytat:
We are uncovering better ways of developing
software by doing it and helping others do it.
Czyli generalnie – bierz co działa i dziel się tym z innymi, żeby i u nich zadziałało. To jako efekt tego, że coś gdzieś częściej działało niż nie, że ktoś przekuł to w Scrum. A w Scrumie którym ostatecznie pojawił się Scrum Master. Czyli jednak nie po to, żeby ciągnąć budżet z organizacji 😉
Na przestrzeni czasu pryncypia zwinności pozostały niezmienne, natomiast Metodyki, metodologie, frameworki (w tym Scrum) i systemy ewoluowały. Taki Scrum, jak przyznają jego twórcy – jest coraz mniej i mniej preskryptywny. I ma ogólne zasady (ramy ^^), pozostawiając dowolność w wypełnieniu ich treścią 🙂
I tak jeszcze kilka lat temu Scrum Master było ROLĄ w zespole, która ze swojej natury powinna być wewnętrzna i ciężko było sobie wyobrazić (przynajmniej mainstreamowi tych od zwinności), że może być inaczej. Ja też tak uważałem – że Scrum Master i Developer to tak trochę próba połączenia dwóch elementów, które mają dość rozbieżne cele. I w sytuacji konfliktu ról, pojawią się wątpliwości, którą z nich ma wybrać taka hybryda. Teraz już wiem, ale to temat na inny wpis.
Widziałem zespoły, w których dedykowany Scrum Master, zwłaszcza z pewnym poziomem wiedzy i doświadczenia robił lepszą robotę niż cały zastęp Developerów z dodatkowymi funkcjami Scrum Mastera. W dodatku najczęściej te dodatkowe funkcje były bardziej w stylu “przynieś / wynieś / pozamiataj”, przez co z ludzi w zespole też wielu chętnych nie było. Mało tego , czasem prowadziło do roli rotacyjnego Scrum Mastera, żeby żaden z Developerów nie musiał “cierpieć” w nieskończoność.
Fajne, efektywne kosztowo, ale nie działa. Tzn. raczej nie. Może działać, ale kiedy – to o tym niżej.
Wszystko w jednym?
Aktualnie Scrum Guide trzyma się wykładni, że Scrum Master (jak i pozostałe dotychczas “role”) to ODPOWIEDZIALNOŚĆ (Accountability). Więc można pełnić rolę Developera, PO czy SMa nie mając dedykowanej roli. Jak się uprzemy (a właściwie raczej, widzimy wartość – można pełnić jednoosobowo wszystkie trzy odpowiedzialności. Tutaj dzięki dla Rafałą Markowicza za bardzo dobrą dyskusję merytoryczną w temacie która pewne zakładki mi pootwierała.
Nooo, marzenie ludzi trzymających budżet, jak już zagaiłem na wstępie. Ale jakby to było takie proste, to by było proste 😉 a nie jest.
Na pytanie – Scrum Master – zewnętrzny czy wewnętrzny, co lepsze – bez znajomości kontekstu powiem domyślnie – zewnętrzny. Już słyszę jęk zawodu po stronie managerskiej, ale cierpliwości – im dalej w las, tym więcej drzew. Więc może nie być tak łatwo i wskazówka odchyli się odrobinę w stronę “to zależy”.
“Od czego to zależy?” zapytacie.
Pierwszą kwestią jest to, gdzie zespół i organizacja jest teraz, aktualnie, dziś.
Czy to organizacja nietknięta zwinnością, do której chęć Agile przyniósł prezes, bo grając w golfa usłyszał że inne firmy to mają? I on też chce mieć Agile? Wówczas będzie raczej jak na poniższym memie.
Ponieważ zgodnie z przytaczaną w poprzednim wpisie I Zasadą Dynamiki Newtona (która jak widać, dość dobrze opisuje organizacyjną rzeczywistość ;)) oczekiwanie samorzutnej zmiany od organizacji “bo ja tak chcę” raczej się nie wydarzy.
Jest tak, bo zawsze tak było. (I zawsze tak będzie).
Nawet jeśli ktoś otrzyma rolę Scrum Mastera. Ktoś inny – Produce Ownera, a wszystkich programistów, testerów i analityków przemianuje się na Developerów. Pół biedy jeśli będzie to mniej więcej w ramach pełnionego zakresu obowiązków. Wtedy i tak każdy będzie robił to co robił dotychczas, otrzymując mniej więcej efekty, jakie otrzymywał dotychczas. Jeśli będzie to coś dodatkowego, to się nic nie zadzieje (“bo edżajl edżajlem, ale prawdziwa robota czeka”)
Dlaczego? Ponieważ zgodnie z prawami zachowania organizacyjnego Craiga Lahrmana, zmienią się tylko etykietki – nazwy spotkań, nazwy ról – a wszystko pod spodem (w tzw. backendzie) zostanie po staremu. Tylko wszyscy będą narzekali na ten Agile, czy tego Scruma-Sruma, pracując w czymś co obok Scruma, czy szerzej nawet – Agile, nawet nie leżało.
Znacznie lepiej wpuścić do takiej organizacji Scrum Mastera zewnętrznego. Będzie miałwiększy lub mniejszy bagaż wiedzy i doświadczeń. I z tej perspektywy zacznie słuchać i obserwować. I na tej podstawie uczyć, pokazywać, wypracowywać. Zarówno na górze organizacji, w warstwie managerskiej, jak i na dole, w warstwie operacyjnej. Oczywiście mając mandat i wsparcie najwyżej położonych organów decyzyjnych. Dzięki temu proces uczenia będzie możliwie krótki (co nie znaczy BARDZO krótki). Bo pewne rzeczy najzwyczajniej na świecie muszą w zespole (i organizacji!) “siąść” lub wykiełkować, nawet jak Scrum Master pozwoli zespołowi popełnić błędy i nauczyć się na nich 🙂
Jest jak jest, ale może być lepiej. (Niemniej trzeba to sprawdzić).
Nie wykluczam sytuacji, w której potrzeba zmiany zmiany w organizacji jest, i buzuje pod powierzchnią lub poza zasięgiem wzroku czekając na impuls (CEO wracającego z golfa z Agile na ustach), jednak szansa na to jest raczej ograniczona 🙂 zresztą, niekoniecznie jest to świadoma potrzeba transformacji zwinnej.
Zatem to wciąż nie jest idealny/dobry moment na przyspieszone przebranżawianie któregoś z Developerów (najczęściej) na Scrum Mastera. Efekt katalizatora zmian podejrzewam, że jeżeli w ogóle będzie, hmmm, to jakby to powiedzieć, będzie OGRANICZONY. Bo fajnie, że mamy Scrum Mastera, który pewnie dostał nową fuchę bo wyciągnął najkrótszą zapałkę, lub został “chińskim ochotnikiem”, ale brak zrozumienia i czucia tematu może być sporą przeszkodą.
Lepsza sytuacja jest, gdy w zespole wśród Developerów (najczęściej) pojawia się ktoś, u kogo “w poprzedniej firmie Agile działał” i wewnętrznie zaczyna postulować, lub nawet wprowadzać zmiany, na wzór tych które dobrze wspomina jako efektywne i przynoszące dodatni zwrot z inwestycji.
Tutaj taka osoba (lub osoby) mają szansę wypączkować w kierunku Scrum Mastera (nie zawsze świadomie). Plus jest taki, że będzie się to działo organicznie, z uwzględnieniem kontekstu i przy użyciu empirycznej kontroli procesu.
Działa – zostaje. Nie działa – zmieniamy. Potencjalne minusy widzę dwa.
Bo chodzi o to, żeby plusy nie przesłoniły nam minusów
Tempo zmian – tutaj może być znacznie więcej błądzenia po omacku, więc ewentualne zmiany mogą zachodzić wolniej – bo mamy tu klasyczną sytuację wymyślania koła na nowo.
Głębokość zmian – zmiany które zajdą, mogą być znacznie płytsze niż potencjał na zmiany w organizacji, a zespół może zaadaptować niektóre praktyki w ramach poprawy sytuacji bieżącej, i po osiągnięciu pewnego poziomu poprawy uznać, że osiągnięty rezultat jest wystarczający i zaprzestać dalszej pętli inspekcji i adaptacji.
Tutaj wciąż Scrum Master zewnętrzny (oczywiście dobry!) to duże ułatwienie – wskazuje kierunki i pokazuje, jak daleko od nich jeszcze jesteśmy, ale i pokazuje drogę, którą udało mu się już przejść. Dodatkowo może wziąć pod skrzydła, w ramach mentoringu naszych pączkujących Scrum Masterów wewnętrznych, pokazując dodatkowe możliwości, metody, techniki, przyspieszając ich rozwój. Same plusy. Idąc dalej, przesuwamy się w górę dojrzałości zwinnej organizacji.
Robi się ciepło, coraz cieplej…
Organizacja jest dojrzała, działa w Agile i ma na tym polu doświadczenie, natomiast zespół jest nowy, niedojrzały, niedoświadczony. Tutaj mamy do czynienia z sytuacją nowego renifera w zaprzęgu Św. Mikołaja. ^^ presja i nawyki grupy (pozytywne!) mogą trzymać w ryzach i nadawać kierunek zespołowi. I to plus. Minusem jest to, że może się to odbyć bez odpowiedniego zrozumienia DLACZEGO tak się dzieje. Czyli możemy mieć punktowy kult cargo, działający poprawnie, dopóki wszystko jest ok, ale jak się coś sypnie – ryzykujemy, że okaże się, że król jest nagi.
Wówczas wciąż lepiej w takim zespole będzie jak Scrum Master będzie doświadczony, żeby pokazał doświadczenia i opowiedział o drodze, którą przeszła organizacja. W szkołach też nie uczymy się wymyślania koła na nowo, tylko korzystamy z wiedzy i zdobyczy innych pokoleń, nadbudowując na tym, co wymyślili ci, którzy byli przed nami. W zwinności można, i według mnie – powinno robić się tak samo 🙂
Jackpot, czyli “nie potrzebujemy już Scrum Mastera”.
W dwóch słowach – “DOJRZAŁY. ZESPÓŁ”.
To jest ten moment, kiedy obecność w zespole zewnętrznego Scrum Mastera jako osobnej roli staje pod znakiem zapytania, przynajmniej według mnie 🙂
Bo wyobraźmy sobie, że mamy zespół, który wie, po co jest w organizacji (zna i rozumie jej misję i wizję), jakie cele przed nim stoją (CELE, a nie hałda zadań w tzw. “backlogu” składającym się z 2000 elementów), jak te cele mapują się na misję i wizję. Zespół, który zna swoje mocne i słabe punkty, który nauczył się ze sobą pracować.
Taki zespół, który rozumie wagę empirycznej kontroli procesu, który wie na czym polega inspekcja i adaptacja, który wie, że transparencja to ich pierwszy krok, który rozumie z czego wynikają i jak działają na jego korzyść pryncypia zwinności, jak na co dzień stosować wartości scrumowe, jak podchodzić do planowania uwzględniając ryzyko, co dają i jak powinny wyglądać dobre i skuteczne miary, który rozumie znaczenie myślenia systemowego.
Zespół, który nie tłucze co Sprint tych samych trzech kolumn na retro. I w dodatku ma retro, którego efektem są realne usprawnienia, a nie marudzenie na wolne wifi i konieczność wizyt w biurze raz na miesiąc.
Jeśli mamy taki zespół, to po co mu (zewnętrzny) Scrum Master? 🙂 Ta ODPOWIEDZIALNOŚĆ (tak, tutaj jest dobre miejsce, żeby przypomnieć to słowo) może zostać przekazana w ręce jednej osoby, może też rozłożyć się na większą liczbę członków zespołu. Ba, jeśli w tym zespole jest/był dobry Scrum Master, to prawdopodobnie ten proces już się dzieje. Bo właściwie dlaczego nie? 🙂
Trzeba poeksperymentować, do czego zakładam taki fajny, dojrzały zespół będzie zdolny i chętny, mając w świadomości, ile już udało mu się osiągnąć i ile potencjalnie ma jeszcze do ugrania.
To możemy gasić światło? Możemy, pytanie czy chcemy 😉
No, bo jak tak się zastanowić, to nawet jak mamy same zgrane, doświadczone zespoły, to taki dobry, zewnętrzny Scrum Master (czasem w wersji przemianowanej na Agile Coacha) wciąż jest przydatny – tylko już w innej formie i na innym poziomie. I dla znacznie większej liczby zespołów niż zazwyczaj (o ile “zazwyczaj” to maksymalnie 2-3 niedojrzałe lub średnio dojrzałe zespoły, a nie patologiczne 4-5+ ;)).
A to więcej czasu spędzi na poziomie organizacji, odkrywając przed nią tajniki zwinności, a to pomoże w doborze i wdrożeniu miar (nie metryk ^^). A to pomoże pomóc rozwiązać (sfacylitować) konflikt daleko wykraczający poza kompetencje zespołu (mimo, że doświadczonego), a to podpowie inne/lepsze/nowe metody na Retrospektywę, #hackinadaily, czy ogólnie podrzuci pomysły miejsc, gdzie zespół jeszcze nie spojrzał (a spojrzeć warto). I nie chodzi o to, żeby prowadzić nikogo za rączkę, tylko zaproponować obszary do samodzielnego zgłębienia.
Dodatkowo jeśli Scrum Master jest w na etapie na którym przyrost wartości w zespole z każdej kolejnej jednostki jego czasu jest coraz niższy, bo się uwidacznia zasada będąca parafrazą prawa malejącej użyteczności krańcowej), to warto poddać sytuację inspekcji i adaptacji. Zespół już dużo umie, dużo eksperymentuje sam, więc warto żeby nawet ten dobry Scrum Master katalizator nie zgnuśniał i nie stał się tłustym kotem, może trzeba poszukać nowych wyzwań.
I to wszystko zatacza krąg – niedoświadczony lub niedojrzały zespół warto “wyposażyć” w zewnętrznego Scrum Mastera, jak nabierze doświadczenia, można pomyśleć o stopniowym przekazywaniu odpowiedzialności i powtarzaniu tego wzorca.
Podsumowanie – TL;DR
Ja uważam, że odpowiedź na pytanie “Scrum Master zewnętrzny czy wewnętrzny?” (tzn. zewnętrzna ROLA, czy wewnętrzna ODPOWIEDZIALNOŚĆ), należy zacząć zależy według mnie od pytania (i uczciwej, a nie życzeniowej odpowiedzi) o dojrzałość zespołu.
W świeżym zespole, który jeszcze nie łapie i nie czuje tego tematu, lepiej jest wpuścić zewnętrznego Scrum Mastera, który zwiększy energię układu i zadziała jako katalizator. W dojrzałym zespole (takim, który zrozumiał i poczuł pryncypia, rozwinął się i nabrał cech samozarządzania i samoorganizacji) Scrum Master zewnętrzny może się wycofać, cedując część odpowiedzialności na członków zespołu (najczęściej Developerów), pozostając w cieniu, okazjonalnie służąc jako źródło inspiracji lub wsparcia przy ciężkich tematach. Albo zniknąć całkiem. Zależnie od tego, co Scrum Master i firma postanowią (a przede wszystkim – czego potrzebują).
Zatem kończę ten wpis, dziękuję za poświęcony czas i pozdrawiam serdecznie czytających 🙂
Marcin
1 comment