{"id":3064,"date":"2018-08-13T06:00:19","date_gmt":"2018-08-13T04:00:19","guid":{"rendered":"http:\/\/jacekwieczorek.agony.webd.pl\/?p=3064"},"modified":"2023-12-29T23:45:37","modified_gmt":"2023-12-29T22:45:37","slug":"jak-scrum-master-wspolpracuje-z-product-ownerem","status":"publish","type":"post","link":"https:\/\/jacekwieczorek.pl\/blog\/jak-scrum-master-wspolpracuje-z-product-ownerem\/","title":{"rendered":"Jak Scrum Master wsp\u00f3\u0142pracuje z Product Ownerem?"},"content":{"rendered":"

Pisa\u0142em w ostatnim wpisie<\/a> o tym, jak niew\u0142a\u015bciwe zrozumienie s\u0142owa coaching, mo\u017ce mie\u0107 negatywny wp\u0142yw na relacj\u0119 pomi\u0119dzy Product Ownerem a Scrum Masterem. Zaproponowa\u0142em te\u017c bardzo og\u00f3lnie kilka pomys\u0142\u00f3w na to, jak te dwie role mog\u0105 wsp\u00f3\u0142pracowa\u0107 ze sob\u0105. W dzisiejszym wpisie chcia\u0142bym rozwin\u0105\u0107 te punkty o konkrety, kt\u00f3re przedstawi\u0105, jak mo\u017ce taka wsp\u00f3\u0142praca wygl\u0105da\u0107 w praktyce.<\/p>\n

Ca\u0142o\u015b\u0107 opieram na moich moich w\u0142asnych do\u015bwiadczeniach wsp\u00f3\u0142pracy z Product Ownerami jako Scrum Master<\/a> oraz Agile Coach<\/a>.<\/p>\n

Na czym mo\u017ce polega\u0107 taka wsp\u00f3\u0142praca?<\/p>\n

#1 Budowanie partnerskiej relacji opartej na zaufaniu<\/h2>\n

Zaufanie mo\u017cna zdefiniowa\u0107 na wiele sposob\u00f3w. Do mnie osobi\u015bcie przemawia prosty wz\u00f3r z ksi\u0105\u017cki \u201cTrusted Advisor\u201d<\/a>. Wg. tego wzoru, na to, czy ludzie nam ufaj\u0105, ma wp\u0142yw iloczyn naszej wiarygodno\u015bci, niezawodno\u015bci oraz blisko\u015bci (takiej biznesowej oczywi\u015bcie) podzielony przez to, jak bardzo skupiamy si\u0119 na sobie. To co m\u00f3wimy, jak si\u0119 zachowujemy oraz jak ludzie si\u0119 przy nas czuj\u0105, ma wp\u0142yw na budowanie zaufania<\/strong>.<\/p>\n

Przyk\u0142ad:<\/span> je\u017celi obiecuj\u0119 Product Ownerowi, \u017ce pode\u015bl\u0119 mu do ko\u0144ca dnia link do artyku\u0142u, o kt\u00f3rym wcze\u015bniej rozmawiali\u015bmy, to terminowa realizacja tej obietnicy zgodnie z ustaleniami, buduje zaufanie (niezawodno\u015b\u0107). Je\u015bli natomiast proponuj\u0119 u\u017cycie nowej techniki tylko dlatego, \u017ce prywatnie chc\u0119 j\u0105 pozna\u0107 \u2014 a nie po to, aby pom\u00f3c Product Ownerowi \u2014 to takie zachowanie mo\u017ce nadszarpywa\u0107 zaufanie (skupienie si\u0119 na sobie).<\/p>\n

#2 Obustronna wymiana do\u015bwiadcze\u0144 oraz punkt\u00f3w widzenia<\/h2>\n

Zwykle na pocz\u0105tku taka wymiana wyst\u0119puje w formie spotka\u0144 1:1. Z czasem przeradza si\u0119 to w mniej formaln\u0105 wsp\u00f3\u0142prac\u0119, kt\u00f3r\u0105 trudniej wsadzi\u0107 w jakie\u015b konkretne ramy. Zwykle zar\u00f3wno Scrum Master jak i Product Owner maj\u0105 baga\u017c ciekawych do\u015bwiadcze\u0144 zwi\u0105zanych z rolami, kt\u00f3re wcze\u015bniej pe\u0142nili oraz z firmami, w kt\u00f3rych wcze\u015bniej pracowali. Tego rodzaju wymiana jest zwykle kontekstowa – gdy kt\u00f3ra\u015b z os\u00f3b widzi sensown\u0105 okazj\u0119, aby podzieli\u0107 si\u0119 do\u015bwiadczeniem lub punktem widzenia, to po prostu to robi.<\/p>\n

Przyk\u0142ad:<\/span> ostatnio dzieli\u0142em si\u0119 z pocz\u0105tkuj\u0105cym Product Ownerem swoim do\u015bwiadczeniem w temacie mo\u017cliwych sposob\u00f3w zarz\u0105dzania Backlogiem Produktu. Sam z kolei ch\u0119tnie wys\u0142ucha\u0142em jego opowie\u015bci o meandrach komunikacji ze stakeholderami.<\/p>\n

#3 Dzielenie si\u0119 informacj\u0105 zwrotn\u0105<\/h2>\n

Je\u015bli chodzi o informacj\u0119 zwrotn\u0105 po wydarzeniach w Scrumie, to mam ca\u0142kiem dobrze wypracowany nawyk rozmawiania z Product Ownerem bezpo\u015brednio po wydarzeniu\/wydarzeniach lub w miar\u0119 bezpo\u015brednio po nich. Pisz\u0119 konkretnie o wydarzeniach, bo na bazie moich do\u015bwiadcze\u0144 jest to miejsce, gdzie mo\u017cna zaobserwowa\u0107 du\u017co ciekawych zachowa\u0144, kt\u00f3re warto w nast\u0119pnym kroku om\u00f3wi\u0107. Oczywi\u015bcie zwyk\u0142a praca w przestrzeni zespo\u0142u jest r\u00f3wnie warto\u015bciowa, je\u015bli chodzi o generowanie okazji do podzielenia si\u0119 informacj\u0105 zwrotn\u0105.<\/p>\n

Przyk\u0142ad:<\/span> niedawno wspomnia\u0142em Product Ownerowi, \u017ce spos\u00f3b, w jaki przekazywa\u0142 informacje o dalszych planach rozwoju produktu (w bardzo wizualny spos\u00f3b), trafia\u0142 w moj\u0105 potrzeb\u0119 jasno\u015bci tego, co wydarzy si\u0119 w przysz\u0142o\u015bci.<\/p>\n

#4 Wzmacnianie otwartej komunikacji w Zespole Scrumowym<\/h2>\n

Osobi\u015bcie traktuj\u0119 Scrum Master\u00f3w oraz Product Owner\u00f3w jako osoby, kt\u00f3re swoim zachowaniem powinny dawa\u0107 przyk\u0142ad innym. Na bazie moich do\u015bwiadcze\u0144, pierwsze efekty staj\u0105 si\u0119 widoczne, gdy cho\u0107by jedna z tych r\u00f3l propaguje zachowania warte na\u015bladowania. Wzmocnienie takich zachowa\u0144, poprzez komentowanie ich na meta poziomie (\u201cPrzed chwil\u0105 powiedzia\u0142em Wam o X, bo zale\u017cy mi, \u017ceby Y i Z\u2026\u201d), mo\u017ce zwi\u0119ksza\u0107 skuteczno\u015b\u0107 takich dzia\u0142a\u0144.<\/p>\n

Przyk\u0142ad<\/span>: kiedy widz\u0119, \u017ce w zespole, kt\u00f3ry wspieram, co\u015b mog\u0142oby dzia\u0142a\u0107 lepiej, m\u00f3wi\u0119 o tym g\u0142o\u015bno i otwarcie do wszystkich, zamiast narzeka\u0107 na to w kuchni. Inny przyk\u0142ad, kt\u00f3rego do\u015bwiadczy\u0142em: Product Owner otwarcie, przy ca\u0142ym zespole, powiedzia\u0142 co my\u015bli o opowiadaniu hermetycznych \u017cart\u00f3w w przestrzeni zespo\u0142u oraz powiedzia\u0142, dlaczego nie czuje si\u0119 tym dobrze.<\/p>\n

#5 Wsp\u00f3\u0142praca podczas wydarze\u0144 w Scrumie<\/h2>\n

Zar\u00f3wno Scrum Master jak i Product Owner maj\u0105 konkretn\u0105 prac\u0119 do wykonania podczas wydarze\u0144 w Scrumie. To co sprawdzi\u0142o mi si\u0119 wielokrotnie, to ustalenie na starcie, jak nasze role mog\u0142yby wygl\u0105da\u0107 podczas spotka\u0144. Zwykle ustalenia oscylowa\u0142y w ok\u00f3\u0142 tego, \u017ce jako Scrum Master b\u0119d\u0119 pomaga\u0142 zespo\u0142owi sprawnie przeprowadzi\u0107 spotkanie, natomiast Product Owner b\u0119dzie dostarcza\u0142 wsad produktowy do rozm\u00f3w. Podczas samego wydarzenia wsp\u00f3\u0142praca zwykle polega na realizacji wcze\u015bniejszych ustale\u0144, rozszerzona o cz\u0119sty, \u201ckontrolny\u201d kontakt wzrokowy oraz bie\u017c\u0105c\u0105, s\u0142own\u0105 wymian\u0119 obserwacji.<\/p>\n

Przyk\u0142ad<\/span>: przed ka\u017cdym wydarzeniem spotykam si\u0119 lub zdzwaniam z Product Ownerem, aby om\u00f3wi\u0107 zar\u00f3wno og\u00f3lne jak i szczeg\u00f3\u0142owe cele spotkania oraz og\u00f3lny plan tego, jak mog\u0142oby takie wydarzenie wygl\u0105da\u0107.<\/p>\n

#6 Dobieranie narz\u0119dzi wspieraj\u0105cych prac\u0119 na produktem<\/h2>\n

Ka\u017cdy temat produktowy mo\u017cna mo\u017cna ugry\u017a\u0107 r\u00f3\u017cnymi technikami. St\u0105d wcze\u015bniej warto porozmawia\u0107 i ustali\u0107, co mog\u0142oby najlepiej zadzia\u0142a\u0107 w danym kontek\u015bcie. Tutaj znowu k\u0142aniaj\u0105 si\u0119 wcze\u015bniejsze do\u015bwiadczenia \u2014 zar\u00f3wno Scrum Mastera jak i Product Ownera \u2014 kt\u00f3re warto om\u00f3wi\u0107. Co zadzia\u0142a\u0142o? Co nie zadzia\u0142a\u0142o? Czego zabrak\u0142o? Co mo\u017cna by by\u0142o zrobi\u0107 lepiej? A mo\u017ce warto spr\u00f3bowa\u0107 jakiego\u015b nowego podej\u015bcia\/techniki?<\/p>\n

Przyk\u0142ad<\/span>: narz\u0119dzie, kt\u00f3re ostatnio zaproponowa\u0142em Product Ownerowi, by\u0142o technik\u0105 priorytetyzowania Backlogu Produktu, opieraj\u0105c\u0105 si\u0119 na macierzy koszt\/warto\u015b\u0107.<\/p>\n

#7 Wspieranie wa\u017cnych moment\u00f3w w \u017cyciu zespo\u0142u<\/h2>\n

Taki moment mo\u017ce by\u0107 zwi\u0105zany z odej\u015bciem osoby z zespo\u0142u, do\u0142\u0105czeniem nowej osoby, udanego wdro\u017cenia produktu czy te\u017c otrzymania krytycznej informacji zwrotnej od u\u017cytkownik\u00f3w produktu. Tego rodzaju sytuacje zwykle w pierwszej kolejno\u015bci wst\u0119pnie omawiam z Product Ownerem, aby wymieni\u0107 si\u0119 punktami widzenia oraz ustali\u0107 pierwsze opcje dotycz\u0105ce kolejnych ruch\u00f3w.<\/p>\n

Przyk\u0142ad<\/span>: to, co zwykle robi\u0119 w takich momentach, niezale\u017cnie od ustale\u0144 z Product Ownerem, to kreuj\u0119 przestrze\u0144 dla zespo\u0142u na om\u00f3wienie tego konkretnego tematu. Raz, \u017ce cz\u0119sto jest to pewnego rodzaju \u201cwentyl bezpiecze\u0144stwa\u201d, dwa \u2014 cz\u0119sto takie rozmowy prowadz\u0105 do konkretnych wniosk\u00f3w i powi\u0105zanych z nimi akcji usprawniaj\u0105cych prac\u0119 i organizacj\u0119 zespo\u0142u.<\/p>\n

#8 Wsp\u00f3lne omawianie trudnych moment\u00f3w w trakcie prac nad produktem<\/h2>\n

Punkt powi\u0105zany z powy\u017cszym, jednak w tym przypadku rozmowa ma cz\u0119sto charakter \u201cwygadania si\u0119\u201d i \u201cwyrzucenia z siebie\u201d, co daje komfort psychiczny i pomaga pouk\u0142ada\u0107 my\u015bli. Je\u015bli to Product Owner inicjuje tak\u0105 rozmow\u0119, to zwykle pytam w takim momencie, czego si\u0119 spodziewa po rozmowie ze mn\u0105: po prostu bycia wys\u0142uchanym, informacji zwrotnej, us\u0142yszenia o moich do\u015bwiadczeniach na omawianym polu, otrzymania dobrych pyta\u0144 czy po prostu zwyk\u0142ej porady.<\/p>\n

Przyk\u0142ad<\/span>: ostatnio, b\u0119d\u0105c w roli Agile Coacha, odby\u0142em rozmow\u0119 z Product Ownerem, kt\u00f3ry chcia\u0142 om\u00f3wi\u0107 temat jego decyzyjno\u015bci oraz umocowania w organizacji. Podzieli\u0142em si\u0119 z nim swoimi do\u015bwiadczeniami z podobnych sytuacji.<\/p>\n

#9 Wzmacnianie \u015bwiadomo\u015bci procesowej oraz produktowej w zespole<\/h2>\n

Zdarza\u0142o mi si\u0119 wspiera\u0107 zespo\u0142y, kt\u00f3re nie mia\u0142 komfortu posiada zar\u00f3wno Scrum Mastera jak i Product Ownera jednocze\u015bnie. Je\u017celi brakowa\u0142o Scrum Mastera, to zwykle cierpia\u0142y na tym aspekty procesowe, brakowa\u0142o ci\u0105g\u0142o\u015bci w usprawnianiu si\u0119 czy te\u017c odwa\u017cnego nazywania rzeczy po imieniu (\u201cpiszemy dziadowski kod\u201d, \u201cnie przyk\u0142adamy si\u0119 do wdro\u017ce\u0144\u201d). Z kolei brak Product Ownera zwykle prowadzi\u0142 do braku wiedzy na temat wizji produktu w zespole, niejasno\u015bci co do dalszego rozwoju produktu, b\u0105d\u017a nie zrozumienia, w jaki spos\u00f3b u\u017cytkownicy korzystaj\u0105 z produktu. Posiadanie obu tych r\u00f3l jednocze\u015bnie i \u015bwiadome adresowanie luk w wiedzy, narz\u0119dziach oraz nawyk\u00f3w Zespo\u0142u Scrumowego to co\u015b, nad czym Scrum Master oraz Produkt Owner mog\u0105 wsp\u00f3lnie pracowa\u0107 i wdra\u017ca\u0107 te zmiany w \u017cycie.<\/p>\n

Przyk\u0142ad<\/span>: pracuj\u0105c z zespo\u0142em klienta, wzi\u0105\u0142em udzia\u0142 w ich Codziennym Scrumie. Po spotkaniu podzieli\u0142em si\u0119 swoimi obserwacjami i zmoderowa\u0142em rozmow\u0119 o tym, co pomog\u0142o by im usprawni\u0107 to spotkanie w przysz\u0142o\u015bci.<\/p>\n

#10 Promowanie warto\u015bci poprzez \u017cycie w zgodzie z nimi na co dzie\u0144<\/h2>\n

O warto\u015bciach w codziennej pracy du\u017co si\u0119 m\u00f3wi (konferencje, wpisy na blogach, plakaty promuj\u0105ce warto\u015bci na korytarzach oraz wszelkiego rodzaju gad\u017cety takie jak naklejki czy kubki), jednak do niczego to nie prowadzi, je\u015bli te warto\u015bci nie towarzysz\u0105 nam w codziennym funkcjonowaniu w firmie. Widz\u0119 rol\u0119 Scrum Mastera oraz Product Ownera jako domy\u015blnych ambasador\u00f3w wykorzystywania warto\u015bci scrumowych w praktyce.<\/p>\n

Przyk\u0142ad:<\/span> jako Scrum Master, m\u00f3j szacunek do innych mog\u0119 objawia\u0107 poprzez nie sp\u00f3\u017anianie si\u0119 na Planowanie Sprintu, bo dbam o czas innych. Z kolei Product Owner mo\u017ce manifestowa\u0107 swoj\u0105 otwarto\u015b\u0107 poprzez aktywne s\u0142uchanie pomys\u0142\u00f3w zespo\u0142u, co do dalszego rozwoju produktu.<\/p>\n

#11 Nazywanie rzeczy takimi jakimi s\u0105<\/h2>\n

Uwa\u017cam, \u017ce dojrza\u0142y Zesp\u00f3\u0142 Scrumowy nazywa rzeczy po imieniu. Przyk\u0142adowo, je\u017celi Cel Sprintu<\/a> nie zosta\u0142 osi\u0105gni\u0119ty, to warto o tym powiedzie\u0107 g\u0142o\u015bno, nazwa\u0107 problem, przeanalizowa\u0107 go i poszuka\u0107 sposob\u00f3w unikni\u0119cia podobnych sytuacji w przysz\u0142o\u015bci. Je\u015bli Zesp\u00f3\u0142 Deweloperski tego nie robi, to zawsze pozostaje nam bezpiecznik w postaci Scrum Mastera oraz Product Ownera. Oczywi\u015bcie, warto takie zachowania om\u00f3wi\u0107 przy okazji ustalania zasad wsp\u00f3\u0142pracy, nie mniej je\u015bli takie ustalenia nie powsta\u0142y wcze\u015bniej, to mo\u017cna chocia\u017cby udzieli\u0107 wsparcia w postaci nie torpedowania ruch\u00f3w drugiej strony.<\/p>\n

Przyk\u0142ad<\/span>: czasem jako Agile Coach spotykam si\u0119 z sytuacj\u0105 w kt\u00f3rej Product Ownera nazywa rzeczy po imieniu (\u201ctrzeci raz z rz\u0119du nie zrealizowali\u015bmy Celu Sprintu\u201d), a dzieje si\u0119 to w akompaniamencie pr\u00f3b (nies\u0142usznego) wybielania zespo\u0142u ze strony Scrum Mastera.<\/p>\n

Podsumowuj\u0105c…<\/h2>\n

Kilka lu\u017anych my\u015bli, niekoniecznie merytorycznych:<\/p>\n