Scrum Master o technicznym rodowodzie

Przez wzgląd na różne zawirowania związane ze zmianą pracy trochę zaniedbałem bloga. Było to po części związane z moim aplikowaniem do Toptal i Crossover (o czym napiszę osobno), ale częściowo również związane z faktem „odkurzania” moich technicznych umiejętności – przed wszystkim Angular i WebAPI (o czym również stworzę osobne wpisy). W związku z poszukiwaniem pracy odbyłem kilka rozmów kwalifikacyjnych na Scrum Mastera, przeglądnąłem dziesiątki ogłoszeń i w trakcie tych rozmów pojawiły się ciekawe przemyślenia w tytułowym temacie.

Ale do rzeczy. Czy Scrum Master wywodzący się z developmentu to wada czy zaleta?

To chyba pierwsza rzecz z jaką się zetknąłem – „ma Pan dużo doświadczenia ale tylko y lat jako Scrum Master więc ponieważ y<x …”. Wrzucę tutaj przy okazji link do ciekawego wywiadu z Agile247: “Mówienie, że wszystko się da załatwić Scrumem jest objawem żabiej perspektywy”

I w sumie chyba najważniejszym moim przemyśleniem związanym z powyższymi wymogami, rozmowami itp. jest spłycenie roli Scrum Master-a do opiekuna zespołu. Czyli Scrum Master który przez x lat radził sobie jakoś z grupką ludzi pewnie da sobie radę dalej. Nietechniczny Scrum Master jest równie dobrym Scrum Masterem jak osoba z developmentu (albo inaczej – doświadczenie nie jest kluczowe), ale bycie przez lata w branży IT na różnych stanowiskach związanych z developmentem raczej pomaga niż stanowi przeszkodę. Rozumienie wszelkich zależności w procesie developmentu, deploymentu, testowania etc. jest równie ważne jak rozumienie interakcji międzyludzkich i innych elementów składających się na Agile.

Bo to jeszcze inny temat – często Scrum jest na wczesnym etapie lub tak naprawdę nie wiadomo jeszcze czy Scrum powinien być rozwiązaniem naszych problemów. Osoba mająca doświadczenie z developmentem łatwiej zrozumie i zaproponuje rozwiązania problemów organizacyjnych jeśli okaże się, że akurat Scrum to nie jest dobre rozwiązanie. Agile ma znacząco szerszą paletę rozwiązań i ja osobiście uważam akurat, że lepiej częściej lepiej by było zastosować Kanban niż oszukiwać się mówiąc „mamy Scrum” kiedy w rzeczywistości nawet nie do końca rozumiemy na czym on polega.

No ale taki trend na świecie, że wszyscy mają Scrum, jest on cudownym rozwiązaniem wszystkich problemów i bolączek. Więc łatwiej mieć „mechaniczny” Scrum i udawać, że jest fajnie niż przeanalizować sytuację i zastosować rozwiązanie, które faktycznie będzie rozwiązywało nasze problemy. No, ale taki mamy klimat.

I wracając do tytułowego pytania ja osobiście przyznam, że wszelkie doświadczenie na stanowiskach związanych z zarządzaniem developmentem z reguły przydaje się równie dobrze jak doświadczenie na pozycji Scrum Master-a. Co więcej pozwala nieco szerzej spojrzeć na problemy w zespole niż tylko z perspektywy codziennych problemów.

A tak poza wszystkim to miałem kilka rozmów na stanowisko Scrum Master i nigdy nie miałem rozmowy na temat rozumienia Scrum-a, Agile, Lean, Kanban-a czy innych tego typu ważnych elementów. Zdarzyły się natomiast rozmowy o rozwiązywaniu codziennych problemów w zespołach. Ale ogólnie chyba jednak skłaniam się do opinii, że mało ludzi ma nawet pomysł o czym można by porozmawiać z potencjalnym Scrum Master-em.

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.