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:

  1. Najczęstsze błędy Developerówy
  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 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.

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

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

Przewodnik Scrum:

  1. Słowniczek podstawowych terminów Scrum
  2. Czym jest Scrum?
  3. Wartości Scruma
  4. Jak wdrożyć Scrum w swojej firmie?
  5. Scrum Team - czym jest i jak działa?
  6. Kim jest Product Owner?
  7. Kim jest Scrum Master?
  8. Najczęstsze błędy popełniane przez Product Ownera
  9. Cechy dobrego Scrum Mastera
  10. Najczęstsze błędy popełnianie przez Scrum Mastera
  11. Współpraca Scrum Mastera z Product Ownerem
  12. Jakie statystyki i metryki powinien śledzić Scrum Master?
  13. Zespół Developerski w Scrumie
  14. Najczęstsze błędy popełniane przez Developerów
  15. Artefakty Scruma
  16. Skalowanie Scruma
  17. Co to jest Backlog Sprintu?
  18. Co to jest Backlog Produktu?
  19. Czym są User Stories?
  20. INVEST, czyli jak stworzyć dobre User Story
  21. Najczęstsze błędy popełniane przy pisaniu User Story
  22. Kryteria Akceptacji User Story
  23. Estymacja i Story Points w Scrum
  24. Jak działa Planning Poker?
  25. Team Estimation Game jako alternatywa dla Planning Pokera
  26. Czym jest Przyrost w Scrum?
  27. Czym jest Sprint w Scrum?
  28. Wydarzenia w Scrum
  29. Cel Produktu, Cel Sprintu i Definicja Ukończenia, czyli zobowiązania Scrum Team
  30. Co to jest wykres spalania (Burndown Chart)?
  31. Jak tworzyć i jak interpretować wykres spalania?
  32. Zalety i wady wykresu spalania
  33. Tablice Kanban w Scrum i Scrumban
  34. Prędkość Zespołu Deweloperskiego
  35. Daily Scrum
  36. Sprint Planning
  37. Sprint Review
  38. Co to jest Retrospekcja Sprintu?
  39. Częste błędy w czasie Retrospekcji
  40. Jak przeprowadzić pielęgnację backlogu produktu?
  41. Gdzie zdobyć wiedzę i doświadczenie w Scrum?