Paweł_Feliński_Laboratorium_Scruma
 

Szymon, 28 lat, pisze do nas:

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

Snajper o ciętym języku i doskonałych umiejętnościach analitycznych. Weteran transformacji w kierunku Lean i Agile.