Jak zmaksymalizować efektywność współpracy pomiędzy Product Ownerem, a Scrum Masterem?

Czy byliście kiedyś na planowaniu sprintu na którym Product Owner bardzo nalegał, aby zespół brał większy zakres iteracji, a z drugiej strony Scrum Master naciskał, aby zespół jednak nie brał już nic więcej? Pomijając przypadki, kiedy te dwa zdania byłyby podyktowane brakiem profesjonalizmu lub chęcią zrobienia drugiej stronie na złość, to oba te punkty widzenia mają sens.

Ale to tak jakby na jednym ramieniu do ucha dev teamu coś szeptałby anioł, a na drugim wtórował mu diabeł…

Tylko teraz, kto z tej pary jest kim? 🙂
Postaram się na to pytanie odpowiedzieć w poniższym artykule! Znajdziecie w nim też kilka sugestii jak te dwie role mogą poprawić współpracę i wydajność swojej pracy.

To jak jest z tymi rolami?

Zanim możemy coś usprawniać, musimy najpierw zrozumieć gdzie jesteśmy. Omówmy sobie pokrótce rolę Scrum Mastera i Product Ownera w Scrumie i jakie są ich podstawowe interakcje między sobą.

Product Owner, zgodnie z definicją, ma za zadanie zmaksymalizować wynik pracy zespołu poprzez efektywne zarządzanie backlogiem produktu. Taki backlog powinien być:

• dostępny dla zespołu i opisany w zrozumiały dla niego sposób,
• wystarczająco doprecyzowany, żeby zespół wiedział jakie są oczekiwania kierownika produktu względem danej historyjki i przez to co należy zrobić,
• podzielony na zadania o odpowiednim rozmiarze tak, aby zespół mógł dostarczać wartość najlepiej co iterację.

Scrum Master natomiast skupia się na maksymalizowaniu wyniku pracy zespołu poprzez:

• budowanie świadomości zespołu jak usprawniać swoją pracę,
• usuwanie przeszkód, które utrudniają postępy w pracy zespołu,
• pomaganie Product Ownerowi w zrozumieniu i wdrażaniu zasad zwinnego budowania produktów,
• prowadzenie organizacji poprzez wdrożenie Scruma i transformację w kierunku metodyk zwinnych.

Ale chwila, poczekaj, wróć…
Product Owner, zgodnie z definicją, ma za zadanie zmaksymalizować wynik pracy zespołu (…)

Scrum Master natomiast skupia się na maksymalizowaniu wyniku pracy zespołu (…)

Tak – obie rolę mają tak naprawdę ten sam cel, lecz do tematu podchodzą z dwóch różnych stron. Więc jeżeli cel jest wspólny, to dlaczego te dwie osoby nie miałyby ze sobą współpracować? Czy Scrum guide coś na ten temat mówi? Mamy na to jeden, średniej długości paragraf. Dotyczy on “usług” Scrum Mastera w kierunku Product Ownera, które w gruncie rzeczy można by streścić jako uczenie PO mentalności i technik metodyk zwinnych oraz pomoc w ich wdrożeniu.

Z żalem stwierdzam, że opisuje to tylko połowę interakcji – framework nie wspomina o tym co PO może oddać w zamian SM. Może ma to rację bytu, kiedy Product Owner nie ma obeznania w metodyce. Ale przecież na rynku mamy coraz więcej naprawdę zaprawionych w boju speców produktowych i grzechem byłoby z tej wiedzy nie skorzystać. Naprawmy to! Spójrzmy jak obie strony mogą sobie pomagać, a co za tym idzie, jak mogą nawzajem usprawnić swoją pracę.

Rozważmy następujące modele współpracy pomiędzy Scrum Masterem, a Product Ownerem.

Spece od wysłuchiwania drugiej osoby 🙂

Jednymi z fundamentów Scruma są: inspekcja i adaptacja. Podążając za tymi wykładniami, każdy z nas powinien często spoglądać na swoją pracę i zastanawiać się jak można ją usprawnić. Najlepiej taki “rachunek sumienia” zrobić z pomocą drugiej osoby. Do tego zadania świetnie może się nadać zaufana osoba z którą pracujemy na co dzień – SM / PO. Tym bardziej kiedy ta osoba jest przecież “specem w wysłuchiwaniu innych osób”:

• Scrum Master jest świetny w rozumieniu i pomaganiu członkom zespołu.
• Product Owner na co dzień słucha i rozwiązuje problemy użytkowników / klientów.

Nie bójcie skorzystać ze swojej pomocy by lepiej zrozumieć jak stawać się lepszym.

Sparingpartnerzy

