Praktyki wspierające Planowanie Sprintu

Czy Twój Zespół ma problem z zaplanowaniem sobie pracy i okazuje się, że zadania “puchną” i nie jesteście w stanie ich wykonać w całości, tak jak planowaliście? Czy macie poczucie, że moglibyście planować lepiej, ale nie macie zbytnio pomysłów, jak to robić? W tym artykule chciałbym się podzielić kilkoma konkretnymi praktykami, jakie mi przychodzą do głowy jako odpowiedź w temacie lepszego planowania. Przynajmniej część z nich może być inspiracją dla Twojego zespołu. Znajdzie się też najważniejsza rada, jaką mogę dać w tym obszarze.

  • Brać mniej na sprint – to pierwsza i bardzo przewrotna praktyka prowadząca do lepszego planowania. Branie na siebie większej porcji pracy, niż są realistycznie w stanie wykonać, jest dla wielu zespołów źródłową przyczyną tego, że nie mogą dobrze zaplanować sobie pracy. Zespołowi, który ma problem z dostarczeniem planu, niekoniecznie proponowałbym, by lepiej planował, tylko by zaplanował mniejszy zakres. Duże obciążenie czasowe i duże zamieszanie, które się dzieje, gdy weźmiemy za dużo, mogą wpłynąć negatywnie na produktywność pracy pojedynczych osób i całego zespołu. Przeciążony zespół nie ma też czasu, by wyciągać wnioski z tego, co robi i jest pod taką presją, że nie myśli o tym, jak dobrze sobie zaplanować swoje działania i jak je robić mądrze. Zespół, który weźmie mniej pracy niż zwykle, powinien bez problemu mieć czas na to, by sobie tę pracę dobrze rozplanować. Jeśli weźmie za mało – skończy wszystko przed końcem sprintu i będzie mógł podjąć nowe, nieplanowane wcześniej zadania. Smutny, oddzielny wątek, to skąd pojawia się presja w zespole na branie większej ilości pracy niż to rozsądne – ale nie o tym ten artykuł.
  • Bardzo popularną przyczyną kiepskiego planowania sprintu jest rozpoczynanie tego planowania z kompletnie nieprzygotowanym Backlogiem Produktu. Zespół zamiast wykonywać faktyczne aktywności planistyczne musi dopiero odkrywać co w ogóle jest do zrobienia, wyceniać, dzielić elementy Backlogu Produktu na mniejsze elementy. Brakuje czasu i energii na planowanie sprintu, więc zespół zatrzymuje się na etapie ustalenia celu sprintu i jego zakresu, w ogóle nie rozmawiając o tym, jak to wszystko planują zrealizować. Receptą na taką sytuację będzie realizacja (większej ilości) sesji Refinementu Backlogu Produktu.
Doskonalenie Rejestru Produktu

