Relacja między Product Ownerem, Scrum Masterami i Developerami jest kluczowa dla sukcesu zespołu Agile. To symbiotyczna relacja, która opiera się na jasnej komunikacji, wspólnych celach, przejrzystości i jest zbudowana na zaufaniu. Budowanie produktu, który jest szeroko adoptowany, lub ciągłe doskonalenie to zwykle cel, ale spójność i dynamika zespołu mogą decydować o tym, jak płynny i bezbolesny jest ten proces.
Chcieliśmy dowiedzieć się więcej, więc postanowiliśmy znaleźć Product Ownera, który podzieli się swoimi spostrzeżeniami i historiami.
Po jego prezentacji mapy drogowej produktu na spotkaniu Agile w Perth, usiedliśmy z Adamem Mullettem, autorem książki „Od «Nie» do «Jak?»: Zdobądź poparcie i przewódź zmianom” i Product Ownerem, aby zapytać go o jego opinię na temat poziomu zaangażowania, jaki Product Owner powinien mieć w retrospektywie.
To, co otrzymaliśmy, to nie tylko odpowiedź na pytanie, ale demonstracja roli Product Ownera i odnowione docenienie zaufania, przejrzystości i dyscypliny.
Relacja między product ownerem, scrum masterami i zespołem agile
Adam wydawał się nieco zaskoczony, kiedy zapytano go, czy Product Owner powinien być zaangażowany w retrospektywę.
Pytanie wynikało z obserwacji, że niektórzy ludzie zaangażowani w agile postrzegali obecność Product Ownera na retrospektywie jako opcjonalną, a nawet przeszkodę.
Po krótkiej chwili jego odpowiedź brzmiała stanowcze „tak!”
Następnie wyjaśnił „dlaczego” –
Jednym z ważnych aspektów Agile jest to, że nie chodzi o bycie szybkim, ale o bycie adaptowalnym — co prowadzi do większego sukcesu, takiego jak lepsza adopcja produktu.
Jeśli chodzi o prowadzenie retrospektyw zespołu, ważne jest nie tylko ułatwianie procesu, ale równie ważne jest zarządzanie kulturą. Zespół tak bardzo polega na kierunku i wkładzie Product Ownera jako eksperta merytorycznego. Product Owner tworzy środowisko, w którym zespół może dążyć do wysokiej wydajności, będąc odpowiedzialnym za wyniki i samozarządzając się, tak aby pozostawał odpowiedzialny wobec swoich interesariuszy.
Zaufanie i przejrzystość
Adam postrzega, że fundamentem Product Ownera jest zaufanie i przejrzystość.
„Dla mnie bycie transparentnym to dar, ponieważ dzielisz się tym, co myślisz lub co wiesz. Jeśli zespół nie może tego od ciebie uzyskać, to nie dajesz im tego, czego potrzebują, aby odnieść sukces.”
„Nie powinno być żadnych tajemnic między zespołem, Scrum Masterem a PO. Dla mnie skupiłbym się na tych rzeczach. Wolałbym poruszyć problem i zagłębić się w konflikt, niż pozwolić mu narastać.”
„Możliwość odkrycia czegoś, co powstrzymuje zespół przed pójściem naprzód, jest naprawdę cenna.”
Adam podał przykład dwóch członków zespołu, którzy nie rozmawiali ze sobą w zespole, który kiedyś coachował.
„To było niewyobrażalne! Więc jeśli podczas retrospektywy pojawił się komentarz związany z problemem, kontynuowałbym drążenie, zagłębiając się w «dlaczego», dopóki nie zdali sobie sprawy, że problemem był brak komunikacji.”
Chociaż podejście było nieco konfrontacyjne, gdy problem został wydobyty na światło dzienne, łatwiej było się nim zająć, a członkowie zespołu byli później wdzięczni, że sprawa została rozwiązana.
„Rozwiązanie tego typu problemów może być tak proste, jak zaproponowanie innych godzin pracy. Nie rozmawianie ze sobą po prostu nie było dobrym powodem, aby nie być zespołem o wysokiej wydajności.”
Wprowadzaj ludzi do rozmowy
Product Owner powinien mieć współpracę na pierwszym planie, dlatego Adam dąży do współtworzenia.
„Jeśli coś robię, chcę to robić z tobą, a nie tobie. Żadna zmiana nigdy nie zakończy się sukcesem, jeśli robisz ją sam.”
„Ponieważ współpraca zespołowa jest potrzebna do współtworzenia, ważne jest, aby wiedzieć, jak i kiedy włączyć ludzi do rozmowy. Wybór sposobu prowadzenia rozmów może mieć duże znaczenie.”
„Na przykład łatwiej jest pokazać komuś swoją pracę, niż go przekonywać. Godzinny prototyp, o którym można porozmawiać, jest czasami znacznie skuteczniejszy niż duża sesja planowania, podczas której próbujesz sprzedać swój pomysł. Innym razem lepiej jest tworzyć wspólnie.”
Bądź zdyscyplinowany w procesie i wynikach
Kiedy dyscyplina jest postrzegana jako platforma wsparcia, a nie bariera dla elastyczności, może działać jako mechanizm wzmocnienia zespołu.
Dyscyplina może być tak prosta, jak rozpoczynanie spotkania na czas, kończenie na czas i posiadanie ścisłej definicji „gotowości”. Są to małe, uzgodnione zachowania, których członkowie zespołu przestrzegają w celu świadomego poprawiania spójności i wzajemnego szacunku w zespole.
Zdaniem Adama dzięki dyscyplinie można wspierać zdrowe nawyki, które wspierają zespoły o wysokim funkcjonowaniu.
„Byłem Product Ownerem w projekcie, gdzie było 23 zespoły i ogólne nastawienie na przetrwanie tego sprintu, potem kolejnego sprintu i jeszcze kolejnego, po prostu przetrwać sprint, jakkolwiek by się dało.”
„Potem zaczęliśmy być bardziej zdyscyplinowani w sprincie.”
„Tak, pierwszy miesiąc był trudny, ponieważ próbowaliśmy robić dwie rzeczy naraz. Ale potem wszystko szło gładko. A zespół był w stanie kontynuować doskonalenie i rozwijać się jako zespół o wysokiej wydajności. W rzeczywistości inni w organizacji chcieli być częścią tego zespołu.”
Zaobserwowano również, że zespoły, którym brakowało dyscypliny, doświadczały problemów.
Więc co powinno się stać, jeśli członkowie zespołu nie przyjęli zdyscyplinowanego podejścia?
„Jeśli ktoś przychodzi nieprzygotowany, ważne jest, aby jasno określić cel spotkania i to, w jaki sposób jego działania nie wspierają tego celu.”
„Chodzi o skupienie. Na przykład podczas groomingu produktu, jeśli ludzie zaczynają rozmawiać o konkretnym zadaniu, to chodzi o przywrócenie uwagi na to, dlaczego odbywamy to spotkanie i co chcemy osiągnąć jako wynik tej ceremonii.”
Oczywiście Scrum Master pomaga utrzymać tę dyscyplinę.
Jeśli chodzi o ich retro, Adam dodał, że gdy zespół rozumie i docenia strukturę, którą zbudowała ich dyscyplina, jest znacznie bardziej skupiony i efektywny, bez konieczności angażowania się w myślenie Systemu 2, jak opisano w książce Thinking Fast and Slow Daniela Kahnemana.
„Posiadanie jasnego procesu ułatwia sprawy. Zespoły nie chcą martwić się o takie rzeczy, jak to, którego pomieszczenia lub technologii używają. Ich uwaga skupia się na rzeczywistym problemie.”
Buduj swój zespół, gdy oni budują rozwiązania
Jeśli chodzi o Adama, nie ma braku jasności co do roli Product Ownera; jeśli jesteś Product Ownerem, jesteś częścią zespołu agile.
„Uważam, że rolą Product Ownera, przy wsparciu Scrum Mastera, jest budowanie kultury i tworzenie jasności dla zespołu.”
„Zespoły nienawidzą nie wiedzieć, dokąd zmierzają. Zwracają się przeciwko sobie, stają się niespokojne, próbują wyglądać na zajęte i doświadczają wszelkiego rodzaju innych dysfunkcji. Jeśli możesz dać ludziom powód, «dlaczego», strategiczny kierunek, wtedy powiedzą: «dobra, super. Rozumiem!» Chodzi więc o to, aby być luźno powiązanym, ale ściśle zorientowanym. W ten sposób wszyscy wiemy, dokąd zmierzamy, a następnie pozwalamy zespołowi tam dotrzeć.”
Adam pracował z zespołami w pełni stacjonarnymi, zdalnymi i hybrydowymi. Przez 18 miesięcy pracował z ludźmi rozrzuconymi od Sydney po Indie. Bez względu na skład, jednym z czynników sukcesu zespołu o wysokiej wydajności było zrozumienie, co będzie dalej.
„Więc jeśli coś wydarzy się w naszej retrospektywie, ktoś stworzy zadanie w Jira. Ludzie mogli nadal współpracować, nawet jeśli nie zawsze byli w tym samym pomieszczeniu. Silne sposoby pracy pomogły to umożliwić.”
Rola product ownera w agile retrospective
Wracając do pytania o rolę Product Ownera w retrospektywie, Adam zauważył, że Product Owner jest uczestnikiem.
Jego zdaniem sama retrospektywa może być prowadzona przez każdego w zespole, z jego preferencją, żeby facylitacja była rotowana między członkami zespołu, tak żeby te umiejętności mogły być rozwijane i doceniane przez zespół.
„Myślę, że zespół chce, aby PO był uczciwy i otwarty podczas uczestnictwa.”
Jeśli chodzi o to, co product owner ma nadzieję pomóc osiągnąć na retro, odpowiedź Adama jest prosta — to dla zespołu, żeby stał się lepszy w tym, co robi.
Dlaczego?
„Ponieważ PO jest odpowiedzialny przed organizacją za wyniki, jeśli chodzi o to, ile czasu coś zajęło, aż po wykorzystane zasoby. Zespół jest odpowiedzialny za dostarczanie wyników. Więc sprytny PO będzie uczestniczył w retrospektywie, aby słuchać. Nie będzie mówił ludziom, co mają robić, ani że powinni to robić «w ten sposób». Gdyby zespół już wiedział, zrobiłby to.”
Adam postrzega retrospektywę jako okazję dla zespołu do –
- odkrywania rozwiązań
- dowiadywania się rzeczy po drodze, żeby być zespołem o wysokiej wydajności i
- wspinania się po drabinie dojrzałości.
Product Owner chce pomóc zbudować zespół o wysokiej wydajności z wielu powodów –
- żeby poprawić przewidywalność
- żeby mieć dobre, solidne, regularne zarządzanie user story
- żeby poprawić ogólną pewność i jakość
w miarę jak funkcje są rozwijane w czasie.
Zachęcaj i umożliwiaj zmiany na swoich retro
Więc dlaczego retro działają?
„Myślę, że to dlatego, że zespół ma uprawnienia do wymyślania rzeczy, które może zmienić. Mogą definiować cele SMART, które mogą wprowadzić w życie w ciągu najbliższych dwóch tygodni. Wymyślają problem, który ich dotyka, więc są samodzielnie ukierunkowani na zmianę.”
Zauważono, że niektórzy ludzie mogą obawiać się zmiany, ponieważ coś jest im robione, i nie czują, że mają kontrolę.
„Coś, do czego odwołuję się w książce „Od «Nie» do «Jak?»”, to sfera wpływu i ośrodki kontroli. Ważne jest, aby pomóc zespołowi skupić rozmowy na tym, gdzie leży ich ośrodek kontroli, aby czuli się uprawnieni i zdolni do wprowadzania zmian.”
„Powinni czuć, że mogą polegać na PO, aby wykorzystać jego wpływ lub kapitał społeczny do wpływania poza sferę wpływu zespołu.”
„W międzyczasie, jeśli zespół agile czuje, że kontroluje swoje przeznaczenie, to może zmienić swój świat i sprawić, że rzeczy się wydarzą. Czują się bardziej uprawnieni do działania i mogą wtedy iść naprzód i realizować zadania.”
Jak product owner może poprowadzić zespół z dala od dysfunkcji
Nie mogliśmy pozwolić Adamowi odejść bez zapytania o jego radę, jak przejść z zespołem od dysfunkcji do wysokiej wydajności.
Kluczowe wnioski:
- Upewnij się, że wszyscy wiedzą, dokąd zmierzają, jaki jest ich cel i upewnij się, że wszyscy są na tej samej stronie.
- Upewnij się, że jest dobra komunikacja; czy to między członkiem zespołu a członkiem zespołu, Product Ownerem a Scrum Masterem, komunikacja musi być otwarta i szczera.
- Dyscyplina! Daj ludziom platformę do kreatywności. Zaczynaj na czas, skupiaj się na tym, o czym jest spotkanie. Zapewnia to strukturę, dzięki której ludzie mogą się rozwijać.
- Zawsze mów im „dlaczego”
- Wskazuj dysfunkcję. Identyfikowanie problemów, konfliktów i błędów jest świetne, ponieważ coś zostało odkryte.
Czy masz jakieś inne spostrzeżenia lub historie do podzielenia się na temat tego, jak poprawiłeś relacje robocze między swoim zespołem scrumowym a product ownerem? Chętnie byśmy, żebyś podzielił się z nami.
„Od «Nie» do «Jak?»: Zdobądź poparcie i przewódź zmianom” zachęca do dzielenia się wynikami nieudanych prób ulepszeń z kolegami i szefem jako sposobem na utrwalenie lekcji i dzielenie się nauką z innymi.