Współpraca Product Ownera z Developerami

Za każdym dobrym Produktem stoi Product Owner znający rynek i użytkowników oraz zaangażowani Developerzy. Najlepsze Zespoły zbudowane są ze Developerów specjalistów, których żywo obchodzi powodzenie Produktu. Najlepsze rezultaty są osiągane, jeżeli osiągniemy symbiozę we współpracy Product Ownera i Developerów.

Kim są Developerzy?

W skład Scrum Teamu wchodzi jeden Product Owner, jeden Scrum Master i Developerzy. Odpowiedzialnością całego Scrum Teamu jest dostarczanie wartościowego Produktu, a zatem realizowanie wszystkich koniecznych ku temu działań (współpracę z interesariuszami, weryfikację, utrzymanie, obsługę, eksperymentowanie, badania i rozwój). W Zespole Scrumowym nie ma hierarchii. Wszyscy są równi. Nie ma leadera, który organizuje wszystkim pracę.

W obrębie Zespołu istnieje rola Developerów, którą piastują wszystkie osoby realizujące pracę przy tworzeniu Produktu. Gdy mówimy „Developer” w głowach wielu osób pojawia się obraz programisty. Developerzy to jednak nie tylko programiści, ale również inni specjaliści (np. analitycy biznesowi, UX designerzy czy testerzy). Będą oni tworzyć interdyscyplinarną grupę osób, posiadającą wszystkie umiejętności potrzebne do wytworzenia ukończonego Przyrostu.

Zgodnie z „Przewodnikiem po Scrumie” [1] odpowiedzialnością Developerów jest m.in. : ustalanie planu działania w formie Sprint Backlogu i jego codzienna adaptacja by osiągnąć Cel Sprintu, zapewnienie jakości wytwarzanego Produktu zgodnie z ustaloną Definicją Ukończenia oraz wzajemne egzekwowanie odpowiedzialności zawodowej.

Developerzy zamiast Development Teamu

„Scrum Guide” z 2020 roku dokonał zmiany rezygnując z „Development Teamu” na rzecz „Developerów”. Wcześniejsza wersja mogła sugerować, że Developerzy tworzą pewnego rodzaju podzespół w obrębie Zespołu Scrumowego. Najnowsza wersja „Scrum Guida” nie pozostawia złudzeń, że Zespół jest jeden.

Zmiana ta, choć wygląda na niewielką, to istotnie wpływa na postrzeganie poszczególnych ról w Zespole Scrumowym. Umacnia przekaz związany z równością i jednością Zespołu Scrumowego. Product Ownerowi może ułatwiać pracę ramię w ramię z poszczególnymi Developerami.

Jak powinna przebiegać współpraca Product Ownera z Developerami?

Sprawna współpraca całego Zespołu Scrumowego jest kluczowa do osiągnięcia sukcesu produktowego. Jako Product Owner powinieneś dążyć do stworzenia wraz z Developerami symbiozy, która ułatwi pracę nad Produktem. Poniżej znajdziesz wskazówki dla Product Ownera, które pomogą stworzyć dobre relacje z Developerami.

Współpraca Product Ownera z Developerami. Bądź częścią Zespołu, Przestrzegaj Wartości Scruma, Daj przestrzeń na samozarządzanie, Razem twórzcie Backlog Produktu, Przekazuj wizję i strategię, Wymagaj wysokich standardów, Bądź tarczą dla Zespołu

1. Bądź częścią Zespołu

By osiągać sukcesy Zespół musi grać do jednej bramki. Nie powinny istnieć podziały na ja – PO, wy – Developerzy. By tworzyć taki Zespół, jako Product Owner, musisz być dostępny i obecny w życiu Zespołu. Stań się prawdziwie jego częścią.

Za dostępnością PO będą przemawiać pragmatyczne czynniki, takie jak szybkość rozwiązywania problemów napotykanych przez Developerów i sprawność podejmowania decyzji. Jednak równie istotny jest czynnik ludzki. Jeżeli będziemy obecni w życiu Zespołu, to naturalnie budować się będą relacje i wytworzy się więź, która będzie przekładać się na łatwość współpracy.

Elementem scalającym Zespół jest czynny udział w wydarzeniach Scrumowych i innych spotkaniach zespołowych [3,4]. Dla każdego Product Ownera oczywistym będzie uczestnictwo w Planowaniu i Review. Jednak nie mnie ważny jest udział w Retrospektywie, która ukierunkowana jest na usprawnianie procesów. Jeżeli będzie to dla Zespołu pomocne, PO może również rozważyć udział w Daily Scrum*.