Jak sprawdzić, czy sesje doskonalenia Rejestru Produktu powinny odbywać się częściej i przebiegać inaczej?

  • Poczas planowania dużą stratę zespoły ponoszą przy przełączaniu kontekstu. Unikajmy tego zjawiska podczas przebiegu aktywności planistycznych – moderator spotkania powinien szczególnie mocno zwracać uwagę na to, czy nie skaczemy po wątkach, nie rozgrzebujemy już zamkniętych tematów, nie mieszamy poziomów abstrakcji (np. jednoczesna dyskusja o tym, jak wartościowa jest planowana praca z perspektywy Product Backloga, jak jest czasochłonna i jak technicznie można to wykonać w naszym systemie). Unikanie przełączania kontekstu to też wytyczna, którą można wprowadzić do samego planu – niektóre zespoły już od początku sprintu przewidują, że równolegle będą realizować wszystkie możliwe zadania, jakie są do wykonania w sprincie, z góry zakładając, że część albo wszyscy członkowie zespołu będą mieli pod opieką kilka zadań. Tu kłania się limitowanie pracy w toku i możliwość zaplanowania sobie pracy razem całym zespołem nad częścią elementów Sprint Backlogu, by po ich zakończeniu przejść do kolejnych.
  • Gdy obserwuję niektóre planowania sprintów, widzę dużo pułapek w tym, że członkowie zespołu jednocześnie (naprzemiennie) generują zadania i układają je w jakiejś formie planu (cokolwiek “plan” znaczy dla danego zespołu – niektóre zespoły budują sobie harmonogram, niektóre planują jakimiś schematami, inne ustalają kluczowe daty dla danych prac). Niebezpieczne staje się to, że członkowie zespołu widząc kurczący się zapas pojemności sprintu, zaczynają modyfikować ocenę czasu potrzebnego do wykonania zadania, tak, by wszystko, co planują, się “zmieściło”, zamiast zrobić refleksję, że może właśnie odkrywają, że szykowali się do zaplanowania zbyt dużej ilości zadań. Praktyką, którą proponuję rozważyć, jest odseparowanie generowania wszystkich zadań, jakie zespół przewiduje, że są potrzebne do wykonania w sprincie, od ich rozmieszczenia na “planie”.
  • Planowanie pracy w sprincie jest wdzięcznym tematem do zastosowania wizualizacji. Zespoły robią sobie dużą krzywdę, próbując omówić plan pracy, ale mając go wyłącznie w głowach albo trzymając go tylko w narzędziu elektronicznym (które w ciemno można założyć, że będzie mało elastyczne i jednowymiarowe). Zachęcam zespoły do tego, by korzystały z flipchartu czy tablicy suchościeralnej do “rysowania” tego, o czym właśnie rozmawiają. Błyskawicznie wyłonią się wtedy praktyki wizualizacyjne specyficzne dla danego zespołu. Dyskusja będzie się toczyć wokół tematów spisanych i widocznych dla wszystkich uczestników. Jeśli dodatkowo dołączymy takie rozwiązania jak postity, kartki elektrostatyczne czy magnesy, bardzo ułatwimy sobie manipulację planem (przesuwanie zadań według kolejnych wersji planu, dokładanie nowych elementów). Na koniec taka wizualizacja może być sfotografowana albo wręcz zabrana do przestrzeni pracy zespołu i może stać się punktem odniesienia każdej kolejnej aktualizacji planu pracy, jaka się odbywać powinna na Codziennym Scrumie. Jeśli plan jest wizualny, bardzo łatwo do jego współtworzenia można zaprosić wszystkich członków zespołu, którzy równolegle mogą go usprawniać, dyskutować jego fragmenty i po prostu znacznie bardziej się zaangażować w spotkanie.
  • Jeśli już wizualizujemy nasz plan pracy, bardzo prosto można wzbogacić proces planowania o zawarcie w takiej wizualizacji dostępności poszczególnych członków zespołu. Zobrazowanie tego, kiedy kto ma urlopy oraz czy są jakieś ważne wydarzenia w trakcie sprintu, które rozproszą zespół (np. Release, jakieś duże spotkanie ogólnofirmowe), może pomóc w lepszej ocenie, ile w ogóle zadań zaplanować oraz jak je poukładać w sprincie.
  • Dla części zespołów przyczyną problemów z rozjazdem między planem a realizacją jest duża ilość nowej pracy, która pojawia się w sprincie. To mogą być nowe pilne drobne zadania zlecone w środku sprintu, które dociążają członków zespołu. To może być też efekt zdobycia nowej wiedzy i odkrycie przez zespół w trakcie sprintu, że potrzeba więcej pracy, niż się spodziewali, by osiągnąć cel sprintu. Niezależnie od tego, co jest źródłową przyczyną tego zjawiska, by je lepiej ocenić, warto zadbać o dyscyplinę w pokazywaniu tych nowych zadań. Jeśli wizualizujemy pracę, może warto zakodować (np. kolorem kartki) nowe, nieplanowane zadania. Jeśli korzystamy z JIRA, zwróćmy uwagę na raport ze sprintu, który wylicza wszystkie zadania dołożone do sprintu. Niezależnie od sposobu ich pokazania, warto w całym zespole głośno i jednoznacznie nazwać sobie problem pojawiających się nowych zadań i rozmawiać o tym, czy i jak się przed nim obronić w przyszłości.
  • Czasami praca w sprincie nie może być poukładana w dowolny sposób i pojawiają się naturalne zależności między zadaniami, niemożliwe do usunięcia. Jeśli takich zależności pojawia się w sprincie dużo, może się okazać, że opóźnienia już na samym początku sprintu mogą się okazać nie do nadrobienia w kolejnych dniach. W takich sytuacjach warto w ramach planowania jasno nazwać sobie to zjawisko i wyznaczyć sobie minideadline’y, które będą przez cały zespół monitorowane (i wszyscy członkowie zespołu będą sobie zdawać sprawę z wagi ich dotrzymania). Jasne nazwanie sobie takich terminów może być sposobem na przeciwstawienie się optymizmowi – jeśli na planowaniu całemu zespołowi wyszło, że np. na koniec przedostatniego dnia sprintu musi być gotowa wersja do ostatecznych testów, to faktycznie musimy się spiąć, nie możemy po cichu liczyć, że w trakcie realizacji kolejnych zadań “nadrobimy” opóźnienie (albo co gorsza – inny członek zespołu zrobi swoją część zadania szybciej niż przewidywał). Pytanie o dotrzymanie takich wyznaczonych “minideadline’ów” może być dodatkowym tematem dyskusji w trakcie Codziennego Scruma.
  • Jedną z praktyk, która prowadzi do lepszego planowania, jest zrobienie sesji podsumowania całości  przez zespół po zakończeniu budowy planu. Jeden z członków zespołu (albo cały zespół naprzemiennie) opowiada na głos, jaki jest plan realizacji prac, jakie są ustalenia poczynione przez zespół. Jeśli w toku planowania przegapiliśmy jakieś istotne aspekty albo powstało niezrozumienie – w czasie takiego podsumowania mamy świetny moment, by to wyłapać i jednak uwzględnić. Podsumowanie planu pracy można też połączyć z ostateczną rozmową z zespołu na temat tego, jak prognozują realizowalność Celu Sprintu. Być może przypomnienie sobie całego obrazu już na koniec Planowania zbuduje refleksję, że jednak próbujemy wziąć zbyt dużo pracy jak na możliwości zespołu.
  • Klasyczną praktyką związaną z planowaniem jest pozostawienie sobie bufora na nieprzewidziane prace albo na opóźnienie się prac planowanych. O stosowaniu takiego bufora wspomina na swoich szkoleniach również Jeff Sutherland, współtwórca Scruma. Zespół w trakcie planowania zostawia sobie z góry niezaplanowaną pojemność, wiedząc na bazie doświadczenia, że w trakcie prac ten zapas czasu będzie potrzebny. Warto ten zapas jawnie nazwać i sobie go śledzić, a sygnałem ostrzegawczym o tym, że mogą być problemy z realizacją planu sprintu jest moment, w którym kończy nam się ten bufor.
  • Inną radą, której warto też spróbować w zespołach mających problemy z planowaniem, jest zwiększenie dekompozycji zadań. Każdy zespół będzie mieć swoje własne zasady w tym, jak rozbijają zadania i do jak drobnego stopnia, jeśli jednak mamy problemy z realizacją zadań, które mają swoje źródła w opóźnianiu się zadań dużych, warto spróbować w kolejnych sprintach dzielić je na jeszcze mniejsze fragmenty. Małe zadania mogą pomóc monitorować postęp prac, być może osobne drobne zadania mogą być wykonane przez różne osoby. Sam fakt rozbijania zadań nie gwarantuje realizowalności planów, ale może pomóc wykryć, w jakiego typu tematach pojawiają się trudności albo opóźnienia – co może pomóc zespołowi wyciągać wnioski na przyszłość.
  • Niektórym zespołom, z którymi pracowałem, doradzałem większą ilość czasu na budowanie planu. Zespoły, które nie mają pomysłu na planowanie albo mają taką sesję zmoderowaną niedoskonale, budują sobie presję na to, by jak najszybciej skończyć to “nudne” planowanie i natychmiast rzucić się w wir “faktycznej” pracy. W takiej sytuacji do poprawy jest jakość przebiegu spotkania i skupienie się na tym, by czynności planistyczne miały realną wartość dla wszystkich uczestników spotkania. W krótkim terminie nie da się tego zrobić bez poświęcenia odpowiedniej ilości czasu – pamiętajmy, że chociażby Scrum Guide daje tutaj wytyczną, by planowanie trwało maksymalnie 8 godzin dla miesięcznego sprintu (i proporcjonalnie mniej dla krótszych – np. 2 godziny dla tygodniowego). Znam doświadczone zespoły, które są w stanie zaplanować sobie pracę na dwutygodniowy sprint w mniej niż pół godziny – ale jeśli macie powtarzający się problem z realizacją celów sprintów i jest podejrzenie, że wynika to z umiejętności planowania – to prawdopodobnie Planowanie Sprintu musi zająć więcej czasu i być lepiej zmoderowane.

