Jak naprawdę Scrum Master może wspierać Product Ownera?

Rozmawiając na przestrzeni ostatnich kilku lat z wieloma Scrum Masterami natknęłam się na pewien, niepokojący wzorzec. Pomimo istnienia jasnych wytycznych w “Przewodniku po Scrumie” (Scrum Guide™) i innych, uzupełniających źródłach, duży odsetek Scrum Masterów, zwłaszcza tych początkujących, zmaga się z interpretacją i pomysłami, jak na co dzień pomagać swoim Product Ownerom.

Poniżej znajdziesz kilka praktycznych przykładów moich osobistych doświadczeń w pracy z Właścicielami Produktów. Uzupełnione są one także o konkretne cytaty ze Scrum Guide’a, które pomagają mi odnaleźć balans pomiędzy wsparciem, a nie robieniem czegoś, za co są odpowiedzialni PO.

Techniki zarządzania Backlogiem Produktu

Zacznijmy od cytatu: “(…) Scrum Master pomaga znajdować techniki pozwalające na skuteczne określenie Celu Produktu oraz zarządzanie Product Backlogiem.“

Co oznacza pomaganie w znalezieniu technik? Czy to po prostu: „proszę bardzo, oto technika user story mapping, która rozwiąże wszystkie twoje problemy” ? Cóż, według mnie, my jako Scrum Masterzy powinniśmy odkrywać różne techniki za pomocą najróżniejszych środków, takich jak:

• „po prostu wygoogluj”, zdejmij ze swojego Product Ownera trochę presji, poszukaj, zaangażuj w szukanie rozwiązań, bądź wsparciem w szukaniu technik,
• Nawiązywanie kontaktów z innymi Scrum Masterami, aby mieć możliwość korzystania z rożnych doświadczeń.
• Łączenie naszego Product Ownera z innymi PO – w naszej organizacji lub poza nią, aby zachęcać do dzielenia się wiedzą. A może masz już jakąś Gildię Product Ownerów? Jeśli nie, to czy istnieje możliwość jej utworzenia?
• Uczestnictwo w różnych spotkaniach, meet-upach, szkoleniach z różnych technik oraz umiejętność ich wyjaśniania Właścicielowi Produktu, a także, w razie potrzeby zastosowania w praktyce.
• Facylitacja warsztatów ze definiowania Celu Produktu i/lub zarządzania Backlogiem Produktu.
• Nauczanie różnych podejść do porządkowania Backlogu Produktu – czy próbowałeś metody opartej na wartości?
• Organizowanie regularnych sesji coachingowych 1 na 1.

Nie sposób dostatecznie podkreślić jak szalenie ważna jest moim zdaniem regularna sesja 1 na 1. To tutaj „ dzieje się magia”. Rolą Scrum Mastera jest zapewnianie miejsca do głębszego zrozumienia frameworku Scrum i odpowiedzenie na wszelkie pytania, jakie mogą pojawić się podczas trwania Sprintu w głowie nasze Product Ownera.

Niestety jest to również jedna z tych rzeczy, do których Scrum Masterzy nie przykładają dostatecznie swojej uwagi. Często mówimy: „aby zbudować relację, aby dokonać prawdziwej zmiany, potrzebujemy wzajemnego zaufania”. Sesje 1 na 1 to właśnie jeden z tych momentów, kiedy faktycznie możemy je zbudować.

To tylko kilka pomysłów na to, jak możemy pomóc swojemu Product Ownerowi w tworzeniu Celu Produktu i zarządzaniu Backlogiem. Zachęcam Cię oczywiście do poszukiwania kolejnych i do intensywnego wykorzystania tego czym dysponujesz już na ten moment.

Jak tworzyć elementy Product Backlogu?

Jak jeszcze Scrum Master może wspierać swojego Product Ownera? Kolejną wskazówką, jaką podsuwa nam Scrum Guide jest: “(…) pomaga Scrum Teamowi zrozumieć potrzebę jasnego i zwięzłego formułowania elementów Product Backlogu”.

Poniżej kilka pomysłów, jak może wyglądać to w praktyce:

• Zapewnienie, że podczas Planowania Sprintu Zespół Scrumowy jest świadomy odpowiedzi na pytania DLACZEGO (chcemy to robić), CO (dokładnie mamy zbudować) i JAK (to osiągniemy).
• Zapewnienie transparencji elementów Backlogu Produktu.
• Zachęcanie Właściciela Produktu i Deweloperów do eksperymentowania z różnymi pomysłami na tworzenie PBI, może format User Story nie jest jedyną dostępną opcją? 😉
• Zadawanie mocnych pytań, takich jak „Czy nadal będziesz w stanie zrozumieć swoje PBI za kilka tygodni?”
• Powiązanie PBI z Definicją Ukończenia, na przykład z pytaniami „Skąd będziesz wiedzieć, że ten PBI jest ZROBIONY? Co musi się stać?”
• Porzucenie pomysłu komplementarnej praktyki, takiej jak Definition of Ready (osobiście nie jestem fanką, ale wiem, że niektóre zespoły mogą na tym skorzystać),
• Ustalenie standardu budowania naszego PBI (np. powinno mieć cel, opis, kryteria akceptacji – wszystko, co działa dla TWOJEGO zespołu)

Empiryczne podejście do planowania pracy

Kolejna wskazówka w Scrum Guidzie mówi, że Scrum Master “pomaga wprowadzać empiryczne podejście do planowania pracy nad produktem w złożonym środowisku”.

Ten element będzie nieco trudniejszy do wyjaśnienia i podania przykładu. Co dokładnie oznacza empiryczne planowanie produktu? Dla mnie jest to wzięcie pod uwagę wszystkiego, czego nauczyliśmy się w poprzednich Sprintach, wyciągnięcie wniosków i zaadaptowanie się w kolejnym Sprincie. Aby jednak tak się stało, musimy podjąć pewne kroki jeszcze przed Sprint Planningiem.

• Podczas Retrospektywy Scrum Master buduje bezpieczne środowisko dla Zespołu Scrumowego, umożliwiające dokonanie inspekcji osiągnięć minionego Sprintu.
• Scrum Master dba o to, aby Product Owner uwzględniał aktualne informacje rynkowe dotyczące rozwijanego Produktu,.
• Pomaga Właścicielowi Produktu znaleźć odpowiednie metryki dla Produktu, pokazuje różne podejścia – dobrym punktem wyjścia może być wykorzystanie Evidence Based Management.
• Pomaga skupić się na wartości, jaką nasz Produkt przyniesie klientom – czy jesteśmy pewni, że wszystkie pomysły na funkcjonalności jakie mamy w Backlogu są naprawdę potrzebne?
• Upewniamy się, że Product Owner nie zapomina o wyznaczonym Celu Produktu, przypominamy mu pytając „w jaki sposób ten element ma służyć naszemu Celowi Produktu?”
• Wyjaśnianie, czym jest złożone środowisko – i budowanie zrozumienia, w jaki sposób Scrum może pomóc w takich okolicznościach. Kiedy ostatnio rozmawiałeś z Właścicielem Produktu o tym, czym jest teoria złożoności?

Wspomagania współpracy z interesariuszami

Ostatni punkt w Scrum Gudzie, w akapicie dotyczącym wsparcia PO przez Scrum Mastera, mówi: “wspomaga współpracę z interesariuszami, kiedy zostanie o to poproszony lub kiedy zachodzi taka potrzeba.”

W jaki sposób możemy osiągnąć to w praktyce?

• Pomoc Właścicielowi Produktu w zidentyfikowaniu interesariuszy wewnątrz organizacji i poza nią – może wykorzystasz do tego celu mapę interesariuszy?
• Upewnienie się, że Product Owner holistycznie uwzględnia wszystkie istotne informacje.
• Facylitowanie wymagających spotkań z interesariuszami, może zasugerowanie pomysłów, jak wybrać, które potrzeby interesariuszy są spójne z naszym rozwojem produktu, jego Celem – może warto zastosować macierz Impact/Effort?
• Pokazanie Właścicielowi Produktu potrzeby i korzyści ze zbierania informacji zwrotnej na temat jego/jej Produktu.
• Upewnienie się, że użytkownicy naszego Produktu biorą udział w Sprint Review – zbyt często mamy tylko wewnętrznych interesariuszy, którzy w rzeczywistości wcale nie korzystają z tego, co buduje zespół!
• Zapewnienie transparencji we współpracy z interesariuszami – może poprzez jasną wizję Backlogu Produktu i odpowiednie priorytety?

Jak widać w powyższych przykładach, Scrum określa pewne ramy współpracy pomiędzy Scrum Masterem i Product Ownerem. Pomimo tego, pomiędzy nimi występuje dosyć duża dowolność. Sami decydujemy jak osiągnąć przedstawione cele, co niewątpliwie sprzyja zarówno kreatywności, jak i czasami… frustracji ;). Mam nadzieję, że powyższy artykuł zainspiruje Was we wspomnianej chwili zwątpienia i że wymyślicie jeszcze niejeden sposób wspierania swojego Właściciela Produktu.