Tylko krowa nie zmienia zdania. Dzisiejszy tekst „odwołuje” wiele dotychczasowych materiałów. Wiele godzin i rozmów doprowadziło do zmiany zdania na temat kluczowego ostatnimi czasy pytania: „Na czym musi znać się Scrum Master?”
Czy Scrum Master musi być techniczny?
Przeglądając czeluści Internetu, można znaleźć wiele materiałów niżej podpisanego, w których jak wół stoi, że „posiadanie technicznej wiedzy nie przeszkadza Scrum Masterowi, ale z tym czy pomaga, może być już różnie”. W ostatnich miesiącach coraz bardziej krytycznie zacząłem patrzeć na model Scrum Mastera, który zajmuje się głównie procesem scrumowym i sytuacją w zespole/miękkimi tematami, jak chociażby te związane z konfliktami.
Dużo czasu spędziłem rozmyślając i rozmawiając, bo szukałem konkretnych powodów, dla których moje przekonania w tym temacie się zmieniły. Wydaje mi się że zidentyfikowałem pierwotne źródło – zmienił się bowiem powszechnie stosowany model Scrum Mastera. Nasz „wzorzec Sèvres SM-a” wygląda inaczej, niż było to jakiś czas temu.
Kiedyś SM-i pochodzili z zespołów i były to osoby które pracowały w Scrum Team w różnych rolach. Byli to analitycy, programiści, testerzy i tak dalej. Te osoby charakteryzowały się tym, że nie mogły usiedzieć w spokoju, gdy widziały że coś można byłoby zrobić lepiej. A to zarządzanie backlogiem, proces wdrożenia czy jakieś usprawnienia związane z wydarzeniami Scrum bądź nawet Jirą. Te osoby posiadały wiedzę techniczną, ponieważ aktywnie uczestniczyły w procesie wytwarzania oprogramowania. Miały pojęcie o środowiskach, o wersjach, używanych technologiach, wymaganiach, itd. Często miały także wiedzę merytoryczną – o samym produkcie i biznesie. Kiedyś to był po prostu standard.
Nowy Model Scrum Mastera
Czasy się zmieniają i od wielu lat mamy do czynienia z „zawodowymi Scrum Masterami„, którzy wybrali taką ścieżkę kariery. Bardzo często te osoby przebranżowiły się na SM-a i tak naprawdę nie mają pojęcia o IT czy wytwarzaniu oprogramowania. Wydaje mi się, że wzięło się to stąd, że wiele propozycji szkoleniowych oraz materiałów adresowane było do „starych” technicznych Scrum Masterów. To znaczy te propozycje skupiały się na samym Scrumie, procesie scrumowym oraz umiejętnościach miękkich takich jak budowanie zespołów, rozwiązywanie konfliktów, coaching i facylitacja.
Osoby, które szukały wejścia do IT bądź natrafiały na materiały o Scrum Masterach, widziały tylko i wyłącznie informacje o umiejętnościach miękkich i konieczności znajomości metodyki. W propozycjach kierowanych do SM-ów nie było nic o samym wytwarzaniu oprogramowania, bo niemym założeniem było to, że pochodzą oni z zespołów i znają to od podszewki.
Niestety, teraz mamy do czynienia z zawodowymi SM-ami, którzy ewidentnie potrzebują wzmocnienia wiedzy technicznej. #białko niezawodnie planuje odpowiedzieć na te potrzeby, na razie głosząc dobrą nowinę. Więcej informacji – wkrótce.
Na czym musi znać się Scrum Master?
Tydzień temu na naszej liście mailingowej przesłałem opis roli Scrum Mastera, nazywając go inżynierem produkcji oprogramowania. Oczywiście jest to analogia do inżyniera produkcji, który działa w fabrykach i na liniach produkcyjnych. Jeżeli ominęła Cię ta wiadomość, koniecznie zapisz się na listę mailingową i w odpowiedzi na wiadomość powitalną wyślij prośbę o przesłanie tego tekstu. Tutaj pozwolę sobie pójść dalej z wnioskami i odpowiedzieć na pytanie „Na czym musi znać się Scrum Master?”
Osobiście widzę cztery główne nogi, na których twardo powinien stać każdy SM. Są to, w losowej kolejności: wiedza o biznesie lub wytwarzanym produkcie, wiedza technologiczna o procesie wytwórczym, wiedza o wymaganiach i umiejętności pracowania z nimi oraz wiedza o Scrumie, procesie scrumowym, coachingu i facylitacji. Do tego niezmiennie potrzebne są odpowiednie cechy charakteru i umiejętności miękkie.
Praktyczna wiedza o produkcji
Zacznijmy od wiedzy o procesie wytwórczym. Nie wyobrażam sobie, jak można dbać o skuteczność i efektywność zespołu, nie wiedząc i nie rozumiejąc jak on pracuje. Kiedyś żartowałem, że dobry Scrum Master odnajdzie się zarówno w fabryce przetworów mięsnych, jak i w produkcji oprogramowania. To, czego nie mówiłem, bo miałem to w domyśle, to założenie pewnego sposobu działania. Dobry SM i jednym, i w drugim przypadku wejdzie w buty zespołu i albo własnymi rękami, albo przynajmniej patrząc na ręce innych, zrozumie co się dzieje na każdym etapie produkcji. Czy to rzeczonych przetworów, czy to programowania.
Idealnie byłoby, gdyby Scrum Master mógł przez jakiś czas podziałać wspólnie z zespołem i na przykład poprawić proste błędy albo wziąć udział w testach czy wdrożeniu. Albo wziął na warsztat jakieś wymaganie i odpowiednio je zgłębił, a następnie pracował z programistami tak, żeby zostało one zrealizowane. Scrum Master powinien mieć także dostęp do wszystkich narzędzi z których korzysta zespół. W tym także do repozytorium kodu, IDE, narzędzia do testów, serwerów aplikacji, i tak dalej, i tak dalej. Oczywiście, jeżeli dana osoba się na czymś nie zna, to niech to będzie dostęp „tylko do odczytu”. Ale absolutnym minimum jest to, żeby SM widział, jak inni pracują z wykorzystaniem tych narzędzi.
Czy wyobrażacie sobie inżynieria produkcji, które optymalizuje proces produkcyjny w fabryce, a jednocześnie nie ma pojęcia które maszyny do czego służą, jakie mają parametry i jak się obsługuje? Ja też nie i uważam, że nie powinniśmy się na to godzić wśród Scrum Masterów.
Wiedza o biznesie i wymaganiach
Druga gałąź wiedzy Scrum Mastera, to zrozumienie materii produktowej i/lub biznesowej. Jeżeli pracujemy w banku, to Scrum Master powinien mieć podstawową wiedzę o produktach bankowych. Jeżeli w ubezpieczeniach, to musi znać podstawowe ograniczenia i regulacje, a także sposób, w jaki firma ubezpieczeniowa w ogóle zarabia. Jeśli zaś zespół robi gry na komórki, to SM powinien cokolwiek wiedzieć o tym, jakiego rodzaju gry wytwarzamy, jak się w niej gra i dlaczego właściwie ludzie wybierają nasze rozwiązania, a nie czyjeś inne. Inaczej mówiąc, wiedza o tym, co stanowi wartość, jest niezbędna.
Oczywiście, Scrum Master nie będzie ekspertem, pewnie nawet nie stanie się analitykiem biznesowym, ale powinien móc uczestniczyć we wszystkich rozmowach o wymaganiach. W tym w refinemencie. Odważnie uważam też, że powinien móc się wypowiadać jako człowiek zespołu w trakcie wszystkich prac. Bo przecież jeżeli SM nie rozumie tematu i nie jest w stanie zidentyfikować, że jakieś wymaganie to oczywista bzdura, to jest to sytuacja daleka od optymalnej.
Wiedza potrzebna do zadawania właściwych pytań jest ułamkiem wiedzy eksperckiej. Ten ułamek Scrum Master powinien posiadać razem z pewnymi zdolnościami analitycznymi. Bo jak inaczej miałby wspierać Product Ownera w budowie wartościowego Backlogu Produktu? Jak może pokazać zespołowi efektywny refinement, jeżeli nie rozumie rzeczy które „refinementujemy”? Jak pokazać dobrze napisane User Story, skoro nie potrafi zapisać dobrych Kryteriów Akceptacji?
Wiedza o Scrumie
I dopiero tu dochodzimy do rzeczy, która jest oczywista dla wszystkich, a na którą być może wszyscy kładą zbyt duży nacisk. Wiedza o Scrumie. Scrum Master powinien być ekspertem od Scruma. To znaczy, że powinien być w stanie zaadresować wszystkie wątpliwości zespołu, wyjaśnić każdy aspekt działania procesu scrumowego, a jednocześnie umieć zaadresować wszystkie narzekania, że „u nas coś nie zadziała” albo że „to co proponuje Scrum Guide jest bez sensu”.
Dobry Scrum Master widzi różnice pomiędzy źle wdrożonym Scrumem, a źle zbudowanymi zespołami. W przypadku zespołów, które nie są zespołami, tylko luźno powiązaną ze sobą grupą osób, rolą Scrum Mastera jest działanie w kierunku budowy właściwych zespołów albo w kierunku wdrożenia zupełnie innego, nie-scrumowego podejścia. Żeby jednak potrafić to zauważyć, SM musi być ekspertem i wyrocznią w tematach scrumowych. Czy to na podstawie własnych doświadczeń, czy to na podstawie kursów i szkoleń, gdzie omawiane są dziesiątki/setki przypadków z życia, czy to wspierając się mentorem bądź agile coachem.
Ta ostatnia kwestia jest nie do przecenienia, ponieważ dobrze działający Scrum Team, umieszczony w odpowiednim dobrym środowisku, jest jedną z najbardziej efektywnych konstrukcji, jaką miałem okazję obserwować w życiu. Bardzo bym nie chciał pracować ze Scrum Masterem, który nigdy nie widział dobrze wdrożonego procesu scrumowego, albo zna go tylko ze Scrum Guide’a. Bo taki SM działa czysto teoretycznie, błądzi po omacku i uczy się tego razem z zespołem. Niestety, popełnia przy tym kolejne błędy bez gwarancji, że skuteczność i efektywność faktycznie zostanie osiągnięta.
Umiejętności miękkie i nie tylko
Na koniec zostaje ta paczka wiedzy i umiejętności, która spowodowała napływ zawodowych Scrum Masterów z zupełnie innych branż. To umiejętności miękkie, zarządzanie konfliktami, coaching facylitacja i wiele innych, bardzo niejasno zdefiniowanych odpowiedzialności.
„Techniczni” Scrum Masterzy z pochodzący z zespołów, na przykład analitycy, programiści czy testerzy, istotnie skupiali się na „technicznych” aspektach w procesie wytwórczym i samym Scrumie. Bardzo często brakowało im umiejętności miękkich. To spowodowało naturalną odpowiedź rynku, w postaci zatrzęsienia technik i narzędzi, które mają poprawić zgranie w zespole, współpracę i wzajemne zrozumienie. I to jest super! Ale samo to nie jest wystarczające do tego, żeby efektywnie optymalizować proces wytwarzania oprogramowania.
Ci „organiczni” Scrum Masterzy bardzo często posiadali bardzo dobre cechy charakteru, dzięki którym potrafili się świetnie odnaleźć w tej roli. Wsparci wiedzą techniczną byli i są nieocenioną pomocą na każdym etapie pracy scrumowej. Od spotkań z biznesem, przez Wydarzenia Scrum, aż po sytuacje kryzysowe.
Im więcej obszarów z powyższej listy pokryjemy, tym będziemy bardziej wartościowi dla koleżanek i kolegów z zespołu. Bo pamiętajmy, że Scrum Master jest częścią Scrum Teamu, a nie kimś kto stoi „nad” lub „obok”. SM gra w jednym zespole, do jednej bramki, ale na innej pozycji. Rozumie za to całość rozgrywki i wszystkie jej niuanse.
To właśnie takich Scrum Masterów nam trzeba! Artur nazwał ich ludźmi renesansu i trudno mi się z tym stwierdzeniem nie zgodzić. Dobry Scrum Master powinien posiadać bardzo rozległą wiedzę z bardzo odległych od siebie dziedzin. Na pewno nie jest to zawód, który można zdobyć po dwudniowym kursie.
Rola Scrum Mastera w zespole
Na szczęście, w ramach #białko przygotowujemy wiele różnych propozycji dla Scrum Masterów. Co więcej, nasze dotychczasowe warsztaty i szkolenia, oparte są praktyczną wiedzę zdobytą w dziesiątkach firm i w setkach zespołów. Nawet jeśli nie da się tego wszystkiego nauczyć na raz, to można wyposażyć się w solidne podstawy, które dalej można zgłębiać w Zespołach Scrumowych. Od zawsze budujemy świadomość i zrozumienie tej roli wśród uczestników naszych szkoleń i warsztatów.
Drodzy Scrum Masterzy, czy macie zainstalowane wszystkie narzędzia, jakie używa wasz zespół? Czy rozumiecie na czym zarabia produkt, którym opiekuje się Product Owner? Czy wiecie które wymagania są bardziej wartościowe, a które mniej? Czy w sytuacji kryzysowej jesteście w stanie podwinąć rękawy i zrealizować jakieś taski z bieżącego Sprintu? Jeżeli dziwią Was te pytania, to przed wami długa droga, którą należy rozpocząć jak najszybciej. Zanim zespół nie stwierdzi, że „Scrum Master tylko zmusza nas do Daily i Retro„.
Powiedzmy to sobie wprost: Wydarzenia Scrum to tylko 10-12% czasu zespołu, a często mniej. Wliczając przygotowania i opracowania, to Scrum Masterowi nie powinny one zajmować więcej niż 20% czasu! Pozostaje 80%, które powinniśmy spędzić razem w okopach z zespołem, budując zrozumienie odnośnie tego co wytwarzamy, w jaki sposób i po co. A jeśli zostanie nam trochę czasu, to wtedy warto podszkolić swoje umiejętności miękkie i wiedzę o Scrumie.
Jeżeli komuś się wydaje, że praca Scrum Mastera zajmuje tylko 4 godziny w tygodniu, to jest w ogromnym błędzie. Dojście do takiego stanu zajmuje lata i to przy stałych w zespołach oraz w organizacji, która rozumie podejście zwinne i daje zarówno zaufanie, jak i wsparcie we wszystkim czego potrzebujemy. Tego właśnie sobie i Wam serdecznie życzę.