W całym artykule wymieniłem kilkanaście praktyk wspomagających planowanie pracy w zespole scrumowym a i tak jest to zajawka tematu. W każdej z tych praktyk można znaleźć wiele szczegółowych wariacji ich stosowania, bez problemu dojdziecie też do tego, że nie wspomniałem o czymś, co sami stosujecie i Wam się sprawdza w Waszym zespole. I tu docieramy do najważniejszej rady w tym obszarze – skuteczność planowania i stosowane praktyki przez dany zespół przede wszystkim powinny podlegać ciągłej ewolucji poprzez Retrospektywę Sprintu. Zespół jest w stanie samodzielnie wpadać na najlepsze dla siebie metody, udoskonalać te istniejące i poprawiać to, w jaki sposób odbywa się planowanie. Ważne, by otwarcie mówić o niedoskonałościach dotychczasowych sposobów działania i wnikać w źródłowe przyczyny. Trzeba też nie bać się eksperymentów, nie zakładać z góry, że czegoś się nie da, albo u nas nie zadziała, tylko umówić się całym zespołem na próbowanie różnych podejść i wyciągania z nich to co najlepsze dla nas.

Źródło pierwszego zdjęcia: „First Battle of Bull Run” https://flic.kr/p/FhV8R1 Autor Jim Surkamp na licencji CC BY-NC 2.0

