Laboratorium Scruma: Nierówny rozkład pracy w Zespole

bubble chat

Opinia | ZESPÓŁ

Trochę Ci to zajęło, ale wreszcie się udało. Twój zespół jest w pełni interdyscyplinarny. Wszystkie konieczne kompetencje w jednym teamie. I co? I zonk. Okazuje się, że nie każdy w zespole jest równo obciążony pracą. Znacie to? Szymon już poznał i napisał do nas. Zapraszamy do pierwszego odcinka z cyklu Laboratorium Scruma.

Szymon, 28 lat, pisze do nas pytając o nierówny rozkład pracy:

Co doradzić, gdy tworząc zespół multidyscyplinarny odkryjemy rażącą dysproporcję w wysiłku potrzebnym do dostarczenia wartości? Np. w hipotetycznym zespole frontend developer jest w stanie pracować bardzo szybko, ale jego praca nie przynosi wartości nim backend developer nie ukończy swojej części. Tymczasem zmiany po stronie backendu są bardzo długotrwałe. Czy w takiej sytuacji nie warto zastanowić się nad pójściem w kierunku zespołów komponentowych? W szczególności, czy warto jako Scrum Master zawsze silnie sugerować podział w pełni wertykalny, pracę w feature teamach, czy raczej ostrożnie eksperymentować z różnymi wariacjami?

Odpowiada Paweł Feliński, PST.

Drogi Szymonie,

Zespół interdyscyplinarny to zespół, która posiada wszystkie niezbędne kompetencje do dostarczenia Inkrementu zgodnie z Definition of Done. Scrum nic nie mówi o proporcjach tych kompetencji w zespole. Mówi natomiast, że ostatecznie odpowiedzialność za dostarczenie Inkrementu spada na cały Development Team (a nie np. na krytyczny „zasób” w tym zespole).

Co jednak zrobić, gdy do takiej dysproporcji dochodzi?

Wyobrażam sobie wiele rozwiązań, które na pewno gdzieś działają i sprawują się dobrze.

Moja odpowiedź będzie nieco inna, powiedzmy przewrotna: otóż jeśli jest to pytanie postawione Scrum Masterowi, to odpowiedź brzmi: nic nie robić. Kompetencje, ich wykorzystanie, praca w sprincie, dostarczenie Inkrementu – to wszystko należy do Development Teamu i jako Scrum Master nie możesz ingerować w rozwiązanie takich problemów, bo jest to ingerencja w obszar odpowiedzialności zespołu, w obszar techniczny. Pewnie prościej to zrozumieć, gdy wyobrazimy sobie modelowego Scrum Mastera – osobę nietechniczną, która nawet jakby chciała, to nie pomoże, bo się nie zna.

Doświadczenie może, ba, powinno podpowiadać Ci pewne rozwiązania, ale będąc w roli Scrum Mastera nie możesz ich ot tak wdrożyć, gdyż byłoby to zarządzanie już nie procesem, ale zespołem. Do obowiązków Scrum Mastera w tej sytuacji należy zachęcać zespół do samoorganizacji wokół tego problemu, to szukania, eksperymentowania; ostatecznie zgłoszenie tego problemu wyżej do managementu.

Jeśli jednak Twoje pytanie zadane jest z perspektywy członka Development Teamu, to wachlarz odpowiedzi robi się inny. Zasadniczo zespół deweloperski powinien czuć zespołową odpowiedzialność nad sprintem (a Scrum Master zachęcać ich do takiego odczuwania). Jeśli więc testerzy są zarobieni, a programiści nie, to wszyscy razem zastanawiają się, jak sobie pomóc.

A mogą na przykład:
  • parować się z testerami,
  • pisać więcej testów automatycznych,
  • rekrutować testerów,
  • zmienić kompetencje/role,
  • uczyć się,
  • wybierać do sprintu takie wymagania, w których praca programistów i testerów jest zrównoważona,
  • i zapewne wiele innych.

Podobnie z front- i backendowcami, a także wszelkimi innymi specjalizacjami w zespole.

Stworzenie zespołów komponentowych byłoby ostatnią z moich sugestii, ale i ona, zauważ, nie jest przeciwko Scrumowi. Framework nic nie mówi o wyższości feature teams nad component teams. Możemy mieć same zespoły komponentowe i nadal mieć Scruma – narzucamy sobie po prostu więcej zależności, a więc i więcej złożoności do procesu. Warunek brzegowy dla takich zespołów nie ulega zmianie: na koniec sprintu dostarczają one wspólnie jeden zintegrowany Inkrement.

I ponownie: jako Scrum Master, mogę sugerować, proponować, omawiać za i przeciw rozważanych dróg – ale niech to będzie ostatni głos w dyskusji, na samym końcu, kiedy Development Team sam już przepracuje temat i różne rozwiązania. W przeciwnym razie, działając od razu, mogę niechcący zabić samoorganizację.

Najlepsze artykuły:

Powiązane artykuły, mogą Cię też zainteresować!

Cała prawda o czystym kodzie

Wie o tym każdy, kto spędził w jednym projekcie więcej niż dwa lata. Jeżeli kod jest czysty - czyli czytelny, to da się ...

Definition of Done dla Product Ownerów - Poradnik Użytkownika

Pewnie słyszeliście już nie raz o Definition of Done. DoD jest ważne i potrzebne. Tylko do czego służyProduct Ownerowi...

Dziel i zwyciężaj - jak dbać Product Backlog

Dlaczego dzielenie zadań jest tak ważne z technicznego punktu widzenia? Otóż dlatego, że  najwięcej niespodzianek jest n...

Laboratorium Scruma: Scrum Master a Definition of Done

Done, czyli zrobione, ukończone, gotowe do wydania, to najważniejszy element Scruma. Każdy Sprint ma na celu stworzenie ...

Najlepsze artykuły: