5 porad jak przeprowadzić udany Refinement

Dużo pisze się i mówi o tym, jak poprawnie przeprowadzać wydarzenia w Scrumie. Wiele osób jednak zapomina, że bez dobrze przygotowanego Backlogu Produktu nawet najlepiej wykonane wydarzenia na nic się zdadzą. W tym artykule dzielę się pięcioma praktycznymi radami, jak skutecznie doskonalić Backlog Produktu.

1. Zarezerwuj odpowiednią ilość czasu na proces doskonalenia Backlogu Produktu

Według Przewodnika po Scrumie, proces doskonalenia Backlogu Produktu (ang. refinement) zwykle zajmuje nie więcej niż 10% czasu Zespołu Deweloperskiego w Sprincie. Jest to ogólna porada, za którą jednak nie zawsze warto podążać.

Wyobraź sobie sytuację, w której Zespół Scrumowy rozpoczyna pracę nad nowym obszarem produktu, którego jeszcze dobrze nie poznał. Potrzebuje czasu, żeby zdobyć wiedzę, omówić potencjalne możliwości i zdobyć potrzebny kontekst biznesowy. Elementy w Backlogu Produktu na tym etapie prac mogą być mgliste, bardzo ogólnie opisane oraz nieoszacowane. W takim przypadku poświęcenie 10% czasu Sprintu na pracę nad Backlogiem Produktu może okazać się zbyt małą ilością czasu, aby zrobić to na poziomie pozwalającym efektywnie rozwijać produkt.

Porada, którą dzielę się z zespołami, gdy pytają mnie, ile czasu inwestować w refinement, jest następująca: poświęć tyle procent czasu Sprintu na doskonalenie Backlogu Produktu, ile wymaga jego aktualna kondycja oraz wiedza Zespołu Scrumowego.

Jeżeli Twój Backlog Produktu posiada odpowiednią ilość szczegółów, jest oszacowany oraz uporządkowany, a Zespół Scrumowy doskonale rozumie, z jakim problemem się mierzy, być może potrzebujesz mniej niż 10% czasu Sprintu na utrzymanie go w takim stanie.

Z drugiej strony, jeżeli w zespole brakuje wiedzy o wytwarzanym produkcie — co niestety często obserwuję w praktyce — to może się okazać, że trzeba będzie poświęcić np. 50% czasu Sprintu na zapewnienie odpowiedniego poziomu zrozumienia domeny problemu oraz odzwierciedlenia tej wiedzy w Backlogu Produktu.

2. Zapraszaj ekspertów dziedzinowych

Pułapką, w które często wpadają Zespoły Deweloperskie jest założenie, że podczas doskonalenia Backlogu Produktu muszą radzić sobie sami, posiłkując się wyłącznie rolą Właściciela Produktu.

Jednak może się zdarzyć, że Właściciel Produktu będzie odpowiadać za obszar, którego nie jest w stanie samodzielnie objąć merytorycznie lub zrobi to na niedostatecznie dobrym poziomie. W takich sytuacjach może posiłkować się ekspertami dziedzinowymi (ang. Subject-Matter Expert), którzy pomogą mu zdobyć konieczną wiedzę i odzwierciedlić ją w Backlogu Produktu.

Minusem rozwiązania, w którym Właściciel Produktu samodzielnie wchodzi w interakcje z ekspertem dziedzinowym jest fakt, że staje się przekaźnikiem wiedzy pomiędzy ekspertem a zespołem. Dlaczego uważam to za potencjalny problem?

Po pierwsze, w procesie przekazywania wiedzy, Właściciel Produktu może nie pokryć wszystkich pytań, które mogłyby urodzić się w głowach Zespołu Deweloperskiego.

Po drugie, istnieje ryzyko, że wiedza ta zostanie nieumyślnie zmodernizowana na skutek błędnego zrozumienia słów eksperta.

Po trzecie, szansa na zbudowanie relacji pomiędzy Zespołem Deweloperskim a ekspertem zostaje zaprzepaszczona, ponieważ za całość komunikacji odpowiada wyłącznie Właściciel Produktu, izolując eksperta od zespołu.

Stąd moja rekomendacja dla Zespołów Deweloperskich jest następująca: włączajcie ekspertów dziedzinowych w proces doskonalenia Backlogu Produktu, abyście mogli bezpośrednio zaczerpnąć z ich wiedzy oraz budować z nim relację.

Wielokrotnie uczestniczyłem w bardzo owocnych dyskusjach pomiędzy Zespołem Deweloperskim a ekspertem (lub ekspertami), które pełne były parafrazowania, upewniania się, że obustronnie się rozumiemy, oraz bieżącego wizualizowania omawianego obszaru wiedzy. Przekonałem się również w praktyce, że komunikacja twarzą w twarz przy jednoczesnym korzystaniu z tablic suchościeralnych, to najbardziej efektywna i bogata forma przekazywania informacji.

—————

Najbliższy warsztat

Warsztaty „Labirynty Scruma” — Wrocław — 9-10 grudnia: podczas autorskich warsztatów na bazie mojej książki, przepracuję z Tobą najczęstsze pułapki w Scrumie oraz wskażę sprawdzone sposoby, jak sobie z nimi radzić.

—————

3. Iteracyjnie pracuj nad elementami Backlogu Produktu

Widziałem wiele spotkań Zespołów Scrumowych, podczas których próbowały one w jednym podejściu uchwycić duży, złożony i mglisty kawałek produktu. Zwykle próba okiełznania tak dużego obszaru kończyła się zmęczeniem zespołu i poczuciem, że nadal istnieje wiele pytań bez odpowiedzi, a ryzyko błędnych założeń nadal było całkiem spore. W skrajnych przypadkach sytuacji nie poprawiało oczekiwanie Właściciela Produktu, że omawianym tematem zespół zajmie się od najbliższego Sprintu.

Gdy obserwuję takie sytuacje, rekomenduję zespołom, aby iteracyjnie pracowały na elementami w Backlogu Produktu. Jak taka praca może wyglądać w praktyce?

Wyobraź sobie, że Właściciel Produktu przychodzi do zespołu pierwszy raz (N) z tematem np. nowego sposobu rozliczania faktur klientów. Jest to pierwsze, ogólne spotkanie, podczas którego Zespół Scrumowy próbuje uchwycić istotę biznesową zmiany oraz wyłapać najważniejsze aspekty techniczne. Takie spotkanie może zakończyć się stworzeniem listy pytań, zarówno biznesowych jak i technicznych, z którymi możemy udać się do osób, które mogą nam pomóc znaleźć odpowiedzi. Kim są te osoby? Mogą to być inne zespoły w organizacji, eksperci dziedzinowi, Właściciele Produktu, szefowie obszarów itp.

Na kolejne spotkanie (N + 1) Zespół Scrumowy przynosi zebrane odpowiedzi biznesowe jak i techniczne. Dyskutuje, analizuje i pogłębia temat. Czują, że wiedzą więcej, ale nadal nie jest to wystarczająco dużo, żeby rozpocząć pracę. W efekcie Zespół Deweloperski decyduje się na napisanie kawałka kodu, który pomoże im zrozumieć dziedzinę problemu, a Właściciel Produktu obiecuje pojawić się na kolejnym spotkaniu z kilkoma przykładami z życia, jak wyobraża sobie rozliczanie faktur w praktyce.

Następne spotkanie (N + 2) to prezentacja efektów pracy Zespołu Deweloperskiego, który odkrywa pisząc kod, że temat jest bardziej złożony niż pierwotnie myśleli. Z kolei Właściciel Produktu objaśnia kilka przykładów z życia, które pozwalają Zespołowi Scrumowego wybrać z nich te najczęściej występujące w praktyce.

Jeżeli istnieje potrzeba kolejnej iteracji pracy nad tematem (N + 3), zespół decyduje się na nią. Jeśli nie — przechodzą do kolejnych zagadnień.

Z mojego doświadczenia iteracyjne podejście do budowania zrozumienia na temat problemów do rozwiązania to całkiem skuteczna metoda radzenia sobie z dużymi tematami, których zespół nie jest w stanie rozpracować w jednym podejściu.

4. Wyłącz narzędzia elektroniczne

Kolejna porada może zasmucić wiele osób — rekomenduję, aby wyłączyć narzędzia elektroniczne (Jira, Trello, Excel itp.) podczas sesji doskonalenia Backlogu Produktu.

Skąd ten pomysł? Wielokrotnie byłem świadkiem spotkań, podczas których cały Zespół Scrumowy siedział w salce, naprzeciwko dużego ekranu, na którym wyświetlane były elementy Backlogu Produktu. Zwykle w takich sytuacjach obserwuję trzy rzeczy.

Po pierwsze, zaangażowanie w dyskusję jest odwrotnie proporcjonalne do odległości siedzenia od ekranu. Innymi słowy, im dalej konkretne osoby siedzą od ekranu, tym zwykle mniej włączone są w spotkanie.

Po drugie, jest to formuła, która w bardzo niewielkim stopniu angażuje uczestników. I zwykle jedyne co mogą zrobić, to komentować słownie dyskusję, która toczy się w sali.