Komentarze do wpisu: “Praktyki wspierające Planowanie Sprintu

  1. Szanowny Panie autorze.

    Czytamy, że zespół „zostawia sobie z góry niezaplanowaną pojemność, wiedząc na bazie doświadczenia, że w trakcie prac ten zapas czasu będzie potrzebny”.

    Na pierwszy rzut oka wydaje się to być fajne, uskuteczniamy empiryczne podejście i nauczyliśmy się, że wyskakują nam jakieś rzeczy w trakcie sprint więc zostawmy sobie na nie jakiś bufor. Jednak kiedy przyjrzeć się temu dokładniej to jest to niezła patologia.

    1. Scrum Guide mówi jasno „Scope may be clarified and re-negotiated between the Product Owner and Development Team as more is learned.”. Czyli cokolwiek nieprzewidzianego to właśnie ta nauka która sprawia, że powinniśmy renegocjować scope!

    2. Czy jest jakieś źródło do tej klasycznej techniki o której uczy Jeff Sutherland?

    2. Znamy naszą prędkość (która nie spadła z sufitu – to są historyczne dane, które uwzględniają wszystkie dawne nieprzewidziane wydarzenia), znamy pojemność sprintu a jednak wprowadzamy dodatkowy bufor na rzeczy na które czas już został uwzględniony obliczając prędkość.

    3. Bufor też ma skończoną pojemność – skąd więc wiemy czy będzie on wystarczający. Przypomina mi się sytuacja w której PO poprosił zespół o wycenę, dla uproszczenia przeliczył ją na dni, dodał 25% (bo tyle na pewno wystarczy c’nie) i ogłosił na spotkani zarządu datę wypuszczenia aplikacji… zagrożenie jest takie same jak z tym buforem.

    • Cześć,

      > Szanowny Panie autorze.

      Nie musisz się zwracać do mnie aż tak formalnie, na portalu i w jego komentarzach piszemy do siebie bezpośrednio.

      ad.1 Nie mieszaj proszę renegocjacji zakresu w trakcie sprintu z zostawianiem sobie buforu na nieprzewidziane przypadki – te dwie praktyki są od siebie niezależne. Uwierz, że są zespoły, które bardzo świadomie decydują się na takie podejście (zostawienie buforu na bazie dotychczasowych doświadczeń w ich specyficznym kontekście) i nazywanie ich zachowania „niezłą patologią” to chyba zapędzenie się za daleko w opinii.

      ad. 2 Tak, źródłem są materiały ze szkolenia Jeffa „Certified Scrum Master”, w których brałem udział. Teraz sprawdziłem i nawet chyba niechcący na swojej stronie Jeff opublikował je w sposób odnajdowalny w Google, ale nie będę tego linkował. Zalinkuję Tobie opublikowany pattern scrumowy „Illegitimus Non Interruptus” https://sites.google.com/a/scrumplop.org/published-patterns/product-organization-pattern-language/illegitimus-non-interruptus, który jest dokładnie tym, na co się powołuje Sutherland.

      ad. drugie 2. Może to będzie dla Ciebie nowa informacja, ale nie wszystkie zespoły korzystają z prędkości do planowania (polecam tu klasyfikację Mike Cohna „velocity-driven” i „capacity-driven planning” https://www.mountaingoatsoftware.com/blog/why-i-prefer-capacity-driven-sprint-planning). Jeśli zespół tworzy sobie plan pracy na sprint i w trakcie tego tworzenia wyjdzie im, że pod koniec sprintu mają luzy, mogą wpaść na pomysł dotankowania do pełna (wzięcia tyle elementów Product Backloga, że jakakolwiek niespodziewana potrzeba wykonania pilnej nowej pracy rozwala im kompletnie sprint). Przestrzegam przed tym, proponując technikę świadomie ustawionego bufora. Jeśli sprint dobiega końca a bufor pozostaje niewypełniony – zawsze możemy w porozumieniu z PO dobrać nowe rzeczy do sprintu.

      ad. 3 Nie wiemy czy bufor będzie wystarczający, możemy tylko prognozować to na bazie poprzednich doświadczeń. Nie widzę żadnego związku między stosowaniem jawnego bufora a antyprzykładem przyjmowania jakichś samodzielnych założeń przez Product Ownera i składania na ich podstawie obietnicy bez pokrycia. W zasadzie to jest wręcz przeciwieństwo (jawnie z PO zakładamy bufor – PO sam sobie coś założył).

      I jeszcze raz powtórzę to, co zapisałem pod koniec artykułu – co zespół to praktyka, w różnych kontekstach będzie pasowało różne podejście. Jeśli u Ciebie coś działa albo nie – fajnie, nie jest moją intencją Cię przekonywać. Każdą z praktyk opisanych wyżej widziałem skutecznie funkcjonującą w konkretnych sytuacjach. I każda z tych praktyk pojawiała się w danym zespole na zasadzie ciągłego usprawniania się na kolejnych Retrospektywach.

      • Cześć, Dzięki za odpowiedź.

        Wyraziste stwierdzenia prowokują dyskusje. Jednak wciąż nie zgodzę się że są to różne rzeczy, dla mnie jest to obejście problemu z komunikacją, ciężko mi wymyślić przykład w którym mając dojrzałe osoby po obu stronach nadal potrzebujemy bufora zamiast renegocjować scope.

        Z tego co zrozumiałem z podlinkowanego wzorca o pozostawianiu, rozmiarze i zapełnianiu bufora decyduje głównie PO. Zgadzam się na pewno z wypisanym tam zagrożeniem: ” Low defect tolerance increases velocity in general, but exceeding the buffer typically generates at least a 50% reduction in velocity.” Super plus za linka.

        Jedno pytanie:

        „Jeśli sprint dobiega końca a bufor pozostaje niewypełniony – zawsze możemy w porozumieniu z PO dobrać nowe rzeczy do sprintu”. A co z naszym celem sprintu, który przecież już został wykonany? Czy nie zwiększamy ryzyka odwlekając inspekcję i adaptację ze względu na posiadanie bufora?

  2. Kuba, jeśli chodzi o timeboxy, nigdzie w Scrum Guidzie nie ma że są proporcjonalnie krótsze. Jest tam „usually shorter”, a w polskim tłumaczeniu „zwykle krótsze”. Oczywiście łatwiej jest przekonać management proporcjonalnością, ale formalnie nic nie stoi na przeszkodzie żeby mieć 8h planowania w krótszym sprincie. W rzeczywistości, „góra” marudzi nawet na 4h spotkań scrumowych w 2tyg sprincie.
    Pozdrawiam, dobry wpis, prawie wszystkie techniki już stosowałem z dużym powodzeniem 🙂


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