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 popełniane przez 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:

  1. Najczęstsze błędy
  2. Nadmierne przywiązanie do swoich pomysłów
  3. Praca na własny rachunek
  4. Wycofanie Developera
  5. Niesamodzielność
  6. Ograniczanie obowiązków do zakresu kompetencji
  7. Bałagan w Sprint Backlogu
  8. Podsumowanie

Najczęstsze błędy

Wiele błędów najczęściej popełnianych przez 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.

The most common mistakes of Developers

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.

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łąd nie leży po stronie Developera, tylko nietrafnej oceny jego 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łnianym błędem jest przerzucanie się odpowiedzialnością za jego prowadzenie między Developerami. 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, do najczęstszych błędów popełnianych przez 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.

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

Scrum Guide | 14. Najczęstsze błędy popełniane przez Developerów caroline becker avatar 1background

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ść.