Po trzecie, zwykle komunikacja jest ograniczona do słów oraz notowania ich w narzędzi, kompletnie pomijając możliwość wzbogacenia dyskusji wizualnie, poprzez szkicowanie rozwiązań, koncepcji czy pomysłów na kartkach, flipchartach lub tablicach suchościeralnych.

Jeżeli masz taką możliwość, żeby zebrać osoby biorące udział w sesji doskonalenia Backlogu Produktu w jednym pomieszczeniu, spróbuj alternatywnych sposobów pracy, na przykład:

  • Wydrukuj elementy Backlogu Produktu z narzędzia i rozdaj je uczestnikom
  • Rozrysuj omawiany problem na tablicy suchościeralnej
  • Zaprezentuj, jak z problemem Twojego Zespołu Scrumowego radzi sobie konkurencja

Jeśli czytałeś moją książkę “Labirynty Scruma”, to wiesz, że jestem fanem, aby po tego rodzaju spotkaniach pozostawał ślad. Nic więc nie stoi na przeszkodzie, aby z takiego spotkania powstawały notatki, które później staną się wsadem do Backlogu Produktu. Co więcej, takie notatki można tworzyć elektronicznie podczas spotkania, bezpośrednio w wykorzystywanym narzędziu. Ważne tylko, żeby obserwacja przez Zespół procesu pisania kolejnych ustaleń czy obserwacji nie stała się główną osią takiego spotkania.

5. Eksperymentuj

Przyzwyczajenie jest drugą naturą człowieka, stąd wiele zespołów łatwo przywyka do sposobu, w jaki doskonalą Backlog Produktu. Cała dalsza treść tego punktu to zachęta do eksperymentowania z formą pracy. Co może ulegać zmianie?

Poniżej kilka punktów do rozważenia:

  • Ilość czasu przeznaczanego na doskonalenie Backlogu Produktu. Warto testować, jak dokładnie lub odejmowanie czasu przeznaczanego na doskonalenie wpływa na to, co wytwarzamy jako Zespół Scrumowy.
  • Forma przeprowadzania doskonalenia. Dla jednych zespołów lepiej sprawdzi się doskonalenie w formie z góry zdefiniowanych spotkań, inne zespoły preferują pracę nad Backlogiem Produktu na zasadzie “kiedy będzie potrzeba, będziemy rozmawiać”.
  • Długość sesji doskonalenia. Pracowałem kiedyś z zespołem, który co środę rezerwował 4h na pracę nad Backlogiem Produktu. Z kolei znam też zespoły, które nie potrafią doskonalić dłużej niż 1h dziennie, ze względu na szybkie wyczerpanie energetyczne.
  • Interaktywność doskonalenia. Forma może przybierać różne kształty: od mało angażującego czytania z ekranu, poprzez dyskusje, na wizualizowaniu i budowaniu prototypów kończąc. Taki sam temat można przepracować zarówno w bierny, jak i bardzo angażujący sposób.
  • Zarządzanie dynamiką spotkania. Można dyskutować całą grupą, a można podzielić się na mniejsze podgrupy. Te same podgrupy mogą omawiać ten sam problem, albo równolegle omawiać różne problemy.
  • Moderacja wydarzenia. W szczególności, jeżeli pracujesz w większej organizacji, możesz zaprosić osobę, która gościnnie poprowadzi Wasze doskonalenie. Dzięki temu macie szansę poznać inne sposoby doskonalenia, inne techniki czy pomysły na to, jak organizować sobie pracę.

Podsumowanie

Scrum to ramy postępowania, stąd z Przewodnika po Scrumie dowiadujemy się, dlaczego doskonalenia Backlogu Produktu jest ważne, jednak trudno szukać konkretnych porad, jak postępować w codziennym życiu. Powyższe porady to suma moich interakcji z różnymi zespołami, w różnych organizacjach, rozwijających różne produkty. Nie jest to z pewnością zamknięta lista, a raczej punkt startowy do dalszego odkrywania jeszcze lepszych sposobów pracy.

Chcesz dowiedzieć się więcej?

Tematy podobne to tych w artykule, będę poruszał 9-10 grudnia we Wrocławiu, na moich autorskich warsztatach na bazie książki “Labirynty Scruma”. Przez 2 dni będziemy przepracowywać najczęstsze pułapki w Scrumie oraz omawiać sprawdzone sposoby, jak sobie z nimi radzić. Jeśli chcesz w praktyczny sposób pogłębić swoją wiedzę o Scrumie, zapisz się na warsztaty.

Źródło zdjęcia: Photo by Startup Stock Photos from Pexels

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *

*

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Ta strona używa Cookies, korzystając z niej wyrażasz zgodę na używanie ciasteczek zgodnie z ustawieniami przeglądarki. Nasza Polityka Prywatności
Akceptuję, bo lubię Was czytać.
x
X