Interakcje w Zespole powinny być skupione na współpracy (ang. collaboration). Collaborator jest jedną z preferowanych postaw, którą powinien przyjmować Product Owner [6]. I chociaż postawa ta dotyczy wielu aspektów jego pracy, to jedną z nich jest właśnie współpraca z Developerami. Ważne jest by odbywała się ona na równych warunkach dla każdego i w kierunku osiągnięcia jednego celu.

*Zanim zdecydujesz się na ten krok polecam przeczytać artykuł o Daily Scrum, w którym opisałam pułapki czyhające na Zespół, jeżeli Product Owner uczestniczy w Daily.

2. Przestrzegaj Wartości Scruma w codziennej pracy

W budowaniu dobrych relacji w Zespole pomocne będą Wartości Scruma, czyli zaangażowanie, skupienie, otwartość, szacunek i odwaga.

Product Owner powinien być zaangażowany w życie i pracę Zespołu. Bycie aktywnym i skupionym uczestnikiem spotkań jest tutaj kluczowe. Staraj się zrozumieć o czym mówią Developerzy. Rozumienie aspektów technicznych na poziomie pozwalającym Ci świadomie uczestniczyć w dyskusjach prowadzących do podjęcia decyzji, będzie ułatwiać współpracę. Jeżeli czegoś nie rozumiesz – pytaj.

Bądź szczery. Otwarcie mów o sytuacji biznesowej i argumentach, których używasz do podejmowania decyzji – szczególnie tych, które mogą być negatywnie odbierane przez Zespół. Odważnie dawaj feedback i bądź gotowy na jego przyjmowanie. Uzyskasz szacunek Zespołu, jeżeli dostrzegą w Tobie szczerego i kompetentnego Partnera.

Zawsze zakładaj, że każdy członek Zespołu działa na miarę swoich najlepszych możliwości i dobrze wykona swoje zadanie [3].

3. Daj przestrzeń na samozarządzanie

Jako Product Owner jesteś członkiem Zespołu, w którym nie ma hierarchii. Mimo, że podejmujesz decyzje produktowe, to Twoją odpowiedzialnością nie jest decydowanie o tym kto, w jakiej kolejności i jak będzie realizował zadania. Developerzy powinni sami organizować swoją pracę.

Często Product Ownerzy wywodzą się z ról managerskich – mają doświadczenia oraz nawyki związane z zarządzaniem ludźmi. Jeżeli pełnisz rolę Product Ownera w Zespole Scrumowym, to musisz świadomie ograniczyć wpływ tych nawyków na Twoją pracę. Daj Developerom swobodę działania i podejmowania decyzji w zakresie ich obowiązków.

Będąc PO jesteś odpowiedzialny za zarządzaniem Produktem. Zajmij się więc określaniem wizji, strategii, propozycji wartości, celów, czy kluczowych funkcjonalności. Problemy związane z ludźmi i procesami pozwól rozwiązywać Scrum Masterowi [3].

4. Przekazuj wizję i strategię

Jednym z czynników budujących motywację jest poczucie sensu. Pełniąc rolę Product Ownera masz najlepsze narzędzia w ręku, by pokazywać Developerom sens ich pracy. Ustalasz wizję oraz wynikającą z niej strategię Produktu. Bierzesz udział w ustalaniu celów i tworzysz Roadmapę (najlepiej taką Roadmapę rezultatów). Doskonale wiesz dlaczego tworzysz Produkt i jakich rezultatów się spodziewasz.

Wyniki Twojej pracy mogą pozytywnie wpływać na motywację Developerów, zatem warto się nimi dzielić. Developerzy będą chętniej angażować się z Tobą w tworzenie rozwiązań, jeżeli będą wiedzieć jaki jest cel. Nie ma nic lepszego w pracy niż poczucie, że to co robisz ma sens i komuś pomaga.

Zatem na każdym kroku współpracy z Developerami przypominaj po co wykonujemy dany element, jak wpłynie on na życie użytkowników Twojego Produktu i rezultaty biznesowe. Mów o tym kim są użytkownicy i jakie maja problemy. Wskazuj jaką wartość przynosi nasz produkt i czym wyróżnimy się na tle konkurencji [3]. Sposobności ku temu masz mnóstwo – zaczynając na Planowaniu, poprzez Refinementy, skończywszy na Sprint Review.

5. Razem twórzcie Product Backlog

