Współpraca Scrum Mastera z Product Ownerem

Współpraca Scrum Mastera z Product Ownerem jest ważnym aspektem pracy w Scrumie. W tym odcinku wskazujemy, dlaczego brak współpracy może być problemem oraz podsuwamy konkretne przykłady, jak może wyglądać modelowa współpraca tych dwóch ról.

Dlaczego współpraca Właściciela Produktu i Scrum Mastera jest istotnym elementem procesu zwinnego? Jakie problemy mogą się tu pojawić i jak można je rozwiązać?

Temat współpracy Właściciela Produktu, czyli Product Ownera, i Scrum Mastera wydaje się prosty. Jest on również opisany w Przewodniku po Scrumie. Jednak w trakcie naszej pracy, jako Agile Coache oraz w mailach otrzymujemy wiele pytań dotyczących tego zagadnienia i w związku z tym postanowiliśmy o tym opowiedzieć więcej.

Problemy wynikające z braku współpracy Product Ownera i Scrum Mastera?

Brak współpracy między Właścicielem Produktu a Scrum Masterem może być efektem przypadku, gdzie w sposób zupełnie niezaplanowany Product Owner nie rozmawia ze Scrum Masterem. Inny scenariusz jest taki, że ze strony Product Ownera pojawia się ignorancja dla tego, co robi Scrum Master, co może też działać w drugą stronę. W tym drugim przykładzie, siły, które mogą wspierać się wzajemnie i robić dużo dla Zespołów Scrumowych, będą się po prostu kanibalizować i nieść ze sobą straty dla całego procesu zwinnego.

Ten brak współpracy może wynikać też z braku uważności i wykorzystywania okazji do rozwijania pomysłów lub sugestii drugiej strony, przez co część energii Product Ownera i część energii Scrum Mastera, które mogłyby być połączone, rozmywają się i nie dają większych korzyści mimo istniejącego na to potencjału.

Nawet jeśli nie ma celowego działania przeciwko sobie czy sabotowania swoich decyzji, to nawet iluzoryczna współpraca między obiema rolami może powodować brak poczucia, że jako Zespół Scrumowy idziecie w jedną stronę.

Pracując z zespołami niejednokrotnie, widzimy potencjał zarówno w teamie deweloperów, jak i potencjał w roli Scrum Mastera i Product Ownera. Wszystko jest niby w porządku, ale przez to, że nie ma tego spoiwa i współpracy pomiędzy tymi dwoma rolami, zespół często traci taką tę możliwość przemnożenia efektów swojej pracy. Jeszcze nie spotkaliśmy sprawnego zespołu, w którym ta współpraca by nie zachodziła.  

Takim przykładem wzajemnego blokowania możliwości rozwoju czy wdrażania usprawnień w zespołach jest Story Mapping. Można go wykonać na bardzo podstawowym poziomie, rozkładając podróż użytkownika na serię kroków, przemyślenie możliwych opcji i wyciągnięcie z tego, takiej pierwszej wersji produktu. Jeśli jednak Scrum Master porozmawiałby wcześniej z Product Ownerem o celach biznesowych, to cały proces można by zacząć od właściwej strony, czyli od przemyślenia tego, co chcemy tak naprawdę osiągnąć. 

Dla Product Ownera, który ma dobrze przygotowanie biznesowe, ale wcześniej nie pracował w środowisku zwinny, to taki brak współpracy ze Scrum Masterem jest dużą stratą w kwestii edukacyjnej. Scrum Master może go wesprzeć w doborze narzędzi, podpowiedzieć jak pracować z Backlogiem Produktu itp. Takie wskazówki mogą znacznie przyspieszyć start Product Ownera w pracy w środowisku scrumowym. Oczywiście działa to też w drugą stronę i przy partnerskim podejściu również Scrum Master może nauczyć się wiele od Product Ownera. Stąd istotne jest zbudowanie więzi i zaufania między obiema rolami. 

Ostatnia rzecz, jaka nasuwa nam się w temacie problemów wynikających z braku współpracy Właściciela Produktu i Scrum Mastera jest brak wsparcia wzajemnego w promocji zwinności i wykorzystania tego zwinnego podejścia szerzej w organizacji. Wynika to z tego, że Product Owner często ma lepszy dostęp do managementu biznesowego, a Scrum Master często ma lepszy dostęp do managementu IT. Razem mają dostęp do kluczowych jednostek, a także łatwiej dostrzec im jakieś przeszkody lub lepsze rozwiązania i pomysły. Razem mają szersze spojrzenie na całą firmę.

Jak powinna wyglądać współpraca Product Ownera ze Scrum Masterem?

Przede wszystkim warto starać się zbudować partnerską relację. Dobrze, aby spędzali oni ze sobą więcej czasu i rozmawiali nie tylko podczas wydarzeń scrumowych, ale i poza nimi. Powinni oni czuć się swobodnie w swoim towarzystwie i wymieniać się obserwacjami, przemyśleniami i obawami. Z naszego doświadczenia, taka wymiana punktów widzenia ma pozytywny wpływ dla ich osobistego rozwoju, jak i dla efektów pracy całego zespołu.

Warto, aby oboje mieli świadomość wartości płynących z partnerskiej relacji i nie wykorzystywali rozmów do budowania jakiejś swojej przewagi lub dokarmiania ego. Otwarta i szczera postawa oraz poczucie, że jesteśmy teamem i gramy do tej samej bramki, będzie bardzo wspierać Zespół Scrumowy w codziennej pracy.

Najlepiej jest ustalić cykliczne spotkania, np. co tydzień w środę spotykacie się na godzinę i wymieniacie obserwacje oraz przegadujecie tematy zebrane podczas tego tygodnia. Może się tak zdarzyć, że godzina nie wystarczy na poruszenie zebranych przez obie strony zagadnień, dlatego wówczas warto dokończyć spotkanie następnego dnia lub pozwolić sobie na przedłużenie obecnego. 

Dodatkowo warto wygospodarować trochę czasu na rozmowę przed i po każdym wydarzeniu w Scrumie. Pozwoli to Wam przygotować plan spotkania uwzględniający potrzeby obu stron, a także wymienić się przemyśleniami po spotkaniu z zespołem. 

Oczywiście oprócz tych cyklicznych spotkań, taka współpraca ad hoc, również wchodzi w grę, a wręcz odradzamy sztywnej postawy typu “mamy ustalone terminy spotkań i tylko wtedy rozmawiamy”. Zachęcamy wszystkich do ustalenia z drugą stroną, jaką formę współpracy preferujecie, na co jesteście otwarci, a czego wolelibyście unikać, bo np. wybija Was z rytmu pracy. Spontaniczność spotkań jest jak najbardziej w porządku, jeśli tylko odpowiada obu stronom. Pewnym rozwiązaniem pośrednim, gdy zachodzi potrzeba szybkiego omówienia czegoś, jest np. wspólny lunch, który będzie też okazją do lepszego poznania się i jakiejś luźnej rozmowy wzmacniającą relację.

