Rola Scrum Mastera to między innymi zadawanie takich pytań, aby Zespół Deweloperski poszukiwał w rezultacie usprawnień (ang. improvments).
Jakie pytania powinieneś, jako Scrum Master (SM) lub Lider, zadać zespołowi (i Product Ownerowi), aby zachęcić go do “myślenia” oraz udoskonalania swojego procesu?Na podstawie artykułu, dostępnego na stronach Age of Product, stworzyłem listę takich pytań.
Bardzo często jestem w różnych zespołach deweloperskich, które bardziej lub mniej wykorzystują framework Scruma. Okazje do bycia w zespole są bardzo różne – od obserwacji uszczegółowienia wymagań, poprzez rozwiązywanie konfliktów wewnątrz zespołu, aż po szukanie razem z drużyną rozwiązań problemów dotyczących na przykład niezrealizowania zoobowiązań.
Zawsze jak wchodzę do jakiegoś zespołu zastanawiam się, od czego zacząć z nimi pracę. Jak zachęcić ich do wypracowania rozwiązania problemu samodzielnie. Oczywiście, w niektórych przypadkach wskazane jest, aby zespołowi, używając jedną z techniki coachingowych, pokazać tzw. chińskie menu (czyli dostępne opcje rozwiązania problemu, z których to oni mają wybrać te potencjalnie właściwe i realizować je z użyciem eksperymentowania / cyklu PDCA. Jednak w większości wypadków moja rola sprowadza się do tego, aby właśnie pytaniami zachęcić ich do samodzielnego poszukiwania rozwiązania (albo uzmysłowienia sobie istniejącego problemu).
Przygotowałem poniżej listę pytań, których użycie może zachęcić zespół / POs do “myślenia”.
- Jak duży jest Backlog Produktu?
Backlog Produktu, który jest większy niż ten, który zespół może obsłużyć w trzech, może czterech Sprintach, jest z założenia niewłaściwy (mam na myśli tutaj te zadania, które są drobnoziarniste, przygotowane do planowania; PBL może się także składać z elementów średnio- oraz gruboziarnistych, na dłuższy horyzont (w postaci na przykład epików). Jeśli Rejestr Produktu przekracza ten próg, Właściciel Produktu może potrzebować wsparcia (zespołu, SMa, Agile Coacha).
- Jaki jest typowy wiek elementu Backlogu Produktu?
Element Rejestru Produktu, który nie był zmieniany od pięciu miesięcy, jest nieaktualny. Zaśmiecanie Backlogu Produktu pomysłami, przypomnieniami lub innymi elementami o niskiej wartości zwiększa chaos, prawdopodobnie utrudniając dostarczanie wartości biznesowej.
- Jaki jest średni czas realizacji (Lead Time), od dodania pomysłu do Backlogu Produktu do jego dostarczenia?
Jest to trudne pytanie, ponieważ większość zespołów i Product Ownerów (Managerów) tego po prostu nie wie. Ale jest to jedna z niewielu miar, które mogą dostarczyć informację, czy Agile / Scrum został zaadaptowany przez Twoją organizację.
- Czy Backlog Produktu zawiera zadania, których zespół nie zna?
Jeśli tak, przedmiotowe elementy Rejestru Produktu mogą nie być już wartościowe lub nieprawidłowo przebiega proces Refinementu.
- Jak często odbywa się udoskonalanie elementów Backlog Produktu?
To powinien być proces ciągły. Moja opinia jest taka, że chciałbym mieć przynajmniej raz w tygodniu sesję udoskonalania Backlogu Produktu z całym zespołem (za Scrum Guide – “…doskonalenie zazwyczaj zajmuje nie więcej niż 10% czasu Zespołu Deweloperskiego w Sprincie…”)
- Nad iloma elementami na raz pracuje zespół celem ich uszczegółowienia?
W idealnym przypadku zespół nie powinien pracować nad większą liczbą elementów (w definicji “elementy” mieszczą się m.in zadania rozwojowe, maitenance, błędy), niż może obsłużyć w ciągu następnych dwóch lub trzech Sprintów. W przeciwnym razie, ryzyko uszczegóławiania elementów, które w momencie trafienia do Sprint Backlogu będą już nieaktualne, staje się zbyt wysokie.
- Jak długo trwa udoskonalanie typowego elementu Rejestru Produktu?
Udoskonalanie nie powinno zająć więcej niż jeden do dwóch Sprintów. W przeciwnym razie właściciel produktu / interesariusze mogą potrzebować wsparcia w prawidłowym przygotowaniu pomysłów na wydarzenia dotyczące udoskonalania (Refinement / Grooming).
- Jak powstają elementy Backlogu Produktu? (Czy jest to wspólny wysiłek zespołowy z Product Ownerem, czy też Właściciel Produktu tworzy nowe elementy / zadania, a Zespół Deweloperski tylko je szacuje?)
Jest tendencja, że Właściciele Produktów stają się swego rodzaju „technicznymi autorami” elementów Backlogu Produktu, które są następnie szacowane przez zespół. Dobrą praktyką, a wręcz niezbędną czynnością, aby zachować rozumienie zadań z PB przez Zespół Deweloperski (co powinno przełożyć się na podniesienie efektywności i zadowolenia), jest tworzenie elementów Backlogu Produktu wspólnym wysiłkiem całego zespołu.
- Kiedy / gdzie omawiane są elementy Product Backlogu? (Tylko podczas sesji udoskonalania, czy też na Slacku lub na przykład poprzez komentarze do zadania?)
Komentowanie zadania w Confluence, Jira, Github czy wykorzystanie Slacka jest skuteczne. Jeżeli dzieje się to przed Planningiem [link], zanim zadanie “trafi” do Sprint Backlogu, jest efektywne i wskazane.
- Kto pisze kryteria akceptacji i w jakiej formie?
Powinien to być Właściciel Produktu we współpracy z Zespołem Deweloperskim, zgodnie z uzgodnioną definicją „Gotowe” (ang. Done), tworząc w ten sposób wspólne zrozumienie tego, co zespół musi zbudować.
- Jak jest oceniany prawdopodobny wysiłek / złożoność zadania?
Istnieje wiele praktyk dotyczących szacowania elementu pracy. Najważniejsze jest jednak, aby stworzyć wspólne zrozumienie między wszystkimi członkami zespołu, co powinno zostać wytworzone. Oszacowanie / ustalenie wielkości zadanie jest efektem ubocznym, a nie głównym celem.
- Jaka była prędkość zespołu w ostatnich trzech sprintach?
Zespół Scrumowy powinien znać swoją szybkość lub produktywność. W przeciwnym razie jak mógłby się poprawić, nie znając stanu AS IS?
- Ile User Stories (zadań) zazwyczaj nie kończy się w ramach Sprintu i z jakich powodów?
Kiedy Zespół Deweloperski regularnie pozostawia elementy Sprint Backlogu niedokończone, nie osiąga Celów Sprintu, powinno to być głównym jego zmartwieniem. Dodatkowe pytanie, jakie każdy SM powinien sobie zadać w tej sytuacji, to jak pokazać tę sytuację zespołowi? Jak uświadomić mu ten problem?
- Jaki jest poziom (złego) długu technicznego?
Jako Scrum Master chcesz wiedzieć wszystko o aktualnym poziomie długu technicznego, zależnościach od innych Zespołów Scrumowych i zależnościach od zewnętrznych dostawców. Te kwestie są bezpośrednio odpowiedzialne za efektywność Zespołu Scrumowego.
- Jakie są trzy główne wyzwania, przed którymi stoi dziś Zespół Scrumowy?
Ostatnie pytanie jest z założenia pytaniem otwartym, aby uzyskać kilka pomysłów na następną retrospektywę sprintu.
Podsumowanie
A jaka jest Twoja preferowana technika, aby jak najszybciej zapoznać się z nowym Zespołem Scrumowym? Gdzie zaczynasz? Podziel się swoim doświadczeniem w komentarzach.