Z drugiej strony, kiedy masz już pomysł jak można by zaadresować problemy w swoim scrum teamie, czy to dotyczących samego siebie (jak powyżej), śmiało pogadaj o tym ze swoim SM / PO. Jako osoby obeznane w metodykach zwinnych, na pewno powinny być w stanie “podnieść rękawicę” i dokonać konstruktywnej krytyki Twojej propozycji. Dużo osób, tego typu pomysły dyskutują ze swoimi odpowiednikami na spotkaniach typu Community of Practice / Scrum of Scrums / itp. Ma to jednak jedną wadę. Mianowicie, tacy koledzy po fachu nie siedzą na co dzień w Waszym zespole scrumowym, a co za tym idzie nie znają jego charakterystyki, dynamiki czy też motywacji. Po prostu, niektóre pomysły mogą nie zadziałać tak samo skutecznie w różnych środowiskach. Dlatego warto też porozmawiać z osobą, która od środka rozumie otoczenie w jakim operujecie – Twoim Scrum Masterem / Product Ownerem.

Sojusznicy

Kiedy jesteśmy już gotowi do zmiany, w osobie Twojego SM/PO możesz szukać pomocy we wdrożeniu swojego pomysłu. I nie mówię tutaj o robieniu roboty za nas, ale wsparciu na różnych płaszczyznach – od motywania po bycie ambasadorem zmiany. Świetnym przykładem jak takie wsparcie może zaprocentować są zmiany dotyczące Waszego zespołu scrumowego. Po prostu, dwóm osobom łatwiej przekonuje się innych, niż mając siłę przebicia tylko jednej. Zwłaszcza kiedy zespół jest oporny na zmiany. Ustalcie w takich sytuacjach wspólny plan działania, a sukces powinien być na wyciągnięcie ręki!

Entuzjaści

Jeżeli SM i PO naprawdę podążają za wartościami metodyki zwinnej, samorozwój powinien być jedną z ważniejszych czynności w ich życiu. Spędzają więc dużo czasu szukając ciekawostek i artykułów w internecie, wertując książki, projektując eksperymenty. Często znalezione materiały mogą być przydatne drugiej z ról – pamiętajcie o sobie nawzajem i przekazujcie taką wiedzę. Na przykład – czy myślisz, że ten artykuł mógłby zaciekawić Twojego PO/SM? Jeśli tak, to mu go prześlij! 🙂

Zastępcy?

Tutaj z kolei zapędzamy się za daleko. Pomimo, że Scrum Master i Product Owner mogą być mocno zaznajomieni w zakresie obowiązków drugiej osoby, to, według mnie, nie powinny się nawzajem zastępować. Mówię to z własnego doświadczenia, kiedy to musiałem albo pełnić przez pewien czas obie role na raz, ale też incydentalnie wypełniałem lukę po chorym SMie jako np. facylitator spotkań. Przy pojedynczych przypadkach nie doszukujmy się jakiejś tragedii, ale, jeśli miałoby to trwać więcej niż kilka dni, pomyślcie o kilku problemach:

• konflikt interesów, kiedy starasz się poświęcać całą uwagę swoim użytkownikom i jednocześnie skupiać się w stu procentach na zespole,
• niezbalansowane interakcje w zespole mogą doprowadzać do próby chodzenia na skróty, bo zawsze kogoś ostatecznie będziesz faworyzował – użytkownika albo zespół,
• nawet na samych spotkaniach, często będzie Ci brakować drugiej osoby do ich efektywnego przeprowadzenia.

Według mnie, o wiele zdrowszym rozwiązaniem będzie poszukanie zastępstwa w zespole deweloperskim albo w jego otoczeniu. Dobry Scrum Master, który dąży do pełnej samoorganizacji zespołu, bez problemu znajdzie ochotnika, który by poprawadził zespół podczas swojej nieobecności. Solidną alternatywą może być też kolega SM z równoległego zespołu. W przypadku Product Ownera, za pierwszą opcję uznaję analityka ze scrum teamu (bądź osobę, która przejawia największe zdolności analityczne – na przykład tester). W drugim rzędzie ustawiłbym, podobnie jak u SM, kolegę PO z równoległego zespołu, bądź Product Managera (jeśli pracujemy w Product Teamie).

Podsumowanie

Wróćmy więc do ostatniej, nierozwiązanej kwestii – to jak z tym diabłem i aniołem siedzącym na ramionach zespołu deweloperskiego? Jak już się pewnie domyślacie, pomimo różnych punktów widzenia, jakie we wstępie SM i PO wypowiedzieli, to tak naprawdę przyświeca im wspólny cel – chcą wspomóc zespół w dostarczaniu wartości. Scrum Master, w tym przykładzie, mógł upewniać się czy zespół będzie czuł się komfortowo biorąc taki zakres sprintu. Product Owner, mógł natomiast motywować zespół, aby zakres sprintu był wystarczająco ambitny i przez to satysfakcjonujący dla członków zespołu.
I tak oboje: Product Owner i Scrum Master, jak yin i yang, mimo że są różnią się od siebie, to razem tworzą idealną całość! 🙂 Jeśli masz więc ochotę poprawić wyniki swojej pracy, umów się ze swoim SM/PO na spotkanie i razem poszukajcie swojej drogi na szczyt!