Rozmawiając ze Scrum Masterami w ciągu kilku ostatnich lat, natknęłam się na niepokojący wzorzec. Pomimo dostępu do Scrum Guide oraz innych materiałów uzupełniających, wielu Scrum Masterów, zwłaszcza tych początkujących, zmaga się z brakiem pomysłu na to, jak pomagać swoim Product Ownerom w codziennej pracy.
Poniżej przedstawię kilka przykładów z mojej praktyki pracy z Product Ownerami, wraz z cytowanymi fragmentami Scrum Guide'a, które służą mi jako drogowskaz w równoważeniu wsparcia oraz pozostawienia Product Ownerom przestrzeni do wykorzystania ich kompetencji.
Zacznijmy od pierwszego:
(..) Pomaganie w odkrywaniu technik skutecznego definiowania Celu Produktu oraz zarządzania Backlogiem Produktu;
Co to oznacza? Brzmi tak, jakbyśmy mieli po prostu podać gotowe rozwiązanie, typu „proszę, oto technika mapowania historii, która rozwiąże wszystkie twoje problemy”. Jednak z mojej perspektywy, jako Scrum Masterzy, powinniśmy aktywnie poszukiwać odpowiednich metod korzystając z dostępnych narzędzi, na przykład:
- „Wyszukanie w Google” i odciążenie Product Ownera od presji znalezienia najlepszej techniki,
- Networking z innymi Scrum Masterami, aby poznać ich doświadczenia,
- Połączenie Product Ownera z innymi Właścicielami Produktu – zarówno wewnątrz organizacji, jak i na zewnątrz, aby umożliwić wymianę wiedzy. Może macie już jakąś gildię Właścicieli Produktu? Jeśli nie, to być może warto ją utworzyć?
- Uczestniczenie w spotkaniach i szkoleniach dotyczących dostępnych technik, aby móc wyjaśnić ich wartość dla Właściciela Produktu i prowadzić je, kiedy jest to konieczne,
- Organizacja warsztatów na temat definiowania Celu Produktu i/lub zarządzania Backlogiem Produktu,
- Edukowanie o różnych metodach priorytetyzacji Backlogu Produktu – czy próbowaliście Metody Opartej na Wartości?
- Regularnie przeprowadzane sesje coachingowe jeden na jeden z Właścicielami Produktu.
Nie mogę wystarczająco podkreślić, jak ważne są regularne spotkania jeden na jeden. To właśnie w tych chwilach, jak mówię, „dzieje się magia”. Jako Scrum Masterzy tworzymy przestrzeń do pogłębienia zrozumienia frameworku Scrum i odpowiadamy na wszelkie pytania, jakie mogą pojawić się u naszego Product Ownera w trakcie Sprintu. Niestety, często Scrum Masterzy nie przykładają do tego wystarczająco dużo uwagi. Często mówimy, że „aby zbudować relacje i wprowadzić prawdziwą zmianę, potrzebujemy zaufania”. To właśnie w tych momentach zaufanie może zostać zbudowane.
To tylko kilka sposobów, w jakie możemy wspierać naszych Product Ownerów w określaniu Celu Produktu i zarządzaniu jego Backlogiem. Zachęcam was do korzystania z dostępnych zasobów,, aby najlepiej służyć waszym Właścicielom Produktu w tych aspektach.
Kolejna rzecz, którą możemy znaleźć w Przewodniku po Scrumie: Scrum Master służy Właścicielowi Produktu poprzez:
Pomaganie Zespołowi Scrumowemu zrozumieć potrzebę jasnych i zwięzłych elementów Backlogu Produktu
Oto kilka sposobów, w jakie może on wspierać ten obszar:
- Zapewnienie, że podczas Planowania Sprintu, Zespół Scrumowy rozumie DLACZEGO coś jest robione, CO jest robione i JAK to będzie zrealizowane w nadchodzącym Sprincie.
- Wprowadzanie przejrzystości do elementów Backlogu Produktu (PBIs).
- Zachęcanie Właściciela Produktu i Deweloperów do eksperymentowania z różnymi sposobami tworzenia elementów Backlogu Produktu – może historyjka użytkownika to nie jedyna opcja?
- Zadawanie istotnych pytań, na przykład: „Czy za kilka tygodni nadal będziesz w stanie zrozumieć swój element Backlogu Produktu?”.
- Łączenie elementów Backlogu Produktu z Definicją Ukończenia, pytając na przykład: „Jak będziesz wiedział, że ten element Backlogu Produktu jest UKOŃCZONY? Co musi się stać?”.
- Sugerowanie komplementarnych praktyk, takich jak Definition of Ready (choć osobiście nie jestem jej zwolenniczką, ale rozumiem, że może być przydatna dla niektórych zespołów).
- Ustalanie standardu budowy elementu Backlogu Produktu, na przykład tego, że powinien zawierać on cel, opis, kryteria akceptacji – cokolwiek, co sprawdza się w TWOIM zespole.
Kolejny punkt to:
Pomoc w ustanowieniu empirycznego planowania produktu w złożonym środowisku;
To nie lada wyzwanie. Co dokładnie oznacza empiryczne planowanie produktu?
Dla mnie oznacza to uwzględnienie wszystkiego, czego nauczyliśmy się z poprzednich Sprintów i dostosowanie planów na przyszłość. Aby to było możliwe, musimy zacząć jeszcze przed Planowaniem Sprintu:
- Tworzenie przez Scrum Mastera bezpiecznego środowiska podczas Retrospekcji, aby Zespół Scrumowy mógł przeanalizować swoją pracę w poprzednim Sprincie.
- Zapewnienie, że Właściciel Produktu uwzględnia informacje rynkowe dotyczące rozwijanego Produktu.
- Pomoc Właścicielowi Produktu w znalezieniu odpowiednich miar dla Produktu i pokazanie różnych podejść – być może Zarządzanie Oparte na Danych (Evidence-Based Management) byłoby dobrym punktem wyjścia.
- Skupienie się na wartości, jaką Produkt przyniesie klientom – czy jesteśmy pewni, że wszystkie te funkcje są naprawdę potrzebne?
- Upewnienie się, że Właściciel Produktu stale pamięta o ustalonym Celu Produktu, przypominając mu: „jak ten element będzie służył naszemu Celowi Produktu?”.
- Wyjaśnianie, czym jest złożone środowisko – i budowanie zrozumienia, jak Scrum może pomóc w tej dziedzinie. Kiedy ostatnio rozmawiałeś ze swoim Właścicielem Produktu o teorii złożoności?
I na koniec, ale nie mniej ważne:
Ułatwianie współpracy z interesariuszami, kiedy jest to potrzebne lub na życzenie.
Jak możemy to osiągnąć?
- Pomaganie Właścicielowi Produktu w znalezieniu interesariuszy wewnątrz organizacji, jak i poza nią – może mapa stron zainteresowanych?
- Zapewnianie, by Właściciel Produktu brał pod uwagę wszystkie istotne informacje.
- Ułatwianie intensywnych spotkań z interesariuszami, kiedy jest to potrzebne.
- Zasugerowanie kilku pomysłów, jak wybrać, które potrzeby stron zainteresowanych są najbardziej zgodne z rozwojem naszego produktu – może macierz wpływu/pracy?
- Wskazywanie Właścicielowi Produktu potrzeby zbierania opinii o jego/jej produkcie.
- Zapewnienie, że użytkownicy produktu są obecni na naszym Przeglądzie Sprintu – zbyt często uczestniczą w nim tylko wewnętrzni interesariusze, którzy w rzeczywistości nie używają naszego produktu!
- Zapewnianie przejrzystości we współpracy z interesariusami – może przez jasne przedstawienie Backlogu Produktu i jego priorytetów?
Jak widzisz, choć w Scrumie mamy pewne wytyczne, istnieje dużo swobody w ramach tych zasad, jak możesz to osiągnąć. To zarówno sprzyja kreatywności, ale też czasem - frustracji.
Mam nadzieję, że ten artykuł zainspiruje cię do kilku pomysłów i pomoże przekształcić te chwile frustracji w kreatywność.
