Über Kleinanzeigen auf der Jagd nach neuen Minds? NEIN! Das sind nicht wir und bitte reagiert nicht darauf. Das ist fake! Wir suchen euch über die üblichen bekannten Plattformen, oder auch direkt in unseren Social Media Kanälen wie LinkedIn, Facebook, XING und Twitter. Findet uns dort und tretet in Kontakt mit uns. Wir freuen uns auf euch!

Jaką wiedzę techniczną powinien posiadać Scrum Master?

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/

0 komentarzy

Wyślij komentarz

Twój adres e-mail nie zostanie opublikowany.

Tim Struck

Napisane przez

Tim Struck