Scientific Agile

Problemem z którym często się spotykam, jest narzekanie na polityczne rozgrywki w organizacjach i małe zaangażowanie interesariuszy. Postanowiłam napisać przepis, jak Właściciel Produktu może zmieniać Przegląd Sprintu, aby stopniowo budować transparencje i współpracę. Tym razem opieram swoje rozważania nie na badaniach, a na wiedzy dotyczącej rozwiązywania konfliktów. Na koniec podaję kilka książek, które warto przeczytać. W tym artykule chciałam przedstawić ogólny zarys koncepcji, jak można pracować z interesariuszami przy wysokim poziomie konfliktów.

Na początek krótko omówmy poszczególne rodzaje konfliktów. W przypadku Review najczęściej możemy mieć do czynienia z ich trzema rodzajami – konfliktem danych, interesów i strukturalnym.

Konflikt danych

Konflikt danych polega na tym, że poszczególne osoby mają różne informacje na określony temat albo zrozumienie tych informacji jest rozbieżne. Ten konflikt jest stosunkowo łatwy do rozwiązania poprzez wyrównanie wiedzy, podzielenie się posiadanymi danymi oraz informacją o tym, w jaki sposób były one zbierane i interpretowane.

Co mogę zrobić jako PO? Konflikt danych rozwiązuje się dostarczając stronom aktualnych, rzetelnych i wiarygodnych informacji i upewniając się, że wszyscy tak samo je rozumieją.

Konflikt interesów

Konflikt interesów pojawia się tam, gdzie dostęp do ważnych dla nas rzeczy jest w jakiś sposób ograniczony. Jeżeli weźmiemy pod uwagę, że te “rzeczy” to: czas, nasza energia wkładana w pracę, dostęp do informacji, pieniądze, które kosztuje praca zespołu, sposób zgłaszania błędów, dostęp do środowisk, czas poświęcany na rozmowy telefoniczne i odpowiadanie na maile, to zaczyna być oczywiste, że ten rodzaj konfliktu jest niesłychanie częsty. Sposobem na jego rozwiązanie jest pokazanie potrzeb wszystkich stron, czyli transparencja a następnie wspólne szukanie najlepszego dla wszystkich rozwiązania.

W następnej kolejności należy pokazywać, jakie są wspólne interesy poszczególnych grup czy osób, a jeszcze lepiej, jakie są wspólne, nadrzędne wartości, którymi wszystkie strony się kierują. Znakomitym narzędziem do tego jest wizja i strategia firmy lub produktu. Pozwala ona otwarcie rozmawiać o tym, w jaki sposób można zaspokoić potrzeby i wspólnie szukać rozwiązań.

Co mogę zrobić jako PO? Transparentne pokazywanie interesów poszczególnych osób zmniejsza poziom rozgrywek. Prezentowanie, jak wpisują się one w strategię, na przykład za pomocą impact mapy, znacznie podnosi zrozumienie i współpracę.

Do ważnych interesów, często będących źródłem konfliktu, należy potrzeba godności, szacunku i zaufania, co należy wziąć pod uwagę za każdym razem, jak pracujemy z ludźmi.

Konflikt strukturalny

Ten rodzaj konfliktu pojawia się wtedy, kiedy struktura organizacyjna powoduje tarcia pomiędzy ludźmi. Może to wynikać z silosów kompetencyjnych, systemu wynagradzania albo niejasnych zakresów odpowiedzialności czy sposobu podejmowania decyzji. Tego typu konfliktów, pojedyncze osoby najczęściej nie są w stanie rozwiazać, dlatego ważne jest pokazywania problemów i ich konsekwencji, aby zbudować wspólne zrozumienie co i dlaczego należy zmienić. Jeśli ważne (dla klienta i firmy) potrzeby interesariusza nie są zaspokojone, to może to być sygnał, że wymagane są zmiany organizacyjne. Takim przykładem może być dział obsługi klienta, który jest traktowany po macoszemu i czeka długo na dostarczenie niezbędnych usprawnień, na czym cierpią klienci i renoma firmy.

Co mogę zrobić jako PO? Pokazywać problemy i ich konsekwencje, jednak nie obwiniać nikogo. Culture follows structure. Szukać osób, które mają wystarczającą decyzyjność, żeby wprowadzić zmiany i edukować ich. Być dla nich partnerem i wsparciem, a nie oskarżycielem.

