Wiele napisano o tym, jak Scrum Master pracuje nad samoorganizacją zespołów, efektywnością pracy i usprawnia całą organizację. Jako Scrum Masterzy propagujemy także zwinne praktyki i narzędzia (oraz, tam gdzie ma to sens - także Scrum :). Jesteśmy świetni w facylitacji, usuwaniu blokad i wspieraniu samoorganizacji.
Jest jednak jeden obszar, który przynajmniej ja - przez długi - czas traktowałem ‘po macoszemu’. Jest to właśnie wspieranie Product Ownerów w rozwoju pod kątem zarządzania produktem i maksymalizacji wartości. Można powiedzieć, że pracując z zespołami i organizacją, byłem Scrum Masterem poziom 2 (może 2,5 😉 na 3. Jak wskoczyć w pełni na trzeci poziom? Zapraszam do lektury.
Jeśli tak jak ja nigdy nie byliście wcześniej Product Ownerami, odnalezienie się w zagadnieniach zarządzania produktem (i maksymalizacją wartości) może być dla Was (jak i mnie) pewnym wyzwaniem. Jeszcze większym może być pokazanie Product Ownerowi, że faktycznie jesteśmy mu, jako Scrum Masterzy w stanie pomóc w zdobyciu nowych narzędzi i kompetencji w tej dziedzinie (oraz sami od niego lub niej się uczyć). Jak w ogóle podejść do współpracy z PO, który często jest ekspertem biznesowym z wieloletnim doświadczeniem w zarządzaniu produktami?
A przecież, jak oznajmia Pismo Scrum Guide:
“Scrum Master wspiera Właściciela Produktu w wielu aspektach, na przykład:
- w znajdowaniu technik efektywnego zarządzania Backlogiem Produktu,
- (...)
- zapewniając, że Właściciel Produktu wie, jak porządkować Backlog Produktu, aby maksymalizować wartość,
- (...)”
No i klops. Jak wspomóc Product Ownera w zarządzania Product Backlogiem czy w sposobach maksymalizowania wartości nie będąc nigdy wcześniej w jego butach? Jak przekonać go (lub ją) do wypróbowania nowych sposobów pracy, o których przeczytaliśmy, usłyszeliśmy na konferencji, widzieliśmy w innych firmach lub poznaliśmy od innych PO na Agile Wrocław (pozdrawiam Michale :)?
Podstawowym warunkiem rozpoczęcia wspólnej pracy nad obszarem maksymalizowania wartości jest… zdobycie wiedzy 🙂
- Czytamy artykuły, książki, blogi
- Dyskutujemy z innymi Scrum Masterami i Product Ownerami
- Uczestniczymy w społecznościach (np. Agile Wrocław, PO Wro)
- Eksperymentujemy z narzędziami, technikami - najpierw na mniejszą skalę
- Poznajemy domenę produktu, w którym przyszło nam pracować
Kolejnym krokiem jest zbudowanie odpowiedniej relacji z Product Ownerem. Co z tego, jeśli pokażemy naszemu PO jak wiele rzeczy wyczytaliśmy, poznaliśmy (czy nawet wypróbowaliśmy w innych firmach), jeśli nie będzie on (lub ona) widział(a) bezpośredniego przełożenia na jego (lub jej) pracę?
Tak jak w przypadku budowania relacji z zespołem, tak i tutaj ja nastawiam się na słuchanie i zrozumienie potrzeb, a następnie zaoferowanie swojej pomocy i dostarczenie faktycznej wartości. Przykłady:
- Zaoferuj PO pomoc przy porządkowaniu Product Backlogu. Przygotuj się do tego, przeglądnij Backlog, zrozum historię produktu, domenę, użytkowników. Zapytaj zespół jak się pracuje z Backlogiem, czego oczekują. Następnie siądź z Product Ownerem i poświęć tyle czasu, ile trzeba aby uzyskać najlepszy efekt (dopasowanie narzędzi, grupowanie, usuwanie, szeregowanie, estymacje z zespołem, etc.).
- Pomóż PO zebrać empiryczne dane na temat produktu i zespołu (zdrowie Product Backlogu, time to market, release burndown chart, ilość błędów, czas życia błędów, prędkość zespołu, stopień dostarczenia MVP czy MMF, dostarczona ilość wartości, etc.) aby mógł podejmować decyzje produktowe bazując na faktach.
- Przeprowadź zespół przez ciężkie fazy formowania się i konfliktu aby ustabilizować prędkość.
- Zorganizuj warsztaty wizji produktu aby pomóc PO zaangażować zespół w wizję i strategię produktu.
- Udzielaj regularnej informacji zwrotnej i sam(a) o nią proś; Doceniaj!
- i inne…
W ten sposób zbudujemy naturalną relację, w której my jako Scrum Masterzy wspomagamy nie tylko zespół developerski (z którym często siedzimy, z którym się kontaktujemy codziennie), ale także Product Ownera, który dostrzeże w takiej relacji wartość także dla siebie.
W takiej sytuacji dużo łatwiej nam jest współpracować z Product Ownerem i eksperymentować z nowymi narzędziami także w obszarze związanym z zarządzaniem produktem i wartością. Dzięki temu będziemy biec nie tylko szybko (efektywność, produktywność zespołu i organizacji), ale także w dobrym kierunku 🙂
Ostatnim, kluczowym elementem próbowania nowych narzędzi i metod z Product Ownerem jest prezentowanie ich na faktycznych przykładach z Waszej codziennej pracy. Szkolenia otwarte, bazujące na przykładach ‘uniwersalnych’ (i nierealnych, choć niewątpliwie ciekawych) są dobre aby przedstawić początkującym osobom podstawowe pojęcia. Dla zaawansowanych osób (jak większość PO, z którymi współpracowałem), takie szkolenia nigdy nie będą tak skuteczne, jak przećwiczenie danego narzędzia na ‘żywym organizmie’.
Jeśli więc masz zamiar przećwiczyć np. Opportunity Canvas - weź faktyczne problemy/pomysły z Product Backlogu (np. epiki do zrobienia) i przejdź z PO przez całe ćwiczenie bazując na tym przykładzie. Jeśli wypracowujesz sposób wyznaczania Business Value na podstawie obszarów wpływu (o tym jeszcze kiedyś będę pisał), to ‘rozpracujcie’ to na przykładzie obszarów produktu lub grupy produktów w waszej firmie. Moim zdaniem, taka nauka przez doświadczanie i eksperymentowanie jest najbardziej jednym z najbardziej efektywnych sposobów przekazywania nowej wiedzy i wdrażania nowych kompetencji.
Po czym poznać, że ‘zaskoczyło’ i jest szansa na to, że ludzie będą kontynuować pracę z nowymi narzędziami?
- W trakcie ćwiczenia następuje gorąca dyskusja (lub nawet spory co do wyniku) -> wyzwalają się emocje.
- Eksperymentowanie z kształtem samego narzędzia -> “Co by szatan zrobił z twoim feature’em” (o tym też może kiedyś 😉 jako dodatkowe pole w Opportunity Canvas.
- Po zakończeniu ćwiczenia/warsztatu, ludzie robią zdjęcia wyników lub wręcz zabierają je ze sobą.
- Powstają (spisane) akcje opisujące ‘co dalej’.
Pomagając Product Ownerom w efektywnym zarządzaniu produktem możemy mieć niejako uczucie ‘wchodzenia na cudze podwórko’. Z mojego doświadczenia mogę powiedzieć, że czasem chyba niepotrzebnie się tego obawiamy jako Scrum Masterzy 🙂 Jeśli pokażemy naszym Product Ownerom, że mogą mieć bezpośrednią korzyść z nowych sposobów pracy, że nam, jako Scrum Masterom, także zależy nam na efektywnym dostarczaniu wartości, to wspólny rozwój, eksperymentowanie i uczenie się będą tylko naturalną konsekwencją.