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?
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.
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.
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.
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.
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.
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.
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.
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ść.
Produktywność jest w ostatnim czasie szczególnie często poruszanym zagadnieniem. Powodem takiego stanu rzeczy jest fakt,…
Specjaliści od zarządzania zasobami ludzkimi są odpowiedzialni za szereg ważnych decyzji. Wybór odpowiedniego kandydata przyczyni…
Wraz z ukształtowaniem się nowych pokoleń, zmianom ulega również środowisko i kultura pracy. Generacja Y,…
Badania przeprowadzone przez firmę Owl Labs wskazują, że już 16% organizacji pracuje w trybie zdalnym,…
Wykorzystanie sztucznej inteligencji sprawia, że możemy komunikować się z naszymi urządzeniami używając języka naturalnego –…
“Zamknij okno!” wypowiedziane do asystenta AI będzie oznaczać co innego, gdy pracujemy w edytorze tekstu,…