Pokażę teraz, jak można zbudować Review w taki sposób, aby możliwe było polepszenie współpracy pomiędzy wszystkimi osobami zaangażowanymi w rozwój Produktu.

Dobre Review ma kształt klepsydry – pokazuje najpierw bardzo szeroko sytuację, aby potem przejść do szczegółowych rozmów o wytworzonym przyroście, a następnie z powrotem się rozszerza aby pokazać plan rozwoju produktu w dłuższym horyzoncie czasowym.

1. Wizja i strategia firmy dotycząca produktu

Ten pierwszy krok może wydawać się niepotrzebny, ale moje doświadczenia z wielu firm są takie, że ludzie często nie widzą powiązania między firmą jako całością a działaniami danego zespołu. Dlatego warto przypominać o tym, co nasza firma chce osiągnąć i jaki jest jej pomysł na to. Pokazujemy tutaj strategię firmy czy sektora w którym pracuje zespół. Pozwala to budować identyfikację z firmą, rozumieć skąd się biorą pewne decyzje, ale również umożliwia dyskusję nad niektórymi założeniami.

Jeśli jest tak, że praca zespołu nie wpisuje się w strategię firmy, to warto sobie zadać pytanie, czy nie należy tej sytuacji zmienić. W sytuacji, kiedy zespół jest po stronie wykonawcy a klientem jest inna firma, warto poświęcić chwilę na przypomnienie, jakie są założenia każdej z tych firm i co dla każdej z nich jest ważne (wydaje się to truizmem, ale kiedy ostatnio pytaliście osoby zarządzające software housem, jaka jest ich misja wobec klienta?).

Dodatkowo, Zespół Deweloperski był pochłonięty zadaniami przez ostatni Sprint. Pracując nad jakimś zagadnieniem trudno jest jednocześnie widzieć całość obrazu, więc zespołowi potrzebne jest regularne pokazanie kontekstu, w którym pracują. Z punktu widzenia klienta, użytkownika końcowego czy reszty interesariuszy takie wprowadzenie pozwala przypomnieć o wspólnych interesach oraz o korzyściach ze współpracy.

Co mogę zrobić jako PO? Przygotować i powiedzieć to, co opisane powyżej. Nie musi być to w żaden sposób formalne. Lepsze jest kilka zdań o tym, jaki cele staramy się osiągnąć i dlaczego są one ważne. Warto tu wspomnieć również o celach naszych klientów, aby budować zrozumienie ich potrzeb. Świetne może być pokazanie Impact Mapy.

2. Sytuacja przed sprintem, czyli co i dlaczego wybraliśmy do sprintu

Pamiętajmy o tym, że często osoby obecne na Review mogły nie być obecne na poprzednim, a jeśli nawet były, to mogą nie pamiętać wszystkich szczegółów. Dlatego warto przypomnieć, jaki był kontekst decyzji, których efektem jest praca wykonana w tym Sprincie.

Co mogę zrobić jako PO? Znowu – nie musi to być sztywna forma, warto powiedzieć o tym, jakie były najważniejsze problemy klienta, które Zespół rozwiązywał poprzez tworzony przyrost i dlaczego ustalono taki, a nie inny cel i zakres Sprintu. Warto tu wymienić główne elementy, jakie Zespół wziął na Sprint.

Takie omówienie ma na celu uwspólnienie danych posiadanych przez wszystkie obecne osoby. Jeśli Właściciel Produktu zdecydował się zaspokoić potrzebę jednych interesariuszy, a innych nie, to warto o tym wprost powiedzieć, szczególnie przytaczając niezaspokojone potrzeby i wykazując się zrozumieniem dla tego, jakie konsekwencje to ma dla tej osoby. Na przykładzie może to wyglądać tak: “Zdecydowałem się, że w ostatnim Sprincie dopasujemy naszą aplikację do wymogów RODO, ponieważ mamy taki obowiązek i ewentualnie konsekwencje dla firmy były bardzo poważne. Niestety spowodowało to, że nie przygotowaliśmy e-Raportów, które były potrzebne działowi Kadr i Ani, która go dzisiaj reprezentuje. Wiemy o tym, że jest to dla Was uciążliwe i powoduje, że musicie poświęcać około trzech dni pracy w miesiącu na ręczne przenoszenie danych.” Pokazanie tego, że rozumiemy czyjąś potrzebę, pamiętamy o niej i traktujemy ją poważnie pozwala budować lepszą współpracę.

