Jakiś czas temu otrzymałam pytanie o moje sprawdzone sposoby na sprawny przebieg Refinementu (tzw. sesja doskonalenia Backlogu Produktu). Zespół jest duży, lubi rozmawiać i przeplatać dyskusje merytoryczne żartami. Znacie to z autopsji? Przyjemnie spędzony czas, ale mało przepracowanych zadań, do tego część z nich po łebkach. Wiele razy spotkałam się z takim problemem, dlatego postanowiłam zebrać swoje przemyślenia, wskazówki i sprawdzone techniki, pośród których być może znajdziecie coś dla siebie.
Szczera rozmowa z zespołem
Jestem zwolenniczką najprostszych rozwiązań, a do takich właśnie należy szczera rozmowa. Trudno mierzyć się z problemem nieefektywnych spotkań w pojedynkę, a zdarza się, że próbuje to zrobić np. Scrum Master, Product Owner albo lider, w ogóle nie dzieląc się wcześniej swoimi przemyśleniami z zespołem. Porozmawiajcie o tym, jak postrzegacie Refinement i dlaczego w aktualnej formule Wam się nie podoba, niezależnie od tego, jaką rolę pełnicie. Rozwleczone, nieefektywne spotkania uważam za jeden z większych paradoksów pracy w zespole – większość z nas męczą, frustrują, a jednocześnie konsekwentnie sprawiamy, że kolejne spotkania niewiele różnią się od poprzednich. Dlatego rozmowę uważam za pierwszy i niezbędny krok, jeśli chcemy zmienić aktualne status quo.
Zapewniam Was, że jeśli dostrzegacie podobny problem w Waszym zespole, nie jesteście jedyni. Wyciągnięcie tematu spod przysłowiowego dywanu, przedyskutowanie go i uzgodnienie wstępnych ustaleń, będzie ważnym pierwszym krokiem do zmiany.
Ustalenie ram dla tematu
Sporo dyskusji trwa długo, ponieważ można je poprowadzić w wiele kierunków, w zależności od doświadczeń, zainteresowań, wyobrażeń poszczególnych osób w zespole. Warto zadbać o nadanie ram każdemu z tematów, które będą poddane dyskusji, niezależnie od tego, na ile zadań/ historyjek zostaną następnie rozbite:
- Jaki jest podstawowy cel nowej funkcji/ ficzera, który będzie budował zespół, po co wprowadzamy zmianę, dlaczego zabieramy się za temat – innymi słowy, co właściwie chcemy osiągnąć? Tutaj najważniejszy głos będzie miał Product Owner zespołu
- Jakie zależności musimy wziąć pod uwagę? – aktualne systemy, funkcje, inne zespoły?
- Co z wymaganiami technologicznymi – co będzie dla nas kluczowe?
- Po czym sprawdzimy, że udało się osiągnąć cel?
Takie ramy naturalnie kanalizują temat dyskusji i zwiększają szanse na to, że te będą bardziej konkretne, z mniejszą ilością niewiadomych, wątpliwości, dygresji, czy rozbieżnych zdań, a tym samym po prostu krótsze.
Praca w parach
Refinement przebiega znacznie sprawniej, jeśli prace nad poszczególnymi zadaniami/ historyjkami toczą się równolegle. Jak to zrobić, aby jednocześnie zapewnić udział w ich tworzeniu/ weryfikacji wszystkim Deweloperom, skoro często nie wiadomo, kto będzie nimi zajmował w trakcie Sprintu?
- Ustalcie ramy dla dużego tematu, jw.
- Wspólnie zdefiniujcie zadania/ historyjki – nazwy wraz z celem dla każdej z nich
- Podzielnie się przepracowaniem poszczególnych zadań/ historyjek w parach, dobranych w możliwie sensowny wg Was sposób – np. senior z juniorem, webdeveloper w parze z innym deweloperem, pracujący nad tematami dotyczącymi frontu itp. Dajcie sobie na to określony czas – timebox – np. 15 min. Ważne: w tym czasie do dyspozycji wszystkich par powinien być Product Owner tak, aby rozwiać ewentualne wątpliwości, czy podjąć potrzebne decyzje
- Po określonym czasie – timeboxie, zróbcie review powstałych historyjek – każda z par prezentuje ich treść – Kryteria akceptacji i ew. taski techniczne, reszta z zespołu ma okazję zadać pytania, uzupełnić, dodać swoją perspektywę.
Uważam, że taka forma Refinementu jest warta wypróbowania szczególnie w przypadku doświadczonych zespołów, które długo ze sobą współpracują. O niuansach większości tematów można wtedy dyskutować w nieskończoność, przekonując się wzajemnie o wyższości rozwiązania X nad rozwiązaniem Y, tylko po co, skoro wiadomo, że mamy w zespole doświadczone osoby, które wiedzą, co robią. Praca w parach ułatwia utrzymanie koncentracji na konkretnym temacie i umożliwia wzięcie odpowiedzialności za niego, a wspólne review zapewnia jednocześnie uspójnienie wiedzy i uzupełnienie ewentualnych braków.
Co istotne – taka forma oszczędza naprawdę sporo czasu. Szczególnie, kiedy założycie, że deweloperzy od razu wpisują całą treść zadań do Product Backloga, z którego korzystacie.
Timeboxy na tematy/ historyjki
Technika stara, jak świat, dla niektórych kontrowersyjna, ale uważam, że w wielu przypadkach skuteczna. Zgodnie z prawem Parkinsona praca zabiera nam tyle czasu, ile na nią założymy. Ile zadań/ historyjek udaje nam się omówić w ciągu godzinnego Refinementu? 1, 2, 5? A co, gdybyśmy założyli, że dajemy sobie 10 min na jedno zadanie, zakładając, że to, co udam nam się wypracować będzie wystarczająco dobre. Może 10 min to za mało, może warto dać sobie 15, może warto uzależnić ilość czasu od stopnia skomplikowania tematu. Eksperymentujcie, próbujcie i wyciągajcie wnioski.
Rotacyjne prowadzenie spotkania przez kolejne osoby z zespołu
To metoda, którą wypróbowaliśmy w 2 zespołach, z którymi miałam okazję współpracować. Za każdym razem zadziałała, bo:
- Dobrze mieć osobę, która bardziej niż inni skupi się na formie spotkania i naprawdę nie musi to być Scrum Master, bo przecież z założenia on ma działać tak, aby z czasem okazać się zbędnym, prawda?
- Biorąc pod uwagę samoorganizację – dobrze, aby każdy w zespole potrafił poprowadzić dowolne spotkanie, a to umiejętność, jak każda inna, której trzeba się po prostu nauczyć, najlepiej przez praktykę,
- Kiedy raz poczujesz na sobie odpowiedzialność za prowadzenie spotkania, następnym razem 3 razy zastanowisz się, zanim ulegniesz pokusie, żeby wtrącić rozpraszający żart w merytorycznej dyskusji. Serio.
I nie mam tutaj na myśli podejścia w stylu „jakoś to będzie”. Refinement, jeśli ma być efektywnym spotkaniem, jak każde inne, powinno być przemyślane przez osobę, która będzie je prowadzić. Przebieg spotkania zależy od specyfiki tematów, stopnia skomplikowania, ew. zaangażowania osób spoza zespołu itd. Warto aby Scrum Master, czy Agile Coach wsparł inne osoby w zespole w tym, aby się do tego spotkania przygotować. Początkowo będzie to wymagało więcej wysiłku, żeby z czasem nabrać wprawy.
Samoorganizacja w pilnowaniu tego, aby trzymać się tematu
Ideałem są spotkania, podczas których każdy z uczestników czuje się odpowiedzialny za to, aby trzymać się merytoryki i omawiać tematy na takim poziomie szczegółowości, jaki jest niezbędny. Jakiś czas temu Jacek podzieli się z Wami swoją sprawdzoną techniką, jak to osiągnąć (jak sprawić żeby zespół podczas spotkań sam ucinal nieistotne dyskusje).
Wizualizacja rozwiązania
Dopóki nie widzimy rozwiązania czarno na białym, choćby w formie schematycznego grafu, narażamy się na minimum trzy ryzyka:
- Mówimy o innych rozwiązaniach, mimo, że cały czas wydaje nam się że mówimy o tym samym
- Wydaje nam się, że wcale się nie zgadzamy, pomimo tego, że tak naprawdę od dłuższego czasu mówimy dokładnie o tym samym
- Zataczamy koła, dyskutując w kółko o tym samym, podczas gdy umyka nam ważna kwestia, której nie wzięliśmy wcześniej pod uwagę
Gros z moich leanowych fascynacji bierze się ze skuteczności najprostszych metod, jak wizualizacja właśnie. Podczas Waszego Refinementu toczy się zaciekła dyskusja na temat tego, jak zaimplementować nowe rozwiązanie w istniejący system? Podajcie pisak osobie, która zabiera głos. To będzie moment zwrotny dla dyskusji, zapewniam. Jedno z moich ciekawszych doświadczeń z rysowaniem podczas spotkań dotyczy tego, że kiedy już zespół zacznie szkicować/ rysować podczas Refinementu, pisak staje się niezbędny podczas niemal każdego spotkania.
Mniejsze Refinementy w tzw. tymczasowych zespołach
A co, jeśli uznamy, że cały zespół wcale nie musi brać udziału w każdym Refinemencie? I co, jeśli okaże się, że takie rozwiązanie działa? Zaproponowałabym kontynuację. Dwa inne zespoły, które wspierałam, uznały, że chciałyby podejść bardziej eksperymentalnie do swoich Refinementów.
W jednym z nich za przepracowanie i realizację kilku dużych tematów były odpowiedzialne poszczególne osoby z zespołu. Ich odpowiedzialnością było to, aby zorganizować spotkanie z Product Ownerem i zebrać odpowiednią grupę, przepracować tematy, zrealizować, a następnie pokazać podczas Review. W drugim zespole powstało natomiast coś na kształt tymczasowych microzespołów, które były odpowiedzialne za realizację poszczególnych tematów.
W obu przypadkach zespół był bardzo zadowolony z jakości spotkań i dyskusji podczas Refinementów, które odbywały się w uszczuplonym gronie. Jednocześnie, żaden z nich nie zdecydował się w dłuższej perspektywie na podział zespołu na mniejsze, uznając, że to spowodowałoby powstanie silosów kompetencyjnych.
Agenda dostępna przed spotkaniem
Informacja od Product Ownera o tym, czego będzie dotyczyło spotkanie pozwala zespołowi przygotować się, przemyśleć rozwiązania, czasem zrobić wstępne rozpoznanie. Mała rzecz, a sprawa, że zespół jest zaangażowany w temat już przed spotkaniem, a dodatkowo mobilizuje samego Product Ownera do tego, żeby wcześniej przygotować się, przemyśleć, jakie zadania chce przepracować z zespołem, w razie potrzeby porozmawiać z interesariuszami.
—
Dodatkowo, zwróciłabym uwagę na to, czy:
Zespół ma ustalone standardy tworzenia zadań (Definicję gotowości, DoR) i realizacji (Definicję ukończenia, DoD)
Często Refinement przeciąga się w nieskończoność przez dyskusje spowodowane brakiem ustaleń dotyczących tego:
- Co rozumiemy przez zadanie, które jest gotowe do wzięcia na Sprint (ang. Definition of Ready, DoR). Przykładowa Definicja gotowości:
- Zadanie zawiera:
- Cel (wiadomo, jaką korzyść chcemy osiągnąć)
- Kryteria akceptacji (wiemy, jak sprawdzić, czy zrealizowaliśmy cel)
- Wizualizację przygotowaną przez specjalistę UX i grafikę, jeśli zadanie dotyczy zmian na froncie
- Jak wyglądają standardy pracy dla każdego zadania, które realizujemy (ang. Definition of Done, DoD) – np. każde zadanie musi przejść code review i testy regresyjne, a uznajemy je za ukończone po wdrożeniu na produkcję.
Posłuchaj też 47 odcinka podcastu Porządny Agile, którego tematem jest Definition of Ready.
—
Czego jeszcze warto Waszym zdaniem spróbować?