Artykuły o Agile i nie tylko.
Największy w Polsce portal o zwinności

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

Reklama


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