Czy można łączyć role w Scrumie?

Artykuł

Czy można łączyć role w Scrumie?

Zwinne organizacje | Blog o agile | Lipiec 2021

Organizacje rozpoczynające swoją drogę ku zwinności, eksperymentują z różnymi frameworkami, wybierając najczęściej Scrum. Firmy nie zawsze decydują się na aplikacje metod zgodnie ze sztuką, a jednym z odstępstw jest wprowadzenie stanowisk hybrydowych, łączących w sobie role Scrum Mastera, Product Ownera i Developerów. O tym, jakie konsekwencje dla organizacji niesie ze sobą takie rozwiązanie, dowiecie się z poniższego artykułu.

Role i odpowiedzialności w Scrumie

Scrum Guide w starszych wersjach wyróżniał 3 role, które wchodziły w skład Zespołu Scrumowego (ang. Scrum Team). Jedną z nich jest Scrum Master, odpowiedzialny za rozumienie Scruma w zespole i organizacji, wspierający zespół jako całość oraz pojedynczych członków w drodze do samoorganizacji i rozwoju. Kolejna z ról to Product Owner, tworzący wizję produktu odzwierciedloną w jego backlogu, która na poszczególnych etapach tworzenia powinna nieść wartość dla użytkownika końcowego. Ostatnia z nich to Zespół Deweloperski, który odpowiada za proces wytwórczy, usprawnienia produktu i innowacje. Więcej o rolach w Scrumie można przeczytać tutaj.

Od 2020 r. przewodnik po frameworku zaczął wskazywać, że nie są to już konkretne role, a odpowiedzialności. Wynika to z faktu, że dotychczas role Scrum Mastera czy Product Ownera były tożsame z formalnymi stanowiskami w strukturze organizacyjnej, co mogło prowadzić do pewnych wypaczeń – zamiast przypisać odpowiedzialności za produkt do istniejącej roli w organizacji, jak np. specjalista ds. kanałów zdalnych czy manager klienta korporacyjnego, tworzyło się osobne stanowiska i miejsca pracy. Nowy Scrum Guide wskazuje zatem, że aby efektywnie zaaplikować framework w organizacji, nie potrzeba specjalnie zmieniać jej struktury organizacyjnej (o ile jest ona efektywna i wspiera zwinny model pracy), a odpowiednio ulokować odpowiedzialności za konkretne obszary merytoryczne. Jedynie wzięcie pełnej odpowiedzialności przy jednoczesnym umocowaniu zespołu przez kadrę zarządzającą sprawi, że będzie mógł się on samoorganizować i samozarządzać.

Łączenie ról

Wiele organizacji, które rozpoczyna swoją drogę ze zwinnością, myśli o tym, żeby połączyć role wymienione w Scrum Guidzie, widząc w tym sposobie krótkoterminowe korzyści. Dzięki temu zamiast kilku stanowisk mogłyby stworzyć jedno, łączące w sobie te role. Z pewnością ma to pewne plusy, jak chociażby optymalizacja kosztów (wynikające z wynagrodzenia oraz rekrutacji), ulokowanie większej ilości informacji w jednym źródle czy możliwość zmniejszenia wielkości zespołów. Tworzenie hybrydowych ról może powstać na kilka sposobów:

  1. W zespole scrumowym istnieją trzy osobne role, jednak natłok obowiązków sprawia, że część odpowiedzialności zostaje delegowana na inną rolę w celu wsparcia.
  2. Organizacja na etapie rekrutacji chce pozyskać osobę do roli hybrydowej, np. Scrum Master-Product Owner, Developer-Scrum Master.
  3. Osoba rozwijająca się w jednej roli pragnie rozszerzyć swoje umiejętności, przyjmując część kompetencji kogoś innego z zespołu scrumowego.

Jednak twórcy Scruma nie bez powodu zdecydowali się rozdzielić te role, aby uniknąć konfliktu interesów. Temat ten zostanie przybliżony w dalszej części artykułu, przy okazji omawiania trzech możliwych kombinacji odpowiedzialności.

