Czy Scrum Master powinien być techniczny?

Tak jak zwolennicy majonezu rozwodzą się nad wyższością jednej marki nad drugą [#teamkielecki] - tak samo temat "technicznego" Scrum Mastera budzi żywe emocje wśród agile'owców.

Zatem skąd biorą się takie rozważania? Po pierwsze zawód Scrum Mastera sprzedawany jest jako łatwa i prosta ścieżka do pracy w IT, gdzie zarabia się dobre pieniądze. I tutaj może być pies pogrzebany, bo nowi adepci dochodzą do wniosku, że jednak jest trudno stawiać swoje kroki w IT bez jakiejś podstawowej wiedzy. A może pracujesz już jakiś czas w tej roli i jednak nie bardzo rozumiesz, o czym zespół czasem rozmawia i nie umiesz im pomóc? Puff i pojawiła się mitologiczna postać "technicznego" Scrum Mastera.

---

Kim w ogóle jest techniczny Scrum Master?

No cóż, już tutaj zaczynają się schody, bo nikt w sumie tego nie zdefiniował.

Potocznie używa się tego stwierdzenia, by odróżnić Scrum Mastera, który zna "jakieś" aspekty techniczne, od takiego, któremu tej wiedzy brakuje.

I tutaj właśnie zaczynają się kontrowersje, bo czy Scrum Master faktycznie potrzebuje wiedzy technicznej, by być dobrym w swojej robocie?

Zacznijmy od tego co mówi Scrum Guide.

Otóż twórcy Scrum Guide są w tej kwestii neutralni jak Szwajcaria. W przewodniku nie znajdziemy ani jednego słowa bądź wskazówki naprowadzającej nas na odpowiedź w tej kwestii. Zatem można by wywnioskować, iż brak wiedzy technicznej to nie przeszkoda iże nie jest to wymóg do objęcia tego stanowiska.

Pragnę jednak zwrócić uwagę na istotny fakt, że twórcy Agile Manifesto i Scruma to jednak inżynierowie, programiści i testerzy. Możliwe, że skoro oni zapoczątkowali ruch, to jednak wiedza techniczna jest w cenie.

To finalnie Scrum Master musi czy nie musi być techniczny?

Mogłabym napisać, jak w szanującym się IT przystało: "To zależy.", ale tego nie zrobię ;). Oczywiście, jeśli nie pracujesz z zespołami IT, to rozumienie aspektów technicznych na nic Ci się przyda. Ewentualnie hobbistycznie ;), jak np. widzisz rozbieżności ceny 1 produktu w dwóch miejscach na ekranie kasy samoobsługowej w Biedronce [żarcik branżowy]. Aczkolwiek, w każdej pracy jest jakaś wiedza ekspercka i ta z pewnością Ci się przyda.

Skoro to już ustaliliśmy, to wróćmy na polankę IT. Każdy Scrum Master ma swój warsztat, lepiej bądź gorzej rozwinięty. Poprzez warsztat mam na myśli umiejętności miękkie, takie jak:

• techniki facylitacji spotkań,

• ogarnianie systemu ticketowego [Jira, MS Azure, ClickUp, itp.],

• dobra komunikacja,

• i wiele innych.

Prawda też jest taka, że i tak zaczniesz zdobywać podstawową wiedzę techniczną, gdy współpracujesz z zespołami IT. Drogą naturalną lub wymuszoną ;). Bo czasami, by skutecznie wykonywać swoją pracę musisz rozumieć jak wytwarza się oprogramowanie, jakie praktyki deweloperskie stosujecie w firmie/zespole, jak wygląda proces testowania oprogramowania i tak dalej.

Zatem zaryzykuję stwierdzenie — uważam, że Scrum Master powinien być "techniczny".

Każdy medal ma 2 strony.

A miało być tak pięknie :P. Posiadanie wiedzy technicznej może się okazać mieczem obusiecznym. Może ona przeszkadzać nam i zespołowi — jeśli na to pozwolimy.

Najważniejszą przestrogą jest (szczególnie dla osób, które w swoim poprzednim wcieleniu były programistami) by nie uczestniczyć aktywnie w pracach inżynierskich. Bądź nie mówić jak zbudować dane rozwiązanie, nad którym trudzi się zespół.

Wiedza ma nas wspomóc w pracy zespołem np. kiedy trzeba ich scoachować z zakresu:

• istoty refaktoringu kodu [proces poprawy istniejącego kodu],

• spłaty długu technicznego [zjawisko powodujące wysoki koszt utrzymania software'u],

• odpowiedzenia na pytanie czy prace techniczne [dla przykładu: podbicie frameworka do wyższej wersji] przyniosą użytkownikom lub biznesowi wartość.

Może się ona również przydać kiedy mamy dyskusję w zespole i pożądane jest byśmy:

• rozumieli, o czym zespół rozmawia,

• jakie są action pointy [akcje wynikowe],

• co należy zrobić, by usunąć przeszkodę na drodze zespołu i jest ona techniczna, ale niezależna od nich,

• podjąć ważne decyzje firmowe jak np. zmiana technologii.

Uderz w stół, a nożyce się odezwą.

Sami pewnie przyznacie, że słabo to wygląda, kiedy siedzicie na spotkaniu przez bitą godzinę i nic nie rozumiecie. Jeszcze gorzej, kiedy jest retro albo warsztaty i nie umiecie poprowadzić tego spotkania, bo nie rozumiecie, o czym zespół rozmawia. A jak już się odzywacie to zespół zdecydowanie myśli: "Co jest, kurde?". No, albo kiedy jesteście o coś proszeni i nie macie pojęcia, co macie zrobić i uderzacie na DM [direct message] do zaprzyjaźnionego deva po wytłumaczenie bądź instrukcję. No właśnie — jaką to nam Scrum Masterom wystawia wizytówkę? A potem się dziwimy, dlaczego tyle hejtu się leje w braci devowej na nas.

Ja wychodzę z założenia, że skoro oczekuję, że wszyscy w firmie, rozumieją moją rolę i jakie obowiązki do mnie należą — to programiści, testerzy i wszystkie inne zawody w IT oczekują tego samego. I niestety nie chodzi tutaj o utarte: "no dev kodzi, tester testuje", tylko o zrozumienie nie tylko co robią, ale też, jak i co ma z tym wspólnego technologia. To oczywiście nie oznacza, że zaraz, drogi Scrum Masterze, masz się uczyć programowania. Możesz, ale nie musisz ;). Umówmy się, i tak w dyskurs nie wejdziesz i nawet jeśli masz do tego odpowiednie kwalifikacje, to nie na tym ta rola polega.

Mam nadzieję, że widzisz, że jednak wiedza techniczna się przydaje w pracy Scrum Mastera. Dzięki, że wytrwałeś ze mną do końca tego posta. Do przeczytania!