Istotnym elementem współpracy Product Ownera i Developerów jest praca nad Backlogiem Produktu. I chociaż PO jest odpowiedzialny za zarządzanie Product Backlogiem, to nie oznacza to, że całość pracy związanej z tworzeniem elementów Backlogu i opisywaniem ich musi wykonywać sam.

Duże lepsze rezultaty osiąga się, jeżeli poszczególne elementy Backlogu budowane są razem z Developerami. Scrum daje do tego narzędzie w postaci Refinementów. Są to regularne spotkania ukierunkowane na budowanie odpowiedniej szczegółowości Backlogu. W trakcie spotkań generowane są rozwiązania będące odpowiedzią na potrzeby użytkowników Produktu.

Niektórzy Product Ownerzy uważają, że są jedyną osobą utrzymującą kontakty z Interesariuszami i użytkownikami. Nic bardziej mylnego! Dobrze jest zachęcać Developerów do angażowania się w spotkania, podczas których z pierwszej ręki mogą usłyszeć lub zobaczyć z jakimi problemami borykają się użytkownicy Produktu. Łatwiej będzie im z nimi sympatyzować i tworzyć rozwiązania myśląc o ich doświadczeniach.

Kontakt Developerów z użytkownikami jest rzeczą, która pomoże Ci uwzględniać ich perspektywę w procesie podejmowania decyzji produktowych, czyli zaangażować ich w …

Proces odkrywania Produktu

Książki o współczesnym tworzeniu Produktów, takie jak „Zainspirowani” Marty Cagan czy „Continous Discrovery Habits” Teresa Torres, podkreślają znaczenie zaangażowania Developerów w proces odkrywania Produktu. Odkrywanie Produktu jest procesem, w którym szukamy najlepszych rozwiązań dla problemów ich użytkowników. I chociaż mogłoby się wydawać, że jest to w pełni odpowiedzialność Product Ownera, to jednak wspomniani twórcy sądzą inaczej.

Proponują podejście w formie tzw. Product Trio, zakładając że w proces odkrywania są zaangażowani Product Manager (często w roli Product Ownera), Programista (osoba znająca się na technologii) i Designer (osoba znająca się na doświadczeniach użytkownika). Perspektywa osoby technicznej jest kluczowa, bo może już na wczesnym etapie określić jak technologia może pomóc w rozwiązaniu konkretnego problemu użytkownika.

6. Wymagaj wysokich standardów

Cały Zespół Scrumowy jest odpowiedzialny za dostarczanie wartościowego Produktu, czyli spełniającego potrzeby użytkowników i będącego wysokiej jakości. Jako PO możesz zatem wymagać od Developerów pewnego standardu jakości [3].

Wymagaj od Developerów dotrzymywania uzgodnień i zobowiązań. Cele Sprintów powinny być osiągane poprzez wytwarzanie wartościowych Przyrostów zgodnie z Definicją Ukończenia. Pamiętaj, jednak że potknięcia będą się zdarzały. Pojedyncze Cele Sprintów nie będą osiągane.

W tych sytuacjach bądź wyrozumiały. Wszystko co dzieje się w obrębie Zespołu musi odbywać się z poszanowaniem drugiego człowieka. Jeżeli zbyt często nie udaje się dostarczać oczekiwanych wysokich standardów, podczas Retrospektywy wspólnie wypracujcie rozwiązania. Dokonujcie inspekcji i adaptujcie się, by poprawić sytuację!

7. Badź tarczą dla Zespołu

Bardzo ważną umiejętnością w pracy każdego Product Ownera jest mówienia „nie”. Beneficjentem każdego razu, w którym PO powie „nie”, będzie nie tylko Produkt, ale również Zespół. Będzie to bowiem pozwalało Developerom na utrzymanie skupienia. Za każdym razem, gdy PO krytycznie rozważy i odrzuci prośbę Interesariusza o pilne zajęcie się nowym tematem, chroni Zespół przed bolesnymi i angażującymi zmianami kontekstu.

Podsumowanie

Symbioza między Product Ownerem z Developerami jest kluczowa dla tworzenia dobrych Produktów. Będąc częścią niehierarchicznego Zespołu interakcje między osobami pełniącymi te role powinny być ukierunkowana na współpracę i dążenie do osiągnięcia wspólnych celów. Postawa Product Ownera ma dla tej współpracy kolosalne znaczenie. Istotne jest bycie aktywnym członkiem Zespołu grającym według zasad Wartości Scruma, ukazywanie sensu pracy i wspólne kreowanie rozwiązań. Product Owner będzie wymagał jakości, a kiedy trzeba chronił Zespół przed rozproszeniami.