Scrum Master – Developer

Osoba będąca jednocześnie Scrum Masterem i Developerem (rozumianym tutaj jako osoba wytwarzającą produkt, niekoniecznie w roli Programisty) jest odpowiedzialna nie tylko za optymalizację pracy zespołu, uczenie dobrych praktyk Scrumowych, coaching czy facylitację spotkań, ale również za realne tworzenie produktu (np. testowanie funkcjonalności, programowanie, tworzenie prototypów, dokumentacji i analizy). Z jednej strony pozwala to głębiej zrozumieć proces wytwórczy oraz to, z jakimi problemami mierzą się inne osoby, z drugiej zaś – ciężej jest się zdystansować w stosunku do zespołu. W takiej sytuacji Scrum Master znacznie częściej wchodzi w rolę właściciela usprawnień, identyfikując problemy, generując usprawnienia i wdrażając je w życie. W wyniku tego, zwalnia zespół z odpowiedzialności za swoją pracę, jej inspekcję i adaptację, zmniejsza również zaangażowanie poszczególnych członków. Dodatkowo, nie tylko jako Scrum Master, ale i Developer, traci jedną z kluczowych wartości Scruma – skupienie (ang. Focus). Skupiając się na pracy wytwórczej, taka osoba może przeoczyć mniej namacalne aspekty, jak np. relacje w zespole czy potencjalne konflikty. Jeśli te ostatnie wystąpią, będąc jednocześnie Developerem, znacznie trudniej jest wchodzić w rolę mediatora (o ile jest ona potrzebna). Podczas braku skupienia, tracimy także możliwość bycia służebnym liderem w stosunku do organizacji, bowiem pełnienie dwóch ról w zespole ogranicza możliwość interakcji z osobami poza nim.

Product Owner – Developer

To połączenie może być również spotykane pod nazwą Proxy Product Owner. W wielu organizacjach widziałam sytuację, gdy mało dostępny Product Owner delegował odpowiedzialność planowania produktu, tworzenia backlogu czy ustalania priorytetów członkom zespołu (zazwyczaj był to analityk biznesowy). W takiej sytuacji Product Owner pozostawał jedynie osobą od udostępnienia środków, eskalowania, prezentowania statusu i podejmowania kluczowych decyzji. I owszem, Scrum Guide daje możliwość delegacji obowiązku zarządzania backlogiem na rzecz innych osób, jednak ta delegacja nie zwalnia z bycia rozliczanym za efekty tej delegacji czy z tworzenia wizji produktu. Jaka może być korzyść łączenia tych dwóch ról? Przede wszystkim, Product Owner zna dużo dokładniej proces wytwórczy, a więc jest w stanie pozyskać wszystkie niezbędne informacje potrzebne do implementacji rozwiązania w dużo bardziej efektywny sposób. Dodatkowo, zazwyczaj taka osoba jest dużo bardziej dostępna dla Developerów – uczestniczy w Daily, może na bieżąco odpowiadać na pytania, czy wyjaśniać wątpliwości. Jednak dostępność Product Ownera dla zespołu powinna być standardem, a nie korzyścią wynikającą jedynie z połączenia jego roli z rolą Developera. Kombinacja może mieć również negatywne strony: Product Owner, będąc jednocześnie Developerem, może odbierać zespołowi kreatywność w temacie tego, w jaki sposób ma być zbudowany produkt. Właściciel produktu odpowiada bowiem za to, co powinno zostać zrealizowane, żeby dostarczyć konkretną wartość użytkownikowi końcowemu, natomiast zespół decyduje o tym, w jaki sposób dana funkcjonalność zostanie zaimplementowana. Dodatkowo, członek zespołu deweloperskiego będący bardziej uprzywilejowany może być wyraźną przeszkodzą do samoorganizacji zespołu – większy zakres odpowiedzialności może sprawić, że osoba pełniąca rolę hybrydową zaczynie zarządzać zespołem, zwalniając go z odpowiedzialności za organizację swojej pracy oraz ciągłe doskonalenie. Kolejna wada takiego rozwiązania to ograniczony kontakt z klientem – cechą pracy Product Ownera jest bieżący kontakt z interesariuszami projektu oraz klientami w celu zbadania potrzeb i oczekiwań. Bardzo często do tego procesu, obok Właściciela Produktu, jest zapraszany zespół deweloperski w celu dostarczenia dodatkowej wiedzy dotyczącej różnych rozwiązań technicznych, które mogą adresować potrzebę klienta. W momencie, gdy Product Owner jest również Developerem, pozostali członkowie zespołu mogą czuć się zwolnieni z konieczności kontaktu z klientem, tracąc przy tym koncentrację w szerszej perspektywie budowanego produktu, na kliencie oraz jego oczekiwaniach.