3. Co zostało ukończone – aktywne użycie, feedback

Teraz już czas na zaprezentowanie przez Zespół ukończonych elementów. W zależności od Zespołu powiedzieć o wartości biznesowej ukończonej funkcjonalności może Właściciel Produktu albo dowolny członek Zespołu. Osobiście wolę to drugie, bo pozwala to Zespołowi myśleć z punktu widzenia klienta. W tej części warsztatu to Deweloperzy grają pierwsze skrzypce, Właściciel Produktu koncentruje się na zadawaniu pytań o feedback i odpowiadaniu na pytania interesariuszy.

Pamiętajmy o tym, żeby zgodnie z Definicją Ukończenia rzeczy, które pokazuje Zespół powinny być potencjalnie wdrażalne. Warto je pokazywać w jak najbardziej fizycznej postaci – jeśli się da, to czegoś co można wziąć do ręki albo przeklikać. Jeśli tylko jest taka możliwość, to należy na Review zapraszać użytkowników końcowych, bo to właśnie oni mogą dać najlepszy feedback do wytworzonego elementu. Jeśli wynikiem prac nie jest coś dotykalnego, ale na przykład poprawa wydajności aplikacji, to warto pokazać wykresy i dane oraz omówić je w sposób zrozumiały dla wszystkich.

Podsumowując – wynikiem tej części jest: lepsze zrozumienie przez Zespół, jak użytkownik końcowy korzysta z tego, co zrobili oraz jakie potrzeby klienta zaspokoił, a jakich nie. Klient lepiej rozumie, jak działa to, co dostarczył Zespół. Fizycznym efektem tej części są notatki Zespołu, jak modyfikacje sugeruje Klient. Przypomnę, że za priorytetyzację odpowiada Właściciel Produktu, na tym etapie Zespół zbiera informacje i je notuje. W zależności od specyfiki pracy Zespołu dyskusja o tym, czy daną rzecz zostanie zrobiona czy nie, może się odbyć teraz albo później.

Co mogę zrobić jako PO? Zadbaj o zaproszenie użytkowników końcowych, ich przedstawicieli oraz osób zainteresowanych produktem. Zadbaj o to, żeby mogli UŻYĆ przyrostu. Niech kryteria akceptacji zawierają możliwość wypróbowania produktu. Bądź ciekawy perspektywy innych osób i otwarty na ich uwagi. Szacunek dla ich potrzeb wcale nie znaczy, że to Ty masz je zaspokajać. Oznacza, że szanujesz ludzi.

Ciekawym zagadnieniem jest to, co z zagadnień technicznych powinno być pokazywane na Przeglądzie. O ile szczegóły techniczne rozwiązania pasują bardziej do warsztatu architektonicznego, o tyle Review jest świetnym miejscem, żeby budować zrozumienie jakości wśród interesariuszy. Co można do tego zaliczyć? Pokazanie na liczbach, jak refaktoring przyspieszył wprowadzanie zmian. Może to brzmieć przykładowo “Do tej pory wprowadzenie zmian w generatorze xyz zajmowało nam średnio 4 dni (dane z ostatniego roku). Teraz szacujemy, że nowe zmiany będziemy mogli wprowadzać w czasie o połowę krótszym.”. Dobrym pomysłem może być pokazanie, że przechodzą testy automatyczne dla wszystkich wprowadzanych zmian, ponieważ buduje to zrozumienie dla wagi automatyzacji. Warto tutaj również pokusić się o dokładniejsze dane, przykładowo “Dodaliśmy 15 nowych testów automatycznych, co skróciło ręczne testowanie o 15% (dane z ostatniego sprintu)”. Kolejną rzeczą, jaką warto pokazać, jest zmniejszenie liczby błędów: “Usunęliśmy kolejnych 25 błędów, które w sumie dotykały 129 użytkowników.”. Cenne będzie pokazanie, jak to poprawiło doświadczenia użytkownika. Bardzo wartościowym pomysłem jest pokazywanie schematu architektury produktu z zaznaczeniem, gdzie były błędy i pokazywaniem, jak wygląda sytuacja po Sprincie. Nie chodzi tutaj o wchodzenie w technikalia, a o edukowanie interesariuszy, że technologia sprzedawana pod nazwą produktu będzie tylko wtedy wartościowa dla klienta, kiedy będzie niezawodna i będzie umożliwiała naszej firmie szybkie i bezpieczne wprowadzanie zmian.

