Najczęstsze błędy Developerów Scrum| Firmbee

Zespół Developerski to grupa samodzielnych specjalistów. Jednak powodzenie projektu, który realizują, zależy od ich wspólnych wysiłków. A to wymaga dużej dojrzałości i umiejętności z zakresu pracy zespołowej. Jakie są najczęstsze błędy Developerów? Które z nich sprawiają, że dążenie do Celu Produktu staje się trudne, albo nawet niemożliwe?

Najczęstsze błędy popełniane przez Developerów – omówione zagadnienia:

Najczęstsze błędy Developerówy
Nadmierne przywiązanie do swoich pomysłów
Praca na własny rachunek
Wycofanie Developera
Niesamodzielność
Ograniczanie obowiązków do zakresu kompetencji
Bałagan w Sprint Backlogu
Podsumowanie

Najczęstsze błędy Developerów

Błędy Developerów pracujących w Scrum ma swoje źródło w ich podejściu do pracy zespołowej. Z jednej strony jest to źle rozumiana niezależność i obrona swoich pomysłów wbrew interesom Zespołu. Z drugiej strony – zdawanie się na innych i brak samodzielności. Kolejnym źródłem problemów może stać się opaczne rozumienie zespołowej odpowiedzialności.

Nadmierne przywiązanie do swoich pomysłów

Do codziennych obowiązków Developerów należy znajdowanie innowacyjnych rozwiązań złożonych problemów. Wysiłek wkładany w opracowywanie rozwiązań może powodować, że nadmiernie przywiązują się do swoich pomysłów. To z kolei sprawia, że tracą z oczu Cel Produktu i poświęcają zbyt dużo czasu na rozwijanie pobocznych rozwiązań, które nie są użyteczne z biznesowego punktu widzenia. A także mniej chętnie poszukują alternatywnych rozwiązań, co zagraża zwinności Zespołu. Błędy Developerów wynikające z nadmiernego focusowania się na własne rozwiązania powinny być eliminowane przez Scrum Mastera zanim zagrożą realizacji sprintu.

Praca na własny rachunek

Jeśli Developer ma trudności ze zrozumieniem swojej roli w Zespole, będzie próbował wyodrębnić swoje zadania z Celu Sprintu. Co gorsza, będzie realizować je bez odnoszenia się do pracy reszty Zespołu. Problemem może stać się również samowolne dokonywanie zmian w Backlogu Sprintu. Tak właśnie źle rozumiana niezależność jednego z Developerów może wypływać z problemów komunikacyjnych.

Nadmierne pragnienie niezależności może mieć źródło w braku uznania dla indywidualnych osiągnięć Developera. Pojawia się, gdy jego wkład w pracę wykonaną przez Zespół jest oceniany nieproporcjonalnie do włożonego wysiłku i trudności zadania.

Praca na własny rachunek może być źródłem poważnych konfliktów w Zespole. Dlatego tak ważna jest reakcja Scrum Mastera i jak najszybsze rozwiązanie problemu, który leży u jego podstaw. Może się bowiem okazać, że błędy Developerów nie są z ich winy, tylko powstały po nietrafnej oceny ich zaangażowania.

Praca na własny rachunek

Problemem wynikającym z dwóch poprzednich – pracy na własny rachunek i nadmiernego przywiązywania się do własnych pomysłów – może być problem braku komunikacji. Developer zaczyna izolować się od Zespołu. Mimo, że wykonuje swoje zadania zgodnie z Backlogiem Sprintu, wycofuje się z życia Zespołu.

W takiej sytuacji Scrum Master powinien zwrócić szczególną uwagę na wycofanego Developera. Docenić jego wkład w pracę Zespołu oraz zachęcić do przyjęcia proaktywnej postawy.

Niesamodzielność

Samoorganizacja to cecha dojrzałego, dobrze skomponowanego Zespołu Developerskiego, którą opisaliśmy w poprzednim artykule. Oznacza ona, że mimo trudności, Developerzy nie polegają na innych osobach, które mówią im, w jaki sposób rozdzielać między sobą zadania, jak i kiedy je realizować. Samoorganizacja może jednak rodzić interpersonalne nieporozumienia.

W takim przypadku konieczna jest stała obecność Scrum Mastera czuwającego nad podziałem zadań, które muszą zostać wykonane do realizacji Celu Sprintu. Wtedy właśnie pojawia się problem niesamodzielności Developerów.

Z pomocą znowu powinien przyjść Scrum Master, zachęcając członków Zespołu Developerskiego do samostanowienia i brania odpowiedzialności za wykonywane zadania.

Ograniczanie obowiązków do zakresu kompetencji

Kolejnym problemem, z jakim muszą mierzyć się Developerzy, szczególnie w formującym się Zespole, jest niechęć do wykonywania zadań innych niż należących do kluczowych kompetencji Developera.

Błąd ten może prowadzić do znacznego zmniejszenia efektywności Zespołu Developerskiego. Nie we wszystkich Sprintach wykorzystywane są kluczowe kompetencje każdego z członków Zespołu. Dlatego muszą być oni otwarci na wykonywanie innych, pomocniczych lub porządkujących zadań, które są równie istotne z uwagi na Cel Sprintu.

Bałagan w Sprint Backlogu

Jednym z takich zadań jest dbanie o porządek w Backlogu Sprintu. To zadanie kluczowe dla sprawnego działania Zespołu Developerskiego. Jednak często popełniane są błędy Developerów polegające na przerzucaniu się odpowiedzialnością za ich prowadzenie między sobą. Utrudnia to nie tylko pracę nad Celem Sprintu, lecz również rozwijanie się Zespołu i bieżące usprawnianie jego działania.

Podsumowanie

Podsumowując, najczęstsze błędy Developerów należą próby odcięcia się od Zespołu jako całości: praca na własny rachunek, forsowanie własnych pomysłów, oraz wycofywanie się Developera. Integralności Zespołu Developerskiego zagrażają także problemy z wypracowaniem samodzielności, bałagan w Sprint Backlogu, a także niechęć Developerów do wypełniania obowiązków spoza ich kluczowych kompetencji.

Sprawdź kolejny wpis z serii Przewodnik Scrum – Artefakty Scruma

Jeśli podobają Ci się treści, które tworzymy, sprawdź również: Facebook, Twitter, LinkedIn, Instagram, YouTube, Pinterest.

Autor: Karolina Berecka
Karolina, jako project menadżerka jest ekspertem w poszukiwaniu nowych metod projektowania najlepszego systemu przepływu pracy i optymalizacji procesów. Jej umiejętności organizacyjne i zdolność do pracy pod presją czasu sprawiają, że jest najlepszą osobą do zamieniania skomplikowanych projektów w rzeczywistość.

Zobacz wszystkie posty

Przerwa konserwacyjna

Scrum Guide | 14. Najczęstsze błędy popełniane przez Developerów