Scrum Master – Product Owner

Połączenie Scrum Mastera i Product Ownera bardzo często jest określane mianem Delivery Manager lub Delivery Lead. Oczywiście, w takiej formie staje się on odstępstwem od frameworku. W organizacjach pojawia się najczęściej w momencie, gdy przyjmuje ona po raz pierwszy ten sposób pracy i gdy ludzie są dalej przyzwyczajeni do podejścia waterfallowego. Może również powstawać spontanicznie w momencie, gdy Product Owner jest nieobecny i jego obowiązki są czasowo przekazane do wykonywania Scrum Masterowi. Taka osoba ma za zadanie jednocześnie rozwijać produkt, pracować z interesariuszami oraz klientem, jak również rozwijać i wspierać zespół, propagować podejście zwinne w organizacji, pomagać doskonaleniu się i usuwać przeszkody. Szerokie spektrum obowiązków skutkuje nie tylko tym, że taka osoba jest przeciążona i nie może efektywnie wykonywać swoich obowiązków, ale przede wszystkim traci – znowu – swoje skupienie. Cierpi na tym nie tylko jakość produktu i zadowolenie klienta, ale także relacje w zespole, poziom aplikacji Scruma oraz zwinności w organizacji i zadowolenie samego pracownika. Przekłada się to na poziom długu technicznego, mniejszą innowacyjność i efektywność zespołu. Więcej o roli Scrum Mastera dowiesz się z Podcastu „Zwinne organizacje”.

Podsumowanie

Rozdzielenie ról Product Ownera, Scrum Mastera oraz Developera pozwala wcielić w życie wartości, którymi kieruje się framework. Szczególnie ważne jest skupienie (ang. Focus), które pozwala lepiej wykonywać swoje obowiązki i stawać się specjalistą w swojej dziedzinie. Choć łączenie ról może nieść ze sobą pozorne korzyści finansowe w postaci niższych kosztów, to w dłuższej perspektywie negatywne skutki mogą powodować, że te korzyści zostaną zniwelowane lub wręcz przewyższone przez straty. Będą one powodowane dłuższym procesem wytwórczym wynikającym z mniejszego skupienia na usprawnieniu pracy i potrzebie użytkownika końcowego, ograniczonego kontaktu z klientem, braku zbiorowej odpowiedzialności za rozwijany produkt, a także mniejszej kreatywności i innowacyjności rozwiązań technologicznych. I choć początkowo trudno jest wycenić skutki długofalowe, to organizacja powinna zadać sobie pytanie, czy chce zrezygnować z przewagi konkurencyjnej, wynikającej z korzyści płynących z pracy zwinnej tylko po to, by w krótkim terminie zoptymalizować koszty wynagrodzenia i rekrutacji.

„Zwinne organizacje”
Skuteczna pigułka wiedzy o agile

Nie przegap najnowszych treści

Potrzebujesz wsparcia w swojej organizacji? Chętnie pomożemy!
Widzimy, że produkty cyfrowe można tworzyć o wiele szybciej i taniej, jeśli ludzie będą zorganizowani wokół produktów, a nie wokół wydzielonych funkcji. Wymaga to dużej zmiany, w której pomagamy naszym Klientom. Zachęcamy do kontaktu.
Czy ta strona była pomocna?