Pisałem w ostatnim wpisie o tym, jak niewłaściwe zrozumienie słowa coaching, może mieć negatywny wpływ na relację pomiędzy Product Ownerem a Scrum Masterem. Zaproponowałem też bardzo ogólnie kilka pomysłów na to, jak te dwie role mogą współpracować ze sobą. W dzisiejszym wpisie chciałbym rozwinąć te punkty o konkrety, które przedstawią, jak może taka współpraca wyglądać w praktyce.
Całość opieram na moich moich własnych doświadczeniach współpracy z Product Ownerami jako Scrum Master oraz Agile Coach.
Na czym może polegać taka współpraca?
#1 Budowanie partnerskiej relacji opartej na zaufaniu
Zaufanie można zdefiniować na wiele sposobów. Do mnie osobiście przemawia prosty wzór z książki “Trusted Advisor”. Wg. tego wzoru, na to, czy ludzie nam ufają, ma wpływ iloczyn naszej wiarygodności, niezawodności oraz bliskości (takiej biznesowej oczywiście) podzielony przez to, jak bardzo skupiamy się na sobie. To co mówimy, jak się zachowujemy oraz jak ludzie się przy nas czują, ma wpływ na budowanie zaufania.
Przykład: jeżeli obiecuję Product Ownerowi, że podeślę mu do końca dnia link do artykułu, o którym wcześniej rozmawialiśmy, to terminowa realizacja tej obietnicy zgodnie z ustaleniami, buduje zaufanie (niezawodność). Jeśli natomiast proponuję użycie nowej techniki tylko dlatego, że prywatnie chcę ją poznać — a nie po to, aby pomóc Product Ownerowi — to takie zachowanie może nadszarpywać zaufanie (skupienie się na sobie).
#2 Obustronna wymiana doświadczeń oraz punktów widzenia
Zwykle na początku taka wymiana występuje w formie spotkań 1:1. Z czasem przeradza się to w mniej formalną współpracę, którą trudniej wsadzić w jakieś konkretne ramy. Zwykle zarówno Scrum Master jak i Product Owner mają bagaż ciekawych doświadczeń związanych z rolami, które wcześniej pełnili oraz z firmami, w których wcześniej pracowali. Tego rodzaju wymiana jest zwykle kontekstowa – gdy któraś z osób widzi sensowną okazję, aby podzielić się doświadczeniem lub punktem widzenia, to po prostu to robi.
Przykład: ostatnio dzieliłem się z początkującym Product Ownerem swoim doświadczeniem w temacie możliwych sposobów zarządzania Backlogiem Produktu. Sam z kolei chętnie wysłuchałem jego opowieści o meandrach komunikacji ze stakeholderami.
#3 Dzielenie się informacją zwrotną
Jeśli chodzi o informację zwrotną po wydarzeniach w Scrumie, to mam całkiem dobrze wypracowany nawyk rozmawiania z Product Ownerem bezpośrednio po wydarzeniu/wydarzeniach lub w miarę bezpośrednio po nich. Piszę konkretnie o wydarzeniach, bo na bazie moich doświadczeń jest to miejsce, gdzie można zaobserwować dużo ciekawych zachowań, które warto w następnym kroku omówić. Oczywiście zwykła praca w przestrzeni zespołu jest równie wartościowa, jeśli chodzi o generowanie okazji do podzielenia się informacją zwrotną.
Przykład: niedawno wspomniałem Product Ownerowi, że sposób, w jaki przekazywał informacje o dalszych planach rozwoju produktu (w bardzo wizualny sposób), trafiał w moją potrzebę jasności tego, co wydarzy się w przyszłości.
#4 Wzmacnianie otwartej komunikacji w Zespole Scrumowym
Osobiście traktuję Scrum Masterów oraz Product Ownerów jako osoby, które swoim zachowaniem powinny dawać przykład innym. Na bazie moich doświadczeń, pierwsze efekty stają się widoczne, gdy choćby jedna z tych ról propaguje zachowania warte naśladowania. Wzmocnienie takich zachowań, poprzez komentowanie ich na meta poziomie (“Przed chwilą powiedziałem Wam o X, bo zależy mi, żeby Y i Z…”), może zwiększać skuteczność takich działań.
Przykład: kiedy widzę, że w zespole, który wspieram, coś mogłoby działać lepiej, mówię o tym głośno i otwarcie do wszystkich, zamiast narzekać na to w kuchni. Inny przykład, którego doświadczyłem: Product Owner otwarcie, przy całym zespole, powiedział co myśli o opowiadaniu hermetycznych żartów w przestrzeni zespołu oraz powiedział, dlaczego nie czuje się tym dobrze.
#5 Współpraca podczas wydarzeń w Scrumie
Zarówno Scrum Master jak i Product Owner mają konkretną pracę do wykonania podczas wydarzeń w Scrumie. To co sprawdziło mi się wielokrotnie, to ustalenie na starcie, jak nasze role mogłyby wyglądać podczas spotkań. Zwykle ustalenia oscylowały w okół tego, że jako Scrum Master będę pomagał zespołowi sprawnie przeprowadzić spotkanie, natomiast Product Owner będzie dostarczał wsad produktowy do rozmów. Podczas samego wydarzenia współpraca zwykle polega na realizacji wcześniejszych ustaleń, rozszerzona o częsty, “kontrolny” kontakt wzrokowy oraz bieżącą, słowną wymianę obserwacji.
Przykład: przed każdym wydarzeniem spotykam się lub zdzwaniam z Product Ownerem, aby omówić zarówno ogólne jak i szczegółowe cele spotkania oraz ogólny plan tego, jak mogłoby takie wydarzenie wyglądać.
#6 Dobieranie narzędzi wspierających pracę na produktem
Każdy temat produktowy można można ugryźć różnymi technikami. Stąd wcześniej warto porozmawiać i ustalić, co mogłoby najlepiej zadziałać w danym kontekście. Tutaj znowu kłaniają się wcześniejsze doświadczenia — zarówno Scrum Mastera jak i Product Ownera — które warto omówić. Co zadziałało? Co nie zadziałało? Czego zabrakło? Co można by było zrobić lepiej? A może warto spróbować jakiegoś nowego podejścia/techniki?
Przykład: narzędzie, które ostatnio zaproponowałem Product Ownerowi, było techniką priorytetyzowania Backlogu Produktu, opierającą się na macierzy koszt/wartość.
#7 Wspieranie ważnych momentów w życiu zespołu
Taki moment może być związany z odejściem osoby z zespołu, dołączeniem nowej osoby, udanego wdrożenia produktu czy też otrzymania krytycznej informacji zwrotnej od użytkowników produktu. Tego rodzaju sytuacje zwykle w pierwszej kolejności wstępnie omawiam z Product Ownerem, aby wymienić się punktami widzenia oraz ustalić pierwsze opcje dotyczące kolejnych ruchów.
Przykład: to, co zwykle robię w takich momentach, niezależnie od ustaleń z Product Ownerem, to kreuję przestrzeń dla zespołu na omówienie tego konkretnego tematu. Raz, że często jest to pewnego rodzaju “wentyl bezpieczeństwa”, dwa — często takie rozmowy prowadzą do konkretnych wniosków i powiązanych z nimi akcji usprawniających pracę i organizację zespołu.
#8 Wspólne omawianie trudnych momentów w trakcie prac nad produktem
Punkt powiązany z powyższym, jednak w tym przypadku rozmowa ma często charakter “wygadania się” i “wyrzucenia z siebie”, co daje komfort psychiczny i pomaga poukładać myśli. Jeśli to Product Owner inicjuje taką rozmowę, to zwykle pytam w takim momencie, czego się spodziewa po rozmowie ze mną: po prostu bycia wysłuchanym, informacji zwrotnej, usłyszenia o moich doświadczeniach na omawianym polu, otrzymania dobrych pytań czy po prostu zwykłej porady.
Przykład: ostatnio, będąc w roli Agile Coacha, odbyłem rozmowę z Product Ownerem, który chciał omówić temat jego decyzyjności oraz umocowania w organizacji. Podzieliłem się z nim swoimi doświadczeniami z podobnych sytuacji.
#9 Wzmacnianie świadomości procesowej oraz produktowej w zespole
Zdarzało mi się wspierać zespoły, które nie miał komfortu posiada zarówno Scrum Mastera jak i Product Ownera jednocześnie. Jeżeli brakowało Scrum Mastera, to zwykle cierpiały na tym aspekty procesowe, brakowało ciągłości w usprawnianiu się czy też odważnego nazywania rzeczy po imieniu (“piszemy dziadowski kod”, “nie przykładamy się do wdrożeń”). Z kolei brak Product Ownera zwykle prowadził do braku wiedzy na temat wizji produktu w zespole, niejasności co do dalszego rozwoju produktu, bądź nie zrozumienia, w jaki sposób użytkownicy korzystają z produktu. Posiadanie obu tych ról jednocześnie i świadome adresowanie luk w wiedzy, narzędziach oraz nawyków Zespołu Scrumowego to coś, nad czym Scrum Master oraz Produkt Owner mogą wspólnie pracować i wdrażać te zmiany w życie.
Przykład: pracując z zespołem klienta, wziąłem udział w ich Codziennym Scrumie. Po spotkaniu podzieliłem się swoimi obserwacjami i zmoderowałem rozmowę o tym, co pomogło by im usprawnić to spotkanie w przyszłości.
#10 Promowanie wartości poprzez życie w zgodzie z nimi na co dzień
O wartościach w codziennej pracy dużo się mówi (konferencje, wpisy na blogach, plakaty promujące wartości na korytarzach oraz wszelkiego rodzaju gadżety takie jak naklejki czy kubki), jednak do niczego to nie prowadzi, jeśli te wartości nie towarzyszą nam w codziennym funkcjonowaniu w firmie. Widzę rolę Scrum Mastera oraz Product Ownera jako domyślnych ambasadorów wykorzystywania wartości scrumowych w praktyce.
Przykład: jako Scrum Master, mój szacunek do innych mogę objawiać poprzez nie spóźnianie się na Planowanie Sprintu, bo dbam o czas innych. Z kolei Product Owner może manifestować swoją otwartość poprzez aktywne słuchanie pomysłów zespołu, co do dalszego rozwoju produktu.
#11 Nazywanie rzeczy takimi jakimi są
Uważam, że dojrzały Zespół Scrumowy nazywa rzeczy po imieniu. Przykładowo, jeżeli Cel Sprintu nie został osiągnięty, to warto o tym powiedzieć głośno, nazwać problem, przeanalizować go i poszukać sposobów uniknięcia podobnych sytuacji w przyszłości. Jeśli Zespół Deweloperski tego nie robi, to zawsze pozostaje nam bezpiecznik w postaci Scrum Mastera oraz Product Ownera. Oczywiście, warto takie zachowania omówić przy okazji ustalania zasad współpracy, nie mniej jeśli takie ustalenia nie powstały wcześniej, to można chociażby udzielić wsparcia w postaci nie torpedowania ruchów drugiej strony.
Przykład: czasem jako Agile Coach spotykam się z sytuacją w której Product Ownera nazywa rzeczy po imieniu (“trzeci raz z rzędu nie zrealizowaliśmy Celu Sprintu”), a dzieje się to w akompaniamencie prób (niesłusznego) wybielania zespołu ze strony Scrum Mastera.
Podsumowując…
Kilka luźnych myśli, niekoniecznie merytorycznych:
- Istnieje wiele lepszych sposobów na współpracę Scrum Mastera z Product Ownerem niż „mocne kołczowanie”
- Nie wyobrażam sobie dobrze działającego i usprawniającego się Zespołu Srcumowego, w którym Scrum Master i Product Owner nie współpracują
- Zasiadając do artykułu nie sądziłem, że urośnie do ponad 10 tys znaków, planowałem krótki wpis
- Dostrzegam jak bardzo pisanie pomaga mi poukładać sobie w głowie tematy, z których intuicyjnie i podświadomie korzystam na co dzień, ale gdyby ktoś z mnie zapytał z zaskoczenia o współpracę Scrum Mastera z Product Ownerem, to ta odpowiedź nie byłaby tak usystematyzowana, jak mogłem to zrobić na blogu
Dodatkowe materiały
Więcej o udanej współpracy tych dwóch ról możesz posłuchać w jedenastym odcinku podcastu Porządny Agile zatytułowanym 011 – Współpraca Scrum Mastera z Product Ownerem.
Photo by Andrew Palmer on Unsplash