Wspominaliśmy powyżej o spotkaniach Product Ownera i Scrum Mastera przed wydarzeniam scrumowymi. Chcemy podkreślić wagę tych spotkań, gdyż wiemy, że z czasem, gdy czujemy się już bardzo pewnie i wkrada się pewna rutyna we współpracy, to często rezygnujemy z tych spotkań. Jednak zawsze warto znaleźć, chociaż te kilka minut, aby powiedzieć sobie, czego potrzebuje lub oczekuje Scrum Master, czego potrzebuje lub oczekuje Product Owner. Być może jedna ze stron chce poruszyć jakiś delikatny lub drażliwy temat i potrzebuje wsparcia oraz konkretnej postawy, a być może chce przetestować jakąś nową technikę, która wymaga więcej czasu. Dobrze to wszystko przedyskutować przed wydarzeniem scrumowym, żeby nie było zaskoczenia drugiej strony i żeby mieć też kompatybilnego sojusznika. 

Jako przykład przytoczymy sytuację, gdy Jacek będąc w roli Scrum Mastera, zauważył, że w zespole nie do końca uspójniona jest wizja produktu. Poprosił on wówczas Product Ownera, aby przy każdej możliwej okazji zaczynał od tej wizji, aby się uspójniła i utrwaliła wśród członków zespołu. Inny przykład to kiedy przed prezentacją złożonego problemu dostał on informację od Product Ownera, że może nie każdy to dobrze zrozumieć. Dzięki tej informacji  zastosował więcej technik wizualizacyjnych, częściej prosił o parafrazowanie tego, co powiedział, aby upewnić się, że wszyscy w zespole rozumieją temat w ten sam sposób.

Warto też podzielić się rolami i ustalić, kto za co będzie odpowiadać już podczas samego wydarzenia. Jest to szczególnie przydatne, jeśli np. na Sprint Review przychodzą jacyś ważni lub szczególnie trudni Interesariusze, z którymi rozmowa wymaga 100% skupienia. Wówczas, aby Product Owner mógł być nastawiony przede wszystkim na dyskusję z nimi, to dobrze, aby miał świadomość, że pilnowaniem czasu, prowadzeniem agendy i moderowaniem spotkania zajmuje się Scrum Master. Nie tylko sama rozmowa z Interesariuszami przebiegnie lepiej, będzie też mniej stresu i więcej korzyści dla całego zespołu. 

To dobry początek do modelowej długofalowej współpracy, w której Product Owner i Scrum Master jakby czytają sobie w myślach i czują, kiedy druga strona potrzebuje wsparcia, co oznacza skinienie czy jakiś konkretny sygnał. Rzecz w tym, że samo się to nie zadzieje i dlatego tak ważne są regularne spotkania, a także otwartość na szczery feedback.

W naszej ocenie Scrum Master i Product Owner najprawdopodobniej spędzają ze sobą najwięcej czasu w pracy i przez to najwięcej widzą, co robi druga strona, jak się zachowuje w konkretnych sytuacjach, co mówi lub jakie emocje przekazuje. Stąd też ta otwartość i przyzwolenie na obustronny feedback będzie nie tylko dobrą podstawą do rozwoju samych siebie, jak również do usprawniania procesów w zespole. 

Oczywiście wymaga to zaufania, szczerości, ale i traktowania siebie z szacunkiem i na równi.

Jak wypracować takie naturalne obustronne dawanie sobie nawzajem feedbacku, jeśli jeszcze tego nie ma? Najlepiej zacząć od siebie, prosząc o ten feedback. Jego dawanie możecie doszlifować poprzez parafrazowanie, co druga strona powiedziała, mówienie o odczuciach i znów, rozmowę, która już tyle razy została wspomniana.

Kolejnym elementem modelowej współpracy Product Ownera i Scrum Mastera mamy do czynienia w sytuacji, w której Product Owner wchodzi w rolę osoby, która podsuwa pewne potrzeby i pomysły, a Scrum Master wchodzi w rolę, która pomaga inspirować i podpowiadać rozwiązania. Przykładowo Product Owner może mieć potrzebę, żeby w czytelny sposób zaprezentować jakiś konkretny obszar Backlogu Produktu. Może się on z tym zwrócić do Scrum Mastera, który zapewne ma już jakieś sprawdzone techniki i zaproponuje jakieś konkretne rozwiązania. Mogą oni też zbudować coś nowego, bazując na ich doświadczeniach i przemyśleniach dotyczących tego konkretnego przypadku. Absolutnie nie ma tu miejsca na postawę wywyższającą się typu: “wiem najlepiej, trzeba zrobić tak i tak”. Podkreślamy jeszcze raz, ma być to inspirowanie i pomoc, a także wspólne wypracowywanie jeszcze lepszych rozwiązań.

Ostatnią naszą wskazówką do dobrej współpracy obu ról to wspólne rozmawianie o usprawnieniach. Mają oni trochę inne perspektywy i na co dzień skupiają się na innych rzeczach, dzięki czemu, zauważają też inne istotne elementy, np. na poziomie Zespołu Scrumowego. Jeśli Scrum Master zaprosi Product Ownera do rozmowy dotyczącej usprawnień, to otrzymają oni bardziej pełny obraz i wspólnie będą mogli dojść do lepszych wniosków oraz wypracowania lepszych rozwiązań. Ponadto nikt nie będzie miał poczucia, że Scrum Master wciąż coś narzuca. 

Takie podejście jest szczególnie istotne przy złożonych problemach, jak demotywacja w zespole, albo pogorszenie się jakości wytwarzanego produktu, gdzie często będzie trzeba przyjrzeć się więcej niż jednej kwestii. Product Owner może przejmie punkty stricte techniczne (np. priorytetyzacja elementów w Backlogu) lub uruchomienie kontaktów wśród interesariuszy, a Scrum Master skupi się np. na zmianie technik wykorzystywanych podczas Retrospektywy. 

Mamy nadzieję, że rozumiesz, dlaczego współpraca Product Ownera i Scrum Mastera jest tak ważna, i to nie tylko dla nich, ale dla całego zespołu i firmy. Chętnie poznamy też Twoje metody usprawniania tej relacji, aby usprawnić pracę i osiągać lepsze efekty. Podziel się nimi w komentarzu.  

W ramach materiałów dodatkowych, zachęcamy do przeczytania artykuł na blogu Jacka, w którym dzieli się swoim doświadczeniem, jak w praktyce może wyglądać współpraca Scrum Mastera z Product Ownerem.

Jeśli odcinek Ci się podobał, koniecznie podziel się nim z innymi osobami, które Twoim zdaniem mogą go potrzebować.

Sprawdź nasz webinar o dzieleniu elementów Backlogu Produktu na mniejsze elementy.

Transkrypcja podcastu „Współpraca Scrum Mastera z Product Ownerem”

Kuba: W dzisiejszym odcinku poruszymy temat współpracy Właściciela Produktu i Scrum Mastera. Ten temat teoretycznie dla niektórych jest prosty. Jest opisany w Przewodniku po Scrumie i co tu jeszcze, by o tym opowiadać. Natomiast gdyby nie to, że dostajemy dużo o to pytań, czy to w trakcie naszej pracy jako Agile Coach’e, czy też w mejlach od Was, to byśmy tego tematu nie poruszyli. Ale są pytania. Widocznie temat jest potrzebny. Myślę, że również zainspirujemy tematyką również tych, którzy czują, że ta współpraca przebiega całkiem nieźle. To w takim razie, jeśli mówimy o współpracy Product Ownera i Scrum Mastera, to dlaczego ta współpraca jest ważna? Gdzie tu w ogóle może się pojawić problem, jeśli ona nie przebiega tak idealnie, jak mogłaby?