4. Co nie zostało ukończone

Ten punkt ma za zadanie budowanie transparencji i zrozumienia problemów, z jakimi zmaga się Zespół Deweloperski. Należy krótko omówić rzeczy, które miały być zrobione, a nie są ukończone, powiedzieć dlaczego tak się stało.

To, co jest ważne, to aby Zespół traktował siebie z szacunkiem i nie usprawiedliwiał się nadmiernie, jeśli naprawdę zrobił co mógł, aby osiągnąć cel sprintu. Oczywiście, nie zawsze od początku Zespół Deweloperski jest odpowiedzialny i zaangażowany. Jeśli chcemy to zacząć zmieniać, to warto w czasie planowania ustalić, co i komu Zespół będzie pokazywał w czasie Review.

Najczęściej problemem nie jest to, że Deweloperom nie zależy, tylko nie rozumieją konsekwencji niedostarczenia. Warto więc, żeby się dowiedzieli tego od osób, które czekają na wynik ich pracy.

Co mogę zrobić jako PO? Zapytaj się interesariusza, którego potrzeby nie zostały zaspokojone, jakie konsekwencje to dla niego powoduje. Celem jest wzbudzenie empatii u Zespołu. Jeśli więc podejrzewasz, że zareaguje obwinianiem, to spotkaj się z nim wcześniej i wyjaśnij mu sytuację – że chcesz, żeby Zespół go rozumiał i chciał rozwiązać jego problemy. W końcu dużo fajniej się pracuje dla osób, które lubimy, prawda?

Z drugiej strony, to jeśli na Review nie ma nikogo, komu zależy na danej rzeczy, to albo nie zadbałeś o obecność potrzebnych osób, albo ten ficzer jest naprawdę nieważny. Gdyby był ważny, a interesariusz nie mógł być obecny w czasie Review, to przysłałby kogoś w zastępstwie, albo umówił się z Zespołem w czasie sprintu, żeby dać feedback. Wtedy Zespół mógłby opowiedzieć innym, co usłyszał od takiej osoby.

Jednak nie należy tutaj iść w kierunku obwiniania czy wzbudzania poczucia winy w Zespole. Chodzi o to, żeby Deweloperzy mogli być dumni ze swojej pracy. Dlatego ważne jest, żeby Zespół Deweloperski brał na Sprint taką ilość pracy, jaką jest w stanie dobrze wykonać. Często “brak dowożenia” jest tylko syndromem przeciążenia Zespołu i tego, że takiej ilości pracy nie są w stanie wykonać albo nie mają do tego odpowiednich warunków, wiedzy czy narzędzi.

5. Problemy, jakie wystąpiły w czasie sprintu i przyjęte rozwiązania

Głównym celem tego punktu jest transparencja i budowanie wspólnego zaangażowania w rozwiązywanie problemów. Ten punkt jest poświęcony rozwiązywaniu konfliktów danych (jakie mamy problemy i jakie są ich konsekwencje), interesów i strukturalnych.

W przypadku każdego problemu, na jaki natrafia Zespół, należy zawsze zacząć od tego, żeby to Zespół spróbował go rozwiązać. Już samo zadanie sobie pytania “Czy wyczerpaliśmy nasze możliwości rozwiązania tego problemu i możemy z czystym sumieniem poprosić o pomoc w jego rozwiązaniu naszych interesariuszy?” jest świetnym motywatorem dla Zespołu do brania na siebie odpowiedzialności za usprawniania.

Na Review przedstawiamy wyniki podjętych działań i omawiamy ich skuteczność. Jeśli pewne rzeczy są poza wpływem Zespołu, a powodują niekorzystne skutki, to warto je transparentnie omówić. Dzięki temu jest szansa, że więcej osób w firmie zacznie mieć wspólne zrozumienie problemu i będzie przekonanych, że zmiany są potrzebne.

Co mogę zrobić jako PO? Zaproś na to spotkanie te osoby, które są w stanie coś zmienić, bo narzekanie w gronie bezsilnych nie poprawi sytuacji. Czasami jest tak, że dopiero zaproszenie zarządu klienta i wykonawcy (albo jeśli mamy zespół rozwijający produkt wewnętrznie, to dyrektorów zainteresowanych działów i prezesa) pozwala rozwiązać problem, a przynajmniej znaleźć osoby, które będą odpowiedzialne za dalszą zmianę.

