7 powodów, dla których w 2022 roku Scrum Master powinien znać się na tworzeniu oprogramowania – i 5 powodów, dla których nie musi!

Przypominam sobie, kiedy pierwszy raz zacząłem pracować ze Scrum Masterem w projekcie. Z dnia na dzień pojawił się nowy kolega, który pilnował, żebyśmy każdego dnia wymieniali uwagi odnośnie projektu i który chciał wiedzieć czy pojawiają się w nim jakieś problemy. Początkowo byliśmy nieco zaskoczeni, ale szybko okazało się, że jego obecność przyniosła nam wiele korzyści. Mieliśmy kogoś, kto nas wspierał, był tam dla nas i pomagał załatwiać w organizacji sprawy, które nie leżały już w naszych kompetencjach.

W tamtych czasach to najczęściej doświadczeni programiści, programistki i architekci/architektki oprogramowania podejmowali się pełnienia tej dodatkowej roli. W międzyczasie ja sam zacząłem pracować jako Scrum Master. Wiele przedsiębiorstw ma dobre doświadczenia w zatrudnianiu na to stanowisko osób spoza branży informatycznej.

Czy kompetencje techniczne są niezbędne w pełnieniu funkcji Scrum Mastera?

Dlaczego Scrum Masterzy powinni posiadać kompetencje techniczne:

Powód 1: znają procesy i procedury

Nie pracujemy w próżni. W branży programistycznej wypracowano już procedury i best practices, które mogą być stosowane z korzyścią dla projektu. Dlatego warto mieć pojęcie o procesie tworzenia oprogramowania, począwszy od analizy i inżynierii wymagań, przez fazę koncepcyjną, wdrażanie, aż po testy i oddanie produktu, by wymienić najważniejsze punkty.

Powód 2: lepiej zrozumieją zespół

Zespoły programistyczne często są bardzo zróżnicowane i składają się z ludzi z różnym zapleczem. Niektórzy programiści są indywidualistami, inni wywodzą się z klasycznych projektów IT, a co poniektórzy zaczynali w scenie startupowej. Kompetencje techniczne pomagają stworzyć podstawę udanej komunikacji i współpracy.

Powód 3: antycypują problemy

Doświadczenie popłaca: „szósty zmysł“ może nas ostrzegać, zanim będzie w ogóle wiadomo, co go uaktywniło. Dzięki temu można działać, póki problem jest niewielki i można go łatwo rozwiązać.

Powód 4: uważają się za część zespołu

Walk the walk, talk the talk – „doświadczenie bojowe“ nie zaszkodzi. Kiedy Scrum Master na własnej skórze doświadczył problemów, z jakimi programiści zmagają się każdego dnia, łatwiej się zrozumieć i razem pracować.

Powód 5: znają typowych podejrzanych

Każdy projekt jest inny, ale często pojawiają się w nim podobne problemy. Przy odrobinie technicznego doświadczenia łatwo je zidentyfikować lub przynajmniej domyślać się, na czym polegają.

Powód 6: rozumieją punkt widzenia innych

Każda programistka i każdy programista są różni i widzą świat z kompletnie innej perspektywy. Doświadczenie pracy w takim zespole jest wiele warte.

Powód 7: mogą być partnerami sparingowymi dla programistów

Złożone zadania programistyczne są czasami ciężkie do rozgryzienia w pojedynkę i tu bardzo pomaga omówienie problemu z drugą osobą. Tu do zadawania właściwych pytań bardzo przydaje się przynajmniej podstawowa wiedza w tej materii.

Reasumując: wiedza nie szkodzi. Ale sama wiedza to nie wszystko. Dlatego:

5 kontrargumentów, dla których wiedza techniczna to nie wszystko:

Kontrargument 1: wszystkiego można się nauczyć

Programowanie to nie czarna magia (przynajmniej nie zawsze). Podstaw można się szybko nauczyć samemu. Można skorzystać z https://www.freecodecamp.org/ tudzież aplikacji do nauki programowania na Switch i Playstation.

Kontrargument 2: przede wszystkim ludzie

Mimo tego, że wiele osób ma w głowie stereotyp programistów, część problemów w projektach nie leży po stronie technicznej. Często są one spowodowane przez braki w komunikacji, konflikty wewnątrz zespołu lub zły nastrój. I dlatego często warto najpierw tu szukać przyczyny danego problemu.

Kontrargument 3: większa obiektywność

Czasami „nie widać lasu spoza drzew“. Warto wtedy spróbować znaleźć nową, neutralną perspektywę spoza projektu, zrobić krok do tyłu, popatrzeć na sytuację z kompletnie innej strony lub wypróbować rozwiązania z innego zakresu. Czasami to może zdziałać cuda.

Kontrargument 4: inne podejście

Scrum Masterzy, którzy nie wywodzą się ze środowiska programistycznego, mają często zupełnie inny tryb postępowania i dzięki temu mogą zaoferować zespołowi nową, świeżą perspektywę. Programiści mogą spojrzeć na problem z innej strony i dzięki temu łatwiej go rozwiązać.

Kontrargument 5: technologia to nie wszystko

Żyjemy w wysoce stechnologizowanym świecie i mamy skłonność do rozwiązywania problemów przy użyciu technologii. Ale czy naprawdę potrzebujemy kolejnej aplikacji? A może da się problem rozwiązać inaczej? „Kto ma tylko młotek, patrzy na wszystko jak na gwoździe“. Korzystając z innych metod, na przykład Design Thinking, można poszerzyć swój repertuar i wspólnie przetrzeć nowe szlaki.

Doświadczenie techniczne na pewno nie zaszkodzi, ale nie jest ono panaceum na wszystko. Co o tym sądzisz? Chętnie poznam Twoją opinię. Zostaw nam komentarz lub napisz do mnie bezpośrednio (po angielsku lub niemiecku) na adres tim.struck@qualityminds.de.

Jeżeli pragniesz dowiedzieć się więcej o roli Scrum Mastera, przygotowaliśmy dla Ciebie więcej informacji na naszej stronie https://qualityminds.com/pl/services/agile-support/scrum-master/