Jacek: Myślę, że takim głównym problemem, który obserwuję, jeśli chodzi o współpracę tych dwóch ról, to jest takie, że jeśli te dwie role ze sobą nie współpracują, to ja mam zwykle takie przeczucie, że nie idziemy jako Zespół Scrumowy w jedną stronę. To tutaj, jakby ten problem może przybrać takie jakby dwa kierunki. Jeden to jest, że po prostu, przypadkowo, zupełnie w sposób taki niezaplanowany Właściciel Produktu nie rozmawia ze Scrum Masterem. Upraszczając na ten moment – nie współpracuje. No i po prostu pewne rzeczy, taki potencjał, który jest w zespole i tej współpracy, on po prostu nie jest eksplorowany. A taki gorszy przykład tego samego problemu, to jest sytuacja, w której zarówno po stronie Product Ownera może się pojawić jakaś taka ignorancja dla ruchów Scrum Mastera, jak i w drugą stronę. Scrum Master może świadomie ignorować pewne ruchy, pewne komunikaty, pewne akcje Product Ownera. No i tutaj jakby zaczynają się, nazwijmy to siły, które mogą zrobić bardzo dużo dla zespołów wzajemnie, jakoś tak kanibalizować. Nie dość, że tej współpracy nie ma, to jeszcze mam wrażenie, że czasem ten brak współpracy na podłożu lekkiej takiej ignorancji obowiązków drugiej roli, może powodować dla zespołu po prostu konkretne straty.

Kuba: Nawet jeśli nie ma tam świadomego sabotowania, czy takiego robienia sobie na złość, czy jakiegoś takiego wprowadzania swojego zdania na przekór drugiej stronie, no to też, chociaż możemy przegapiać okazje. Czyli no Product Owner ma właśnie ochotę na zrobienie trochę inaczej Backlogu, a Scrum Master w ogóle nie zauważa tego, że może miałoby to sens. I na odwrót, Scrum Master podpowiada, że może byśmy jakieś usprawnienie wprowadzili, a Product Owner w zasadzie zamyka temat, zanim się jeszcze rozgrzebał. Nie, wszystko jest super, zostaje tak, jak jest. No i zespół sobie tkwi w tym etapie. Być może nie wykorzystują okazji, albo nie idą wspólnie razem wspólnie łącząc te kierunki. Wspólnie łącząc te wektory. No albo trochę się rozmywają. Czyli część energii Ownera i część energii Scrum Mastera, które mogłyby być połączone, idą w taką stronę trochę marnowania się wzajemnie.

Jacek: To, co mówisz o tym marnowaniu, to myślę, jest bardzo widoczne. Pracując z zespołami, kiedy dołączam jako Agile Coach do zespołu, to bardzo często widzę potencjał w zespole developerskim. Widzę potencjał w roli Scrum Mastera. Widzę potencjał w roli Product Ownera, w sensie niby wszystko jest w porządku i to powinno grać, ale właśnie przez to, że nie ma tego spoiwa, czyli ta współpraca co najmniej między tymi dwoma rolami nie występuje, to moim zdaniem zespół po prostu traci taką tę możliwość przemnożenia efektów swojej pracy. Tak więc jakby odwracając tutaj jakby myśl. Nie widziałem jeszcze, czy nie miałem szansy pracować z zespołem, który byłby takim zespołem wybitnym, w którym ta współpraca by nie zachodziła.

Kuba: Innym problemem braku współpracy Ownera ze Scrum Masterem, to jest przypadek w sumie już użyty w przykładzie chwilę temu. Zespoły mogą podnosić jakość współpracy ze sobą, czy to poprzez jakieś nowe techniki, nowe podejścia. Ale ponieważ nie ma synchronizacji, nie ma wspólnej idei, nie ma przemyślenia tego, jak można by podjąć najbliższy kolejny krok usprawnieniowy w zespole, to się wzajemnie blokujemy. Przegapiamy okazję. Być może rezygnujemy z bardziej odważnych eksperymentów. Masz jakieś przykłady tego typu?

Jacek: Pierwszy, który mi przychodzi do głowy, to jest użycia Story Mappingu. Story Mapping można wykonać na takim bardzo podstawowym poziomie, czyli po prostu rozłożyć sobie tę podróż Użytkownika. Zastanowić się powiedzmy, jaka jest głębia tych konkretnych kroków. Jakie są opcje tych konkretnych kroków. Z tego można bardzo szybko sobie wyciąć coś, co powierzchownie nazwiemy, że to jest ta nasza pierwsza wersja produktu. No i tutaj jakby zakończyć. Potencjał jest tutaj niewykorzystany taki, że gdybyśmy wcześniej porozmawiali z Product Ownerem o tym, jakie ma cele biznesowe. Jakich rezultatów się spodziewa z naszej pracy. No z tej Story Mapy moglibyśmy wyciągnąć kompletnie inny poziom informacji. W ogóle zacząć od tego, co Product Owner chciałby osiągnąć. I dopiero na tej podstawie, na podstawie konkretnych celów, czy kierunków, zastanowić się, które kawałki z tej przygotowanej Story Mapy, będą realizować te potrzeby Product Ownera. Gdyby tylko to przegadać wcześniej, gdyby Scrum Master porozmawiał o tym z Product Ownerem, gdyby tylko w ogóle zaplanował w agencie spotkania czas na to, żeby powiedzieć – Słuchajcie, to są kierunki, w które idziemy z naszym produktem, no to jakby automatycznie Story Mapping zaczęlibyśmy od tej właściwej strony, czyli od zastanowienia się co my tak naprawdę chcemy osiągnąć. A tak, to po prostu zrobimy ćwiczenie. Pozornie się poczujemy, że jest fajnie. Coś uzyskaliśmy. No ale to nie jest to, co by to mogłoby być. Taki trochę zmarnowany potencjał.

Kuba: No ten Story Mapping to jest taka technika, która mi też przychodzi do głowy jako jedna z rzeczy, która jest bardzo potrzebna i bardzo przydatna. I ona jest, tak nazwę to z kanonu co najmniej średnio zaawansowanych. To już zwykłe siedzimy i gadamy. Tu jest i temat wizualizacji, temat zastanowienia się. Mocnego zaangażowania zespołu. Również Właściciel Produktu musi przyjść na taką sesję przyjść przygotowany. Jest wiele powodów, żeby go nie robić. Wiele powodów, żeby się zdecydować – Nie, to może za trudne. Może nie rozumiemy. Może za pierwszym razem nie wyjdzie nam tak dobrze, jaki jest potencjał w tym podejściu. I teraz wystarczy, że ze sobą nie współpracujemy, albo mamy jakieś wątpliwości, albo się trochę boimy, albo trochę się wzajemnie blokujemy, to będzie bardzo ciężko wprowadzić tę technikę. Bo Scrum Master nie przymoderuje jak trzeba. Owner nie zrozumie, nie przygotuje się, zastanowi się, zwątpi. Zespół też może będzie niezainteresowany i się nam rozsypie konstrukcja. Technika, która jest świetna, a akurat nam może się nie sprawdzić. Nie dlatego, że jest niedopasowana, tylko dlatego, że nie pogadaliśmy. Nie wprowadziliśmy tej techniki mądrze. Nie zrozumieliśmy jej. Nie przygotowaliśmy się. W toku też, już do wykonania jakiejś mapy, gdzieś tam ktoś się zgubił. Ktoś się zamyślił. Ktoś nie uważał. Albo niestety, tak jak mówiłeś, ktoś coś przysabotował. Zignorował jakąś uwagę, albo polecenie i wtedy nam nie wyjdzie. Nie ma szans.

Jacek: Kolejnym problemem, który może się pojawić w przypadku, gdy ta współpraca nie zachodzi, no to myślę, że w szczególności Product Ownerzy, którzy mają dobre przygotowanie biznesowe, ale wcześniej nie pracowali w środowisku zwinnym, no to jakby nie mając wypracowanej współpracy z Product Ownerem, automatycznie są odcięci od tego, że Scrum Master może ich wesprzeć w edukacji. I oczywiście mam tutaj na myśli w szczególności Scrum Mastera, który ma już doświadczenie praktyczne. No bo jeśli tak faktycznie jest, to Product Owner ma wiedzę biznesową, a Scrum Master jest w stanie pomóc w doborze narzędzi, doradzić, powiedzieć na przykład jak zacząć z tym Backlogiem Produktu, gdzie go przetrzymywać? Jak prioretytezować? Jak zapisywać te konkretne elementy Backlogu Produktu. Czyli takie absolutnie praktyczne wskazówki, które, no mogą znacznie przyspieszyć start Product Ownera. I oczywiście, to nie muszą być te techniki, czy te podejścia, które są już tymi ostatecznymi, końcowymi i zawsze musimy tak pracować. No ale chociażby z no mojego doświadczenia, kiedy przychodzi mi wspierać Product Ownera, który zaczyna, no to dostarczenie, pokazanie jakichś podstawowych narzędzi. Zobacz, to możesz zrobić w ten sposób, to możesz zrobić na te pięć sposobów, no już powoduje, że Product Owner nie jest kompletnie we mgle. No tylko albo dostaje konkretny pierwszy krok, który może zrobić. Przepracuje go sobie i wraca z jakimiś przemyśleniami. Albo dajemy na zasadzie Chińskiego Menu ileś opcji i Product Owner na bazie swoich dotychczasowych doświadczeń po prostu wybiera jakiś kierunek i go eksploruje. Natomiast na pewno jest to bardziej komfortowa droga niż po prostu zostać samym z tymi pytaniami i szukać, ale powiedzmy bez tego światełka w tunelu. Myślę, że to może być bardziej, w sensie więcej czasu Product Owner może stracić na poszukiwania niż w przypadku, gdy ma to wsparcie, ten Guide od Scrum Mastera przy swoim boku.

Kuba: No i z tymi, co powiedziałeś, to warto się wczuć w tę perspektywę Product Ownera, jeśli jesteśmy Scrum Masterem, że no Product Owner tych pytań do odpowiedzenia ma masę. Ma współpracę z Interesariuszem. Ma temat, czego potrzebują Klienci. Ma temat sprawdzania wyników produktu, zastanawiania się, co jest do zrobienia w najbliższych krokach, czy też w dalszej przyszłości. Na prawdę, czego potrzebuje Product Owner, to jeszcze się zastanowić, jak to zrobić na Refinemencie i jak to poukładać i poprowadzić na Sprint Review? Jakby odciążmy rzeczy, które nazwijmy to mechaniczne, ale one potrafią przyblokować. Bo merytoryka pracy Product Ownera nadal pozostaje wielkim wyzwaniem, masą pytań. Pełno wątpliwości. Dużo odkrywania. No to zredukujmy rzeczy, które da się uprościć. I tymi rzeczami jest edukacja. Żeby ona następowała, musi być jakaś więź. Musi być jakieś porozumienie. Zrozumienie. Zrozumienie się wzajemnie. Zwłaszcza jeśli mamy do czynienia z Product Ownerem, który startuje, no to tam może być przede wszystkim miejsce, żeby się w ogóle przyznać do tego, że potrzebuję wyjaśnienia. Może czegoś nie zrozumiałem. Może musiałem wyjść na chwilę ze szkolenia, jeśli takie było. No i to wszystko powoduje, że mam luki i te luki Scrum Master może świetnie rozwiązać.

Jacek: Taka uwaga, która przychodzi mi do głowy, kiedy patrzę na ten punkt jest taka, że jakby to wszystko, co tutaj powiedzieliśmy o tej współpracy, czy takiej powiedzmy edukacji Scrum Mastera. Wierzę, że to wszystko powinno odbywać się w duchu partnerstwa. Czyli to nie jest coś takiego, że ja jestem bardzo mądrym Scrum Masterem i teraz tutaj temu Product Ownerowi, który dopiero zaczynał będę teraz otwierał głowę i po prostu wrzucał informacje i w ogóle wychodził z takiej pozycji, że ja wiem, a on nie wie. Raczej spojrzałbym na to z tej perspektywy, że ok, ja jako Scrum Master mogę wesprzeć Product Ownera tą wiedzą, którą posiadam odnośnie – jak zarządzać produktem w podejściu zwinnym, czy konkretnie w Scrumie. Natomiast przy takim zastrzeżeniu, że jestem absolutnie otwarty na to wszystko, czego ja mogę się nauczyć od Product Ownera. Jakby bardzo mocno wierzę w to, że powinna to być współpraca partnerska na zasadzie – oboje jesteśmy OK, oboje jesteśmy równi. No i teraz jakby znajdźmy sposób, w którym jakby w dwie strony będziemy się od siebie uczyć. No bo koniec końców wierzę, że nawet doświadczony Scrum Master poprzez głęboką rozmowę z Product Ownerem, czyli upraszczając z osobą taką biznesową, jest w stanie wyciągnąć bardzo dużo dla siebie.No ale, żeby też do takiej sytuacji doszło, no to myślę, że takim pierwszym mikrokrokiem jest zbudowanie pewnej relacji. Zbudowanie zaufania. I też takie umówienie się na to, jak w ogóle będziemy współpracować. Taki nazwijmy to kontrakt na to, co my tutaj ze sobą będziemy robić.

Kuba: Jak wspominasz o tym partnerstwie, to mi się nasuwa taki ostatni powód z mojej listy, który no może nie jest oczywisty, ale kłopotem braku współpracy Product Ownera ze Scrum Masterem może być też brak wsparcia wzajemnego w promocji zwinności, wykorzystania tego zwinnego podejścia szerzej w organizacji. I co mam na myśli? Product Owner, zwłaszcza jeśli mamy do czynienia z taką firmą, gdzie Product Owner pewnie bardziej jest bliższy jakiemuś biznesowi, cokolwiek to znaczy w naszej firmie, a Scrum Master często będzie się raczej wywodził ze świata IT, to może się okazać, że łącząc te dwie specjalizacje, czy te dwa korzenie, z których się wywodzimy, łącznie mamy o wiele lepszy zasięg wewnątrz organizacji. Owner może ma lepszy dostęp do managementu biznesowego. Scrum Master może ma lepszy dostęp do managementu IT. Razem mamy lepsze kontakty osobiste też w tych obszarach. Współpracując ze sobą, wielokrotnie dostrzeżemy te momenty, że w rozwiązaniu jakiejś przeszkody, lepsze pomysły, lepszy kontekst rozumie Product Owner, a nie Scrum Master i razem ze sobą nad tym pracują. Są w stanie to lepiej rozwiązać. Natomiast nawet nie chodzi tylko o same problemy, ale to od czego zacząłem. Promocja zwinności. To Właściciel Produktu będzie wiedział jakie są jakieś nowe pomysły w biznesie. Być może pomysły powołania jakiegoś nowego zespołu. Być może szykuje się jakieś duże przedsięwzięcie, które fajnie by było złapać i zmoderować. Przeprowadzić na przykład przez Refinement już na etapie świeżego pomysłu, a nie czekania, aż ktoś wymyśli sobie, co ma być zrobione i wtedy dopiero to przekaże do Zespołu Scrumowego. Stąd taka myśl, że jakby takie ogólnie rozumiane wykorzystanie zwinnego podejścia może być pogłębione dzięki temu, że mamy fajną współpracę i takie szerokie spojrzenie na całą firmę i wykorzystanie naszych wszystkich kontaktów, potencjałów, lepszych wejść w różne miejsce. Scrum Master tu gubi kontakt z biznesem, jeśli nie skorzysta z product ownerskiego oka i z product ownerskiego powiedzmy doświadczenia. I w drugą stronę. Może nam się budować niepotrzebny mur między Product Ownerem, a na przykład zespołem, jeśli się nie dogadamy z niektórymi rzeczami na styku Product Owner – Scrum Master i reszta zespołu, czy management powyżej zespołu.

Jacek: Te wszystkie problemy, które mówiliśmy oczywiście nie pokrywają wszystkich możliwych opcji. Natomiast też nie chcielibyśmy tutaj spekulować. Łatwo sobie wyobrazić jakby jeszcze inne problemy, które się zrodzą. Natomiast, żeby nie podsuwać kiepskich pomysłów chcielibyśmy się skupić w drugiej części odcinka na tym, żeby trochę przybliżyć Ci jak może wyglądać taka potencjalna udana, modelowa współpraca Product Ownera ze Scrum Masterem.

Kuba: Pierwszym punktem, który nam przychodzi do głowy jako ten najważniejszy, to to, że osoby pełniące te dwie role mogą w bardzo wartościowy sposób, zarówno dla siebie osobiście, jak i dla efektów pracy całego zespołu, wymieniać się punktami widzenia. Po prostu w stały sposób rozmawiać ze sobą. Tu Jacek mówiłeś już o partnerstwie. Może poszerzysz, bo to jest moim zdaniem ten punkt, gdzie to świetnie się nadaje, taka praktyczna, partnerska relacja. Na czym może ona polegać?

Jacek: Wiesz co, to tak absolutnie mówiąc z doświadczenia. Będąc w roli Scrum Mastera, zwykle patrzyłem na Product Ownera, tak jak na mojego partnera, z którym będę pracował razem z zespołem. I tak jak miałem dużo interakcji z zespołem, tak samo czułem, że współpraca z Product Ownerem, to jest coś więcej niż tylko to, że jest on na wydarzeniach i on coś mówi i że ja moderuję. Tak więc, co stało się moją zasadą, którą stosowałem na co dzień, było to, że z tym Product Ownerem spędzałem czas. Rozmawialiśmy. Dzieliłem się jakimiś swoimi obserwacjami. Dzieliłem się jakimiś swoimi lękami, na zasadzie, co może pójść nie tak. Dzieliłem się przemyśleniami. Ale co jest ważne, jak mówisz o tym partnerstwie to to, że ja to robiłem w sposób taki bardzo otwarty. Nie wykorzystywałem tych spotkań, żeby budować swoją pozycję na zasadzie, ależ jestem mądry. Tylko raczej starałem się w jak najbardziej otwarty sposób pokazywać, jak ja patrzę na aktualny układ zespołu, produktu. Taki chciałem jakby zawsze oddać, co ja widzę patrzeć na nas jako całość. No i szukałem po drugiej stronie informacji zwrotnej, komentarza, innego spojrzenia. No i jakby naturalnie poprzez spędzone minuty, spędzone godziny, absolutnie w takiej formule nieoceniającej, niewywyższającej się, cały czas utrzymując skupienie. Jesteśmy tutaj po to, żeby ogólnie, sumarycznie, jak najlepiej wesprzeć zespół w rozwijaniu produktu. No to naturalnie jakby to skupienie nam się przesuwało na to, Ok – to co możemy zrobić razem w kolejnym kroku, żeby wesprzeć zespół w codziennej pracy.

Kuba: Miałeś jakiś konkretny sposób? Bo mówisz wprost z doświadczenia swojego scrum masterskiego. Jak to robiłeś? Jak robiłeś te wspólne rozmowy? W jakimś cyklu? Co środa o 15:00?

Jacek: Wiesz co, zwykle to były cykliczne spotkania. Najczęściej umawiałem się tak, że miałem jedno spotkanie w ciągu tygodnia i to było spotkanie około godzinne, gdzie zbierałem sobie z całego tygodnia najróżniejsze obserwacje, przemyślenia, tematy. Zwykle to były rzeczy, które nie były pilne. I na tym konkretnym spotkaniu budowałem sobie z Product Ownerem agendę, na zasadzie, zobacz, to jest moje pięć tematów. Chciałbym porozmawiać z Tobą o tym, o tym. Podzielić się z Tobą jakąś obserwacją. Product Owner zwykle miał jakiś tam swój Backlog pomysłów. Łączyliśmy go i zwykle punkt po punkcie sobie przechodziliśmy. Bardzo często te spotkania przeobrażały się w jakąś tam dogrywkę. Czyli z dziesięciu tematów omówiliśmy osiem, ale te dwa uznaliśmy, że też są ważne. No i sobie robiliśmy dodatkowe spotkanie kolejnego dnia, na jakieś tam pół godziny. I to był taki cykl. Natomiast on był przebijany dwoma rzeczami. Przed każdym wydarzeniem w Scrumie spędzaliśmy trochę czasu, żeby omówić jaki plan. W sensie, co ja widzę z perspektywy takiej powiedzmy, fascylitatora. Z drugiej strony Product Owner dzielił się tym, co chciał osiągnąć biznesowo. Takie samo robiliśmy sobie spotkanie domykające po każdym wydarzeniu. Z drugiej strony, jeżeli cokolwiek się pojawiało, co wymagało naszej reakcji, no to ja po prostu szukałem Product Ownera w organizacji, albo Product Owner szukał mnie. Tak więc z jednej strony pewna cykliczność. Z drugiej strony pewien rytm wyznaczony trochę wydarzeniami w Scrumie. Z trzeciej strony taka współpraca ad hoc, kiedy jedna ze stron czuła, że jest coś istotnego, co chciałaby przedyskutować.

Kuba: Myślę, że do tego rytmu wydarzeń to jeszcze wrócimy. Natomiast ja bym się jeszcze cofnął do tego, co powiedziałeś, do cykliczności. To mnie zaciekawiło. Po to to pytam, bo akurat sam w swojej pierwszej relacji product ownersko – scrum masterskiej, jak byłem Scrum Masterem. No to ze swoją Ownerką byłem raczej w takim rytmie ad hockowych, ale częstych rozmów. Czyli, no nie raz na tydzień, a bardziej w zasadzie przy każdej możliwej okazji o czymś tam sobie pogadajmy. Myślę, że tu nie ma lepszego lub gorszego rozwiązania, czy preferowanego lub mniej. Będą takie sytuacje i taka na przykład dostępność czasowa Ownera, że możemy się umówić, że rozmawiajmy przy każdej nadarzającej się okazji. A będą tacy zajęci Product Ownerzy, którzy będą preferowali, żeby jednak zaplanować nad kalendarzem i sobie te spotkania poukładać, bo na przykład mają więcej niż jeden zespół, albo mają jeszcze jakieś inne obowiązki firmowe, niż tylko praca w Zespole Scrumowym. No i wtedy się okazuje, że tak na spontaniczne spotkania to już za bardzo czasu nie ma. Więc tutaj nie rozstrzygam, które podejście lepsze. Czasem może spontaniczność też jest OK. Taka innego typu spontaniczność, której się nauczyłem dopiero po paru latach, to też to, że ciekawym, alternatywnym podejściem do spotykania się może być też wspólny obiad, wspólny lunch, wspólne śniadanie, gdzie poświęcimy sobie trochę więcej czasu, niż stricte, żeby faktycznie wyczyścić talerz zupy i wrócić do biura. Tylko po prostu przysiądziemy sobie w jakimś spokojnym miejscu i przy okazji zjemy, pogadamy i trochę też po ludzku się poznamy lepiej, ale też przegadamy bieżące rzeczy. To to też może być ciekawa alternatywa. Taka już bardziej kojarząca się z takim światem wielkiego biznesu. Ale taki wspólny lunch może się okazać jeszcze inną alternatywą na regularność współpracy, komunikacji, wymiany w każdą z możliwych stron.

Jacek: No jak mówisz o tym lunchu to faktycznie jest to o wiele fajny pretekst do spotkania, że on często generuje rozmowy, które niekoniecznie są stuprocentowo związane z zespołem. W sensie tak jakby ta atmosfera wspólnego spożywania jest bardziej luźna. Tak więc jak mówimy o tym partnerstwie i zaufaniu, jakiejś tam relacji, no to w szczególności, takie nieoficjalne spotkania, przypadkowo przy automacie z kawą, właśnie jakiś lunch, no powodują, że ta więź się buduje. Zaufanie się buduje właśnie wtedy, kiedy rozmawiamy o tym wszystkim, co nie jest pracą, no ale jest to fajny fundament, żeby potem lepiej się znać, lepiej się czuć powiedzmy na takim fajnym stabilnym gruncie budować już tak konkretnie rzeczy związane typowo z tym, czym się zajmujemy.

Kuba: To wróćmy może do tego wątku o współpracy przed wydarzeniami i po wydarzeniach. Jak wspominałeś o tym, żeby się umówić przed wydarzeniem, to ja bym to tutaj bardzo mocno zaakcentował, że nawet gdy już jesteśmy w trwałej relacji, gdy już wkrada się delikatna rutyna. Już wszyscy wszystko wiedzą, robimy to jak zawsze. To mimo wszystko zadbałbym o to, żeby przed spotkaniem jakimś typu planowanie, czy przed Refinementem, jeśli odbywamy je w postaci jakiegoś warsztatu, mimo wszystko poświęcić może dosłownie kilka minut. Ale to potrafi być czasem więcej czasu, żeby poświęcić chwilę i sobie porozmawiać. Czego potrzebuje Owner? Co ma w planach? Może czego potrzebuje Scrum Master? Bo może ma ochotę wrzucić jakiś granat do zespołu i wzajemnie sobie pewne rzeczy zsynchronizować. Być może trochę się wzajemnie przygotować, w sensie wzajemnie się poprosić o pewne postawy. Więcej moderacji, mniej moderacji Scrum Mastera, albo wesprzyj mnie drogi Product Ownerze, gdy wrzucę ten trudny temat. Jakby takie przygotowanie pewnych postaw przed spotkaniem, ale już takie bardziej przyziemne, ale nadal bardzo potrzebne, no to jakby jaki mam plan. Jaką technikę zrobię na Retro? Co się pojawi na Refinemencie? Może byśmy zrobili jeszcze jedną rundę Story Mappingu? A może dzisiaj zrobilibyśmy ten Story Mapping trochę inaczej? Zrobię go, a plan mam taki i taki. Więc to są wszystko rzeczy, jeśli się fajnie dogadamy przed, czy Scrum Master, czy Product Owner ma od razu naturalnego sojusznika, który będzie realizował pewien sposób poprowadzenia spotkania w taki sposób już zsynchronizowany, kompatybilny do siebie i taki przygotowany.

Jacek: No to jak o tym mówisz, to mi takie dwa przykłady przychodzą do głowy konkretne, co zdarzyło mi się zrobić. Jeden przykład jest taki, że dostrzegłem, że w zespole nie do końca uspójniona jest wizja produktu. W sensie moje odczucie było takie, że zespół trochę się z tą wizją produktu rozjeżdża, trochę się boksuje. Trochę są jakby różne spojrzenia. Bardzo prostą rzeczą, którą zasugerowałem i poprosiłem Product Ownera było, żeby przy każdej możliwej okazji zaczynał od wizji produktu. Czyli jak wiecie, nasz produkt, coś tam, coś tam. No i w związku z tym… Bardzo prosta rzecz, czy przed przeglądem Sprintu, czy konkretnie przed Refinementami, Product Owner po prostu automatycznie wracał do wizji. Do tego momentu, aż naturalnie stało się jasne, że jakby nie ma już tak dużej potrzeby, żeby to mocno akcentować. Inny przykład, który przychodzi mi do głowy. W momencie, kiedy dotykaliśmy bardziej złożonych problemów, jeśli chodzi o produkt, ja wiedząc, że Product Owner ma jakieś tam obawy związane z tym, czy na pewno to w dobry sposób prezentuje, czy to jest jasne, mogłem będąc w roli Scrum Mastera trochę częściej poprosić o parafrazę. Trochę częściej poprosić kogoś jak on patrzy na ten problem. Trochę więcej mogłem stosować technik wizualizacji. No ale wszystko dzięki temu, że dostałem powiedzmy ten taki hint, czy informację od Product Ownera, że być może nie do końca jest tak, że wszyscy w zespole rozumiemy rzeczy w ten sam sposób. Gdybym o tym nie wiedział, czy w przypadku tego Refinementu, czy w przypadku przeglądu Sprintu, to po prostu by się nie zadziało.

Kuba: Jak mówimy o przygotowaniach się przed spotkaniem, przed wydarzeniem, to też trzeba przygotować coś, co później już na samym przebiegu spotkania bardzo pomaga, to to, że podzielić się rolami i wzajemnie sobie pomagać. Tu sobie wyobrażam taką prostą rzecz, też już o tym wspominałem o tej empatii dla Product Ownera. No to załóżmy Sprint Review, na którym przychodzą ważni Interesariusze, być trudni Interesariusze, którzy w jakiś taki mocny sposób przekazują swoje zdanie. Fajnie byłoby, żeby w czasie tego spotkania już Product Owner już w całości był nastawiony na słuchanie i rozmowę z Interesariuszami i miał spokojną głowę, że przypilnowanie time boxa, moderowanie całego przebiegu spotkania, przeprowadzenie przez agendę, być może jakąś taką kontrolę nad aktywizowaniem kolejnych osób, może odciążyć Product Ownera, może odciążyć Scrum Master i wtedy Product Owner ma 100% procesora na obsługę bardzo trudnego Interesariusza, co w zasadzie można z góry przewidzieć, że takie coś może być potrzebne. Widuję często, że takie drobne niedogadania scrum mastersko – ownerskie, później skutkują niedociągnięciami spotkania. Albo przeciążony jest Product Owner, albo przeciążony jest Scrum Master, a Product Owner w zasadzie odlicza czas, kiedy się to wreszcie skończy i jakby tutaj zagrali tutaj w trakcie spotkania w tandemie, to wzajemnie byłoby mniej stresu i więcej korzyści dla całego zespołu. Tak sobie myślę, że wtedy długofalowo przykład modelowej współpracy, to jest osiągnięcie takiego trochę czytania sobie w myślach. Jakby oczami się porozumiewamy, że ktoś potrzebuje wsparcia, że ktoś tam lekko skinie głową, że może byś przymoderował, może byś odpowiedział na to, może już pora. I tak naprawdę już są te sygnały, że czytamy sobie w myślach, no już byłby sygnał, że ta współpraca jest modelowa. Ale ona sama się nie zrobi, więc tutaj chyba płynnie możemy przejść, gdy tej modelowej współpracy jeszcze nie ma. No to bardzo potrzebny będzie feedback. Feedback obustronny. Ja sobie tak myślę, taka prosta rzecz, że Scrum Master dla Product Ownera jest osobą, z którą prawdopodobnie się najwięcej czasu procentowo widzi się w pracy. W sensie, wszystkie wydarzenia, plus jakieś jeszcze dodatkowe czynności, to się może okazać, że najwięcej o naszej pracy może powiedzieć Scrum Masterowi Product Owner i Product Ownerowi Scrum Master. Bo spędzamy ze sobą pewnie z 30% czasu pracy non stop. Bo to są spotkania, to jest praca pomiędzy, to jest widzenie się w zespole. Manager nie powie nam o tyle pracy, ile nam powie Scrum Master i często być może pojedynczy członek zespołu nawet nie widzi nas tyle, ile widzi nas Scrum Master lub Product Owner w drugą stronę na to patrząc. Więc tutaj ten feedback, jeśli tylko będzie na niego otwartość, jeśli będzie na niego – nazwę to – ochota, przyzwolenie, może być najgłębszy spośród takich, jakie jesteśmy w sobie w stanie dać.

Jacek: No i tu automatycznie wraca nam ten temat relacji. Jeżeli ta relacja jest, jeżeli to zaufanie występuje, no to nie ma też problemu, żeby sobie otwarcie o tym, co można byłoby zrobić inaczej porozmawiać. I to zarówno może wystąpić w takiej formule, co ja często robiłem, po prostu wprost pytałem Product Ownera, co uważa na temat tego, jak poprowadziłem to konkretne spotkanie? Czyli tak jakby feedback na żądanie, można powiedzieć. Z drugiej strony przez to, że ta relacja już jest, no to wtedy jakby ja często nie musiałem czekać, żeby Product Owner podzielił się jakąś obserwacją, no bo wiedział, że jestem otwarty na informację zwrotną. No więc to nie jest tak, że to tylko ja pytam i wtedy jest informacja zwrotna. Tylko wiedzieliśmy, że to działa w obie strony, więc ja też bądź byłem pytany o tym, co myślę, jak Product Owner zachował się w konkretnym momencie. Albo nie czekając na to, nazwijmy to pozwolenie, sam komunikowałem, że mam jakąś obserwację i czy to jest dobry moment, żeby o tym porozmawiać. Dojście do takiego momentu, jakby to co powiedziałeś, myślę jest wartościowe. Jest bardzo istotne, ponieważ, tak jak wspomniałeś, być może nie będzie osoby, która ma większe skupienie na tym, jak konkretnie się zachowujemy. Przez to, że ta współpraca, ten kontakt wzrokowy, te takie czytanie w myślach, no tak naprawdę rozwojowo rzecz ujmując, no to ten Product Owner dla Scrum Mastera i w drugą stronę, to mogą być tacy – mentor, to może za duże słowo, ale na pewno osoby, które będą nam towarzyszyć w drodze rozwijania swoich kompetencji.

Kuba: Najbliższy współpracownik, który ma niezależność od nas, a jednocześnie widzi nas jednocześnie widzi nas zawsze w pracy. Ja bym mocno zaakcentował, to co powiedziałeś. Tak też apropos tego feedbacku. Zacznijmy od siebie, ale nie zacznijmy go dawać, tylko zacznijmy go brać. Czyli najlepiej można zamodelować dawanie feedbacku poprzez proszenie o jego uzyskanie. A nawet jeśli są jakieś niedoskonałości techniczne tego feedbacku, to zawsze można go jeszcze poprawiać poprzez parafrazę tego, co się słyszy. Rozmowę o tym, jak się to odbiera. Być może nawet danie feedbacku do procesu dawania feedbacku. Czyli jak nam się ze sobą współpracuje. Jak nam się ze sobą komunikuje. Natomiast no to jest coś, co myślę, że jest gotową rzeczą, którą można sobie zabrać do natychmiastowego realizowania w zespole, poprośmy o feedback. I zobaczmy co dostaniemy. Bądźmy otwarci na to, co usłyszymy, bo może być tak, że dostaniemy coś innego, niż się spodziewamy i to powinno nam dać do myślenia.

Jacek: Kolejny taki przykład, jak mogłaby wyglądać modelowa współpraca Product Ownera i Scrum Mastera, to jest taka współpraca na zasadzie, że Product Owner może wejść w rolę, która podsuwa pewne potrzeby i pomysły, a Scrum Master wchodzi w rolę, która pomaga inspirować i dawać rozwiązania. Czyli przykładowo Product Owner może mieć potrzebę, żeby w sposób wizualny i czytelny zaprezentować jakiś tam obszar Backlogu Produktu i może mieć pytanie do Scrum Mastera. Jak można to najlepiej zrobić? Spodziewałbym się, że Scrum Master, w szczególności doświadczony przerabiał już taki temat, więc może tutaj bardzo konkretnie zaproponować Product Ownerowi jakieś konkretne rozwiązania. Bardziej wizualne. Mniej wizualne. Jakby ostatecznie doprowadzając do tego, że jakby te potrzeby Product Ownera, które on ma i być może jeszcze nie wie, jak je przekazać do zespołu, no to Scrum Master może mieć w zanadrzu kilka sprawdzonych rozwiązań. Lub idąc krok dalej, może się podzielić jakimś rozwiązaniem i jeszcze z Product Ownerem, jakby co dopowie Product Owner i na bazie, co ja słyszę i co widziałem, jesteśmy w stanie razem zbudować zupełnie coś nowego, co da jeszcze lepszy efekt, niż gdyby tylko dać gotową technikę i po prostu przyłożyć ją od linijki i użyć.

Kuba: Tak. Budować swoje własne techniki. Jak mówisz o tym inspirowaniu technik, to tak trochę odwrócę przez negację, że nie polecam czegoś, co czasem widuję. Przychodzi Scrum Master – też już to powiedziałeś, że w takim trybie, jestem mądry, te techniki się stosuje, o tym słyszałem na konferencji, tu widziałem filmik, tu przeczytałem jakiś wpis na blogu, tak mamy postępować. Albo, drogi Product Ownerze, User Story pisze się tak i masz to zrobić. Fajną sesję kiedyś poprowadziłem, gdzie sobie wyjaśniliśmy, jak taka inspiracja może wyglądać. W praktyce ja zachęcałbym raczej do modelu, w którym Scrum Master pokazuje technikę. Najlepiej od razu zaprasza do wspólnego przepracowania jakiegoś elementu. Zaczynając jak dla mnie dosyć prostych, ale nadal wymagających technik, jak Uses Story, no to nie tylko mówię, jaki ma być szablon User Story. Nie tylko mówię przykład, jak to jest gdzieś u Mike’a Cohn’a. Mówię też, jak to User Story mogłoby wyglądać w naszym Backlogu. Jak tego nie umiem, to jest oddzielny temat. To wypracujmy to sobie razem lub poszukajmy kogoś, kto mógłby mi pomóc w tym, jak to robić. Nie spoczywałbym na laurach scrum masterskich w momencie, w którym umiem wydeklamować teorię User Story i podać przykład od Mike’a Cohn’a kolejnie abstrakcyjny w naszych realiach. To jest za mało. To jest zdecydowanie miejsce na to, żeby ten taki proces wprowadzania pewnych podejść, technik, pomysłów, narzędzi, raczej robić tak na zasadzie „lead by example”. Czyli razem to wprowadzamy, ja Wam mogę nawet podpowiedzieć kilka pierwszych przykładów, a nie na odwrót, że macie to robić, bo to jest mądre, bo to jest polecane i w ogóle jestem Scrum Masterem i macie mnie słuchać. To nie dojdziemy donikąd.

Jacek: I tu znów wraca temat relacji. Nie wyobrażam sobie generalnie takiego podejścia w stosunku do osoby, z którą mam już coś zbudowane, bo spodziewam się, że od razu dostałbym informację zwrotną – a czy na pewno to jest ta jedyna, czy na pewno ten przykład jest dobry w naszym kontekście. Tak więc wracam do tej relacji, w sensie uważam, że to jest taki absolutnie fundament, żeby to wszystko o czym mówimy, żeby w ogóle mogło mieć miejsce. No bo chociażby w przypadku braku relacji próba zainspirowania ze strony Scrum Mastera może zostać odebrana w zupełnie pejoratywny sposób. Na zasadzie, wymądrza się, co on mi tu chce opowiedzieć. Nie wiem, chce pokazać, że jest mądrzejszy? No i jakby z dobrych intencji niewiele nam zostanie.

Kuba: Zamknąłbym ten punkt, że Scrum Master inspiruje, a tak jak powiedziałeś na początku Product Owner komunikuje wprost potrzeby, rozwiązujmy problemy, czy realizujmy potrzeby, a nie wprowadzajmy techniki, bo są modne. To, że 80% świata zwinnego z czegoś korzysta, wcale nie znaczy, że my to musimy robić. Zwłaszcza jeśli nasz kontekst jest w pewien sposób specyficzny i jednak odmienny. Te takie żelazne rozwiązania u nas nie mają zastosowania, chociażby ten przykładowy przypadek, jak używanie historii Użytkownika.

Jacek: Ostatni pomysł, który nam przychodzi do głowy, wskazówka na czym może taka współpraca modelowa polegać, to jest wspólne rozmawianie o usprawnieniach. Ja patrzę na to z tej perspektywy, że Product Owner to jest taka dodatkowa para oczu, która też przez wszystkie wydarzenia w Scrumie, czy przez wszystkie interakcje z zespołem, widzi zespół w sensie, zarówno developerski, no ale też wierzę w jakieś obserwacje i przemyślenia na poziomie całego Zespołu Scrumowego. Jakby tak tę sprawę ujmując no to Scrum Master nie jest sam w tej swojej roli dbania o usprawnienia. Wystarczy tylko zaprosić Product Ownera do tej rozmowy i dostaniemy być może kompletny punkt widzenia na pewne zachowania, na pewne sytuacje. Myślę sobie, tak na bazie doświadczeń, że dopiero łączenie tych perspektyw, czasem nawet idąc dalej, włączanie jakichś konkretnych osób z zespołu, pozwala dojść do lepszych obserwacji, do lepszych wniosków. W konsekwencji do wypracowania lepszych rozwiązań, niż w sytuacji, gdzie Scrum Master jest takim samodzielnym wojownikiem i sam na siebie też narzuca taką presję – muszę zrobić usprawnienia. No bo znów, możemy wrócić do sytuacji, w której te usprawnienia zostaną odebrane jako coś narzuconego, jako coś takiego, bo tak pisało w książce. Wystarczy tylko odbić się od chociażby jednej osoby. Niech to będzie właśnie Product Owner, żeby już zyskać nowe światło na problem, nowy punkt widzenia. Po prostu wypracować coś lepszego.

Kuba: Też będzie często tak, że rozwiązania wcale nie będą sprowadzały się do pojedynczego działania, którejś ze stron, albo jakiejś pojedynczej czynności. Wiele rozwiązań, zwłaszcza na te złożone problemy, jak demotywacja w zespole, albo pogorszenie się jakości. Tak naprawdę będzie wymagało przyłożenia siły w kilku miejscach jednocześnie. Wielokrotnie tak z doświadczenia dość ogólnie powiem, że wielokrotnie jest tak, że nawet na rzeczy stricte techniczne bardzo pomoże, jeśli równomiernie, równolegle dołoży coś do tego ze swojej strony Product Owner. Czy to poprzez priorytetyzację pewnych elementów Backlogu, czy poprzez przypomnienie wizji, tak jak mówiłeś, w stylu mantrycznym. Jeszcze raz przypomnijmy, co jest naszym produktem i jaka jest jego wizja. Czy poprzez uruchomienie jakichś kontaktów wśród Interesariuszy. Może skupienie się na jakimś poszczególnym aspekcie Backlogu? Jest cała masa rzeczy, która jest standardowym sposobem pracy Product Ownera, a w porozumieniu ze Scrum Masterem i wynikami Retrospektywy całego zespołu, jeśli zrobimy to jednocześnie, no to uzyskujemy taki efekt combo. Owner zrobił kawałek, zespół zrobił kawałek, Scrum Master coś dołożył od siebie, a w sumie dzięki temu zrobiliśmy spory przełom. Dobrze, to na ten moment skończymy. W ramach tego odcinka, chcieliśmy Tobie przekazać nasze przemyślenia na temat współpracy Product Ownera i Scrum Mastera. Pierwsza część odcinka była na temat tego, dlaczego brak takiej współpracy w ogóle jest problemem? W drugiej części skupiliśmy się na tym, żeby opowiedzieć o takich dużych punktach tego, jak widzimy jako modelowa współpraca. I te duże punkty przytoczę. Na pewno jest to wymiana punktów widzenia. Umówienie się przed wydarzeniami, jak one będą między nami przebiegać. Współpraca już podczas wydarzeń. To co wspomniałem, takie czytanie sobie w myślach, czy porozumiewanie się wzrokiem. Otwartość i partnerska współpraca włącznie z tym, że otwartość i gotowość na przyjmowanie i dawanie sobie feedbacku. Podsuwanie sobie, inspiracja przez Scrum Mastera technik, które może cały zespół wykorzystać, ale też podsuwanie, czy głośne sygnalizowanie swoich potrzeb przez Product Ownera. Skończyliśmy cały odcinek tematem możliwej współpracy, możliwej rozmowy i możliwym rozwiązywaniu usprawnień.

Jacek: Jeżeli czujesz, że któryś z tych tematów, czy obszarów, który poruszyliśmy dzisiaj, jeśli chodzi o współpracę Scrum Mastera i Product Ownera jest interesujący, i z Twojej perspektywy wymagałby jakiegoś pogłębienia, rozwinięcia, podania większej ilości przykładów – skontaktuj się z nami. Dane kontaktowe znajdziesz w opisie tego odcinka. A tymczasem to wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek.

Jacek: I do usłyszenia wkrótce.