Należy jednak zachować równowagę i pamiętać, że Przegląd jest dedykowany produktowi. Warto więc pokazać transparentnie problem i jeśli jest możliwe rozwiązanie go w ciągu 5 minut, to to zrobić. W innym przypadku warto przenieść szukanie rozwiązań na Retro lub dedykowane spotkanie.

6. Aktualne dane o sytuacji na rynku, konkurencji, zachowaniach użytkowników, wyniki badań

W tym momencie mamy już omówioną sytuację sprzed Sprintu, sam Przyrost jak i pojawiające się problemy. Teraz czas jest przejść do planowania dalszych prac. Jednak aby to było efektywne, to dobrze jest zbudować wspólną wiedzę na temat aktualnej sytuacji. To jest trudna część pracy Właściciela Produktu – zebrać i przekazać informacje o tym, co się dzieje aktualnie na rynku, czy zmieniły się jakoś przyjęte założenia, co robi konkurencja, jak wyglądają wyniki sprzedaży czy instalacji aplikacji. Mogą tutaj być pokazane statystyki z wykorzystania poszczególnych elementów produktu, informacje z Biura Obsługi Klienta czy serwisu, wyniki badań rynku albo użytkowników, jeśli takie były prowadzone. Oczywiście Właściciel Produktu nie musi robić tego sam, może o to kogoś poprosić. Jednak ramy czasowe takiej prezentacji powinien on określić, żeby nie było to zbyt długie i nużące dla uczestników. Ten etap to typowe zapobieganie konfliktowi danych oraz pokazywanie szerszego kontekstu, który pozwoli podjąć za chwilę lepsze decyzje.

Co mogę zrobić jako PO? Za wszelką cenę pokaż dane. Szczególnie te obrazujące, jak się zmienia zachowanie użytkowników. Jeśli Twój zespół nie dysponuje takimi danymi, to nie narzekaj, że nie jest zaangażowany i zmotywowany. Zadbaj o to, żeby te informacje były dla nich dostępne na bieżąco. “Jako Użytkownik chcę, żeby osoby rozwijające produkt, którego używam, kierowały się moimi potrzebami i moją wygodą, a nie zgadywaniem. Jakbym miał ochotę na wróżenie, to bym poszedł do wróżki, a nie do Twojej firmy”.

Pokazywanie danych na Przeglądzie zmienia dynamikę – wszyscy z zapartym tchem zaczynają śledzić, jak się zmienia użycie produktu. Przestaje być ważne, kto ma rację. Ludzi jednoczy wspólny cel, jakim jest stworzenie najlepszego produktu na rynku.

A poza tym, to jak nie masz danych, to nie masz podstaw do negocjowania z interesariuszami. Pozostaje Ci tylko robić to, co Ci każą.

7. Co planujemy na następny sprint – dyskusja, podjęcie decyzji

Dzięki temu doszliśmy do przedostatniego punktu, czyli rozmowy na temat tego, co planujemy na następny Sprint. Kluczowe jest to, że powinna to być rozmowa. Właściciel Produktu mówi o tym, co planuje i wszyscy wspólnie zastanawiają się, czy jest to najlepsza inwestycja pracy Zespołu. Jeśli cała reszta Review przebiegła odpowiednio, to w tym momencie wszyscy obecni mają wystarczającą wiedzę, żeby merytorycznie rozmawiać o możliwościach rozwoju produktu, korzyściach z różnych podejść i potrzebach poszczególnych interesariuszy.

Na miejscu Właściciela Produktu, który chce pobudzić współpracę, nie odrzucałabym od razu rozwiązań, nawet jeśli jest tak, że widzi on ich wady od samego początku. Jeśli rozmowa jest burzliwa, dużo lepszym pomysłem jest spisanie poszczególnych pomysłów, a potem rzeczowa rozmowa o tym, jakie korzyści i komu każde z tych rozwiązań daje. W przypadku, kiedy jest dużo sprzecznych interesów, warto żeby Właściciel Produktu miał przygotowane obiektywne kryteria na podstawie których podejmuje decyzje. Mogą to być kwestie finansowe, prestiżowe, technologiczne, związane z bezpieczeństwem, ważne, żeby były merytoryczne i mierzalne.

Co mogę zrobić jako PO? Istotne jest, żeby decyzje zostały podjęte w taki sposób, żeby wszyscy wiedzieli, jakimi obiektywnymi kryteriami się kierowałeś. Pozwala to ludziom zaakceptować decyzje, z których nie są zadowoleni.

Dlaczego tak ważne jest to, żeby pokazać różne interesy? Jednym z częstych problemów, z jakimi się spotykam w firmach, jest sytuacja, że zoptymalizowany jest zysk z jednego podproduktu, kosztem firmy jako całości lub wygody Klienta. Jest to niestety skutek wąskiego zdefiniowania produktów i sposobem na jego trwałe rozwiązanie są zmiany strukturalne. Jednak zanim to nastąpi warto dążyć do transparentnego podejmowania decyzji i zapraszać na Review wszystkie zainteresowane strony. Jeśli jest to niewygodne dla Właściciela Produktu, to jest to sygnał, że realizuje on bardziej cele związane z karierą lub wewnętrzną polityką, zamiast być rzecznikiem Klienta i pozycji produktu na rynku.

Podsumowując – rolą Właściciela Produktu jest rozmawianie z rozmaitymi interesariuszami, jednak rozmowy te muszą być transparentne. Szkodliwa polityka i konflikt karmią się nieujawnionymi informacjami. Dlatego tak istotne jest nauczenie wszystkich, że jedynym czasem i miejscem podejmowania decyzji o produkcie jest Przegląd. Wymaga to od Właściciela Produktu konsekwencji i zapraszania interesariuszy do wspólnych rozmów. Interesariusze szybko się nauczą, że nie opłaca im się opuszczać Review, bo to będzie powodowało, że ich głos nie zostanie usłyszany. Od całego Zespołu Scrumowego wymaga to przygotowania dobrego WARSZTATU, bo Review jest warsztatem, a nie spotkaniem statusowym.

Właścicielu Produktu, dopóki robisz Demo, to nie dziw się, że jest słabo i mało kto tam przychodzi. Zacznij od poprawy tego, na co masz wpływ i co jest zakresem Twoich obowiązków. To Twój warsztat. Niech będzie najlepszy, na jaki Cię stać. Wymagaj od Zespołu, żeby można było użyć produktu. To może wymagać przygotowania środowisk lub danych testowych. Jeśli już rozumiesz, dlaczego to jest tak ważne, to daj na to przestrzeń Zespołowi w najbliższym Sprincie. “Jako UŻYTKOWNIK chcę użyć produktu w trakcie przeglądu, aby produkt mógł być udoskonalony dzięki mojemu feedbackowi”.

8. Co planujemy w dłuższym odcinku czasu – roadmapa produktu

To już ostatni punkt Review, którego celem jest sprawdzenie, czy pomysł PO na długofalowy rozwój Produktu uwzględnia wszystkie ważne rzeczy. Możemy na to spojrzeć jak na ostateczne uwspólnienie danych posiadanych przez Product Ownera, Zespół i obecnych interesariuszy. Należy omówić co i kiedy planujemy zrobić, w jakiej kolejności będzie rozbudowywany Produkt, jakie główne fakty i terminy bierzemy pod uwagę przy jego planowaniu. Korzyścią z takiego pokazania roadmapy jest uspokojenie emocji, bo jeśli rozmaici interesariusze wiedzą, kiedy się spodziewać zaspokojenia swoich potrzeb, to łatwiej jest im czekać. Jeśli dodatkowo wiedzą, dlaczego nie dostaną tego od razu, i rozumieją ważność tych powodów, to prawdopodobnie będą bardziej skorzy do współpracy i grania do wspólnej bramki.

Co mogę zrobić jako PO? Przygotuj i pokaż prostą, czytelną roadmapę. Miej ją zaktualizowaną na każdym Przeglądzie. Bardzo dobrym artefaktem do zaprezentowania jest również Story Mapa. Świetnie na niej widać, co i kiedy dostarczymy użytkownikom.

Uwagi końcowe. Jak i kiedy przygotować się do Review?

Najlepiej jest zacząć od razu na Planowaniu. Jak Zespół ustali już zakres Sprintu i jego cel, to dobrze jest poświęcić chwilę na ustalenie, jak wyniki swoich prac będą chcieli pokazać na Review i kogo trzeba zaprosić, aby otrzymać wartościowy feedback. Dzięki temu, Zespół od razu, na początku Sprintu będzie wiedział czego się spodziewać. Jest to szczególnie ważne w przypadku mało dojrzałego Zespołu. Poza tym zaproszenie niektórych interesariuszy może nie być łatwe i lepiej to zrobić dużo wcześniej.

Co Zespół musi ustalić przed Review:

1. Kto, co i w jaki sposób pokaże? Czy nie trzeba przygotować czegoś jeszcze (przykładowych danych,wstępnie przygotowanych elementów do modyfikowania, uprawnień itp)?
2. Kto będzie zapisywał uwagi? Prawdopodobnie nie warto, aby to robiła osoba pokazująca. Bardzo prawdopodobne, że nie warto, żeby robił to Product Owner, który raczej jest skupiony na rozmowie. Moje doświadczenia są takie, że warto wyznaczyć osobnego “skrybę” albo na całe spotkanie, albo do poszczególnych jego części.
3. Kto jest w stanie rozwiązać problemy, które dotykają Zespołu – pozwoli to zaprosić te osoby na Review.

Co Właściciel Produktu musi przygotować przed Review:

Przez cały Sprint Właściciel Produktu gromadzi wiedzę i zrozumienie potrzebne mu do przygotowania dobrego Review. Dobrego, to znaczy takiego, które pozwoli podejmować jak najbardziej trafne decyzje. Decyzje,które maksymalizują ROI z pracy Zespołu. Decyzje podejmowane w oparciu o rzetelne dane i zrozumiałe kryteria. Większość tej pracy to codzienność Właściciela Produktu, jednak warto, żeby przygotował je w czytelnej dla wszystkich formie. Często wystarczy Excel z kilkoma informacjami czy prosty schemat, prezentujący plan rozwoju produktu. Ważne, żeby nie było to zbyt pracochłonne i było łatwo modyfikowalne, bo inaczej ciężko będzie mu znaleźć czas na przygotowanie tego przed każdym Przeglądem Sprintu.

Co może pomóc, jeśli interesariusze zachowują się mało konstruktywnie?

Z jednej strony jest bardzo korzystne, żeby Zespół oraz pozostali interesariusze projektu mogli nawzajem siebie usłyszeć. Jednak z drugiej strony nie wszyscy umieją przekazywać swoją perspektywę w sposób efektywny. Można spróbować kilku rzeczy.

Po pierwsze Właściciel Produktu albo Scrum Master może porozmawiać z taką osobą PRZED spotkaniem, wyjaśniając jaki jest cel Przeglądu oraz jakiego zachowania oczekują i jakie negatywne skutki może mieć ich zachowanie. Po drugie, należy w samym zaproszeniu opisać jaki jest cel Review i po co dana osoba została zaproszona. Na samym początku spotkania warto, żeby Scrum Master albo Product Owner powiedział, jaka jest agenda. Jeśli interesariusz wie, że będzie czas przeznaczony na zgłoszenie przez niego uwag, to prawdopodobnie chętniej poczeka do właściwego momentu.

Wreszcie, w niektórych sytuacjach warto, żeby to Product Owner zrecenzował potrzebę albo punkt widzenia niektórych interesariuszy i tylko poprosił ich o potwierdzenie, czy dobrze to przedstawił. Pozwala to nie tylko zaoszczędzić czas, ale też buduje zaufanie do Product Ownera, że niezależnie od podejmowanych decyzji, rozumie on dobrze sytuację danego interesariusza oraz jego potrzeby.

Uwaga końcowa: opisane Review nie jest ideałem. Jest sposobem pracy nad zmianą politycznej organizacji. Jeśli pracujesz w środowisku, gdzie nie ma politycznych rozgrywek, rozbudowanej struktury i produkt jest odpowiednio zdefiniowany, to ciesz się życiem i rozwiązuj innego typu problemy. Opisane tu rozwiązanie jest oczywiście kontekstowe i w targranej rozgrywkami firmie będzie krokiem do przodu. W startupach, małych firmach lub produktowych organizacjach nastawionych na klienta mogłoby być krokiem wstecz.

Bibliografia

R. Fisher, W. Ury, B. Patton „Dochodząc do Tak. Negocjowanie bez poddawania się”
W. Ury „Odchodząc od NIE. Negocjowanie od konfrontacji do kooperacji”