Senior Scrum Master, Junior Agile Coach 

Ostatnio aż kręci się w głowie od tych wszystkich tytułów i ról. Senior Scrum Master? Junior Agile Coach? Senior Agile Coach? Junior Scrum Master? Co jeszcze?

Dążenia do rozwoju

Zaledwie tydzień temu dotknąłem dzisiejszego tematu w tekście pod tytułem „Ścieżka rozwoju Scrum Mastera„. Dla przypomnienia: opisałem w nim podróż od pierwszego kontaktu ze Scrumem, aż do zostania pełnoprawnym i skutecznym SM-em. Skupiłem się tam na wiedzy, umiejętnościach i narzędziach, bo w tych kryteriach rozumiem „rozwój” osób pełniących tę funkcję.

SM to rola miękka, której siłą są umiejętności społeczne, odpowiednie podejście do ludzi i doświadczenie w stosowaniu Scruma (technikalia). W tych kategoriach rozwijać możemy się bez końca, ale bardzo trudno będzie nam wykazać poziom naszych umiejętności. Co więcej, perfekcyjny w jednym zespole SM może w ogóle nie pasować do innego. Bardzo trudno to skategoryzować.

Niestety, rynek ma na ten temat nieco inne wyobrażenie. „Przyjęło się”, że Ci najbardziej doświadczeni i ambitni Scrum Masterzy w końcu „awansują” na stanowisko Agile Coacha. Pozostaje tylko wydać z siebie donośne westchnienie.

Pomijając na razie wszystkie problemy z precyzyjnym określeniem roli AC, utworzyło to niebezpieczny precedens. Bo dość szybko pojawił się podział na Junior SM-ów, Senior SM-ów i Agile Coachy. Tak, jakby to właśnie była ścieżka rozwoju dla tej roli.

Scrum Guide milczy na ten temat. Scrum Master to Scrum Master i tyle. Rozwija się wraz z zespołem i nie wydaje się, żeby był jakiś tajemny zestaw umiejętności, który musi posiąść, żeby stać się „seniorem”.

Junior, Mid-level, Senior?

Podział na Juniorów i Seniorów nie dotyczy tylko i wyłącznie kategorii w sporcie. Odkąd pamiętam, programiści bez doświadczenia lądowali na stanowiskach typu Junior Developer, a Ci z dużym, wieloletnim stażem zostawali „Seniorami”. To oczywiście rodziło pewien problem z określeniem tych „zwykłych” developerów.

Czasami „po prostu programiści” zwani byli mid-level developer, ale z tym określeniem jest podobnie jak z Epiciem – strasznie kiepsko się je odmienia, bo w języku polskim jest dość koślawe. Abstrahując od nomenklatury, podział na „świeżaków, doświadczonych i ekspertów” istniał od zawsze.

Wspomniane doświadczenie zwykle liczy się po prostu według stażu. Niemym założeniem jest, że im więcej ktoś czasu spędził pracując w danej technologii, tym lepiej się na niej zna. Co nie zawsze jest zgodne z prawdą, ale sprawdza się wystarczająco często, aby traktować to jako użyteczną heurystykę.

Przecież nawet w zakładach produkcyjnych funkcjonuje stanowisko „mistrza”. Taka osoba, z racji doświadczenia, odpowiada za produkcję na określonym etapie bądź za jakiś proces technologiczny. I znów nazwa sugeruje to, że głównie chodzi tu o lata spędzone wykonując daną czynność.

O ile jeszcze w przypadku stanowisk technicznych jakoś to mogę zaakceptować, tak w przypadku osób zajmujących się bardzo niedookreślonymi i miękkimi rzeczami trudno mi przejść nad tym do porządku dziennego.

Z igły widły

Być może „problem” jest sztuczny. Może faktycznie w każdej roli możemy się rozwijać i z biegiem czasu zdobywamy więcej doświadczenia i stajemy się lepsi. Tylko czy istnieje tu górna granica? Czy programista z 15-letnim doświadczeniem jest o wiele lepszy od tego, który ma 10 lat za pasem?

A wracając do naszych Scrum Masterów i Agile Coachów – czy miarą doświadczenia faktycznie jest upływ czasu? Czy SM, który spędził dziesięć lat pracując z jednym zespołem jest „lepszy” od tego, który przez trzy lata współpracował z sześcioma? Że już nawet nie wspomnę o różnicach w doświadczeniu pomiędzy osobami, które był w małych organizacjach i takich, które zjadły zęby na projektach liczących setki osób.

Tak jak nie da się jasno ocenić Scrum Mastera, tak trudno jest przyporządkować mu „stopień rozwoju”. To nie gra komputerowa, żebyśmy odblokowywali „achievementy”.

W przypadku ról technicznych zwykle posiłkujemy się po prostu liczbą lat spędzonych w konkretnej technologii. Może i w tym przypadku powinniśmy postępować podobnie? Zamiast ogłoszeń o pracę na „Senior Scrum Mastera” powinniśmy widzieć „Scrum Master z doświadczeniem w skalowaniu Scrum” lub „SM dla zespołów rozproszonych„?

Tylko oczywiście my gadamy sobie, a rynek sobie. Tak jak od dawna nieodłącznym aspektem SM-a poszukującego pracy jest odpowiedni certyfikat, tak teraz każdy na siłę udowadnia ile to lat spędził w danej roli. Bo im bardziej „senior” jesteśmy, tym na większe możemy liczyć zarobki.

Nie sądzę, żeby to szaleństwo miało minąć. Wiele organizacji, które trudno nazwać zwinnymi, poszukuje Scrum Masterów według bardzo konkretnych kryteriów: certyfikat, lata doświadczenia, znajomość Atlassian Jira, doświadczenie w rozdzielaniu zadań i kontrolowaniu postępów pracy, harmonogramowanie i zasobowanie, itd.

Tylko co to ma wspólnego z rolą Scrum Mastera i kiedy dojdziemy do punktu, w którym „SM” to tylko nic nie znacząca etykieta?