Planowanie pracy w środowisku zwinnym rodzi wiele pytań. Rozmawiamy o Planowaniu Sprintu, analizujemy to wydarzenie z różnych perspektyw a na koniec odcinka dzielimy się praktycznymi poradami, które można wykorzystać od zaraz, podczas najbliższego planowania.
Jak porządnie zaplanować Sprint w Scrumie? Który ze sposobów na planowanie Sprintu wybrać i jakie mamy dla Ciebie porady związane właśnie z wydarzeniem scrumowym.
Oprócz wyżej wymienionych zagadnień związanych z planowaniem Sprintu, w artykule tym poruszymy też takie kwestie jak:
- jak dokładny powinien być Plan Sprintu?
- czy zakres Sprintu jest stały czy zmienny?
- czy Cel Sprintu determinuje zakres prac czy jest wręcz odwrotnie?
- jak zarządzać dostarczaną wartością w trakcie pracy?
Czym jest Planowanie Sprintu?
Najprościej mówiąc Planowanie Sprintu, jest wydarzeniem, podczas którego ustalamy pracę na nadchodzący Sprint. Planowanie można podzielić na dwie części. Pierwsza część odpowiada nam na pytanie: co będziemy realizować?, natomiast druga część na pytanie: jak tę konkretną pracę będziemy wykonywać jako zespół?
Istotne jest tu to, że to Zespół Deweloperski decyduje, ile faktycznie pracy jest w stanie wykonać, opierając się na danych historycznych.
To rozróżnienie na dwa etapy ma ciekawe korzenie historyczne. Na szkoleniu Certified ScrumMaster w 2009 roku uczono nas, że Planowanie Sprintu składa się z dwóch osobnych, wyraźnie odróżnialnych części – ustalenie zakresu Sprintu i ustalenie planu pracy w Sprincie. I to były jakby dwie wyraźne, oddzielne czynności. Jedne z kolejnych aktualizacji Scruma trochę zatarły to rozróżnienie, a te obie rzeczy (Plan pracy i jej zakres) dzieją się w miarę równolegle lub naprzemiennie i nie są wyraźnie odseparowane.
W ramach Planowania Sprintu powstaje Cel Sprintu, o którym rozmawialiśmy w 7. odcinku naszego podcastu i zachęcamy Cię do jego przesłuchania.
Zarówno Planowanie, jak i Cel Sprintu, dążą do tego, aby na końcu powstał Przyrost Sprintu, będący efektem pracy całego Zespołu Deweloperskiego.
Różne zespoły planują na różne sposoby i nie ma jednoznacznie najlepszego podejścia. Nie w każdym zespole każda metoda zadziała, a bywa też tak, że są konkretne konteksty funkcjonowania zespołu, od których skuteczność tych metod może zależeć.
Przedstawimy to na przykładach i trochę przez pokazanie pewnych kontrastów, jakie w zespołach mogą funkcjonować.
Pierwszym spektrum jest kontrast: przygotowanie na Planowaniu i realizowanie bardzo dokładnego planu pracy, jako przeciwieństwo sformułowania po prostu celu i realizowania planu trochę ad hoc i wyłaniania się go trochę w trakcie Sprintu.
Z naszych doświadczeń wynika, że im bardziej Zespół rozumie produkt i im lepiej zna swoje możliwości, tym bardziej jest on w stanie przygotować bardzo konkretny Plan. Czyli wiemy dokładnie, jakie zadania wykonamy, kto wykona te zadania i potrafimy mniej więcej osadzić to w czasie. Im krótszy Sprint, tym ta precyzja jest większa.
Dzięki temu powstaje Plan, który możemy sobie prześledzić dzień po dniu, osoba po osobie i rysuje on nam krajobraz na najbliższe dni.
Przeciwieństwem tego jest sytuacja, w której Zespół właśnie wykonuje jakieś bardzo złożone przedsięwzięcie, być może bardzo eksperymentalne, którego nikt jeszcze przed nimi nie zrobił i tak naprawdę bardziej jest to projekt badawczy, a Zespół próbuje wpaść na rozwiązanie. Stąd też na etapie rozpoczynania kolejnej iteracji prac, Zespół nie ma zielonego pojęcia, jak długo zajmie im przygotowanie tego rozwiązania czy produktu, którego jeszcze nigdy nikt nie wymyślił.
Dlatego tu bardziej będzie on operować w świecie celów, jakie ma ambicję osiągnąć i być może pomysłów na pierwsze działania albo jakiegoś szkicu czy scenariusza Planu. Jednak tak naprawdę ten Plan nie przeżywa pierwszego kontaktu z rzeczywistością, zwykle już pierwszego, drugiego dnia widać, że się rozsypuje, że jednak są jakieś negatywne sytuacje, coś się przedłuża, coś jest niemożliwe, a z kolei coś innego okazuje się zupełnie szybkie do zrealizowania. Potem okazuje się, że dłużej go tworzyliśmy, niż pracowaliśmy zgodnie z nim.
Można to zaobserwować zwykle w zespołach rozwiązujących jakieś problemy biznesowe. Tam planowanie zwykle wygląda tak, że znamy cel, plus na takim metapoziomie wiemy, że podzielimy się na grupy, zrobimy jakieś rozpoznanie, ktoś zdobędzie jakieś informacje. Potem za dwa dni o 14 grupa się spotyka i synchronizuje, wiemy coś więcej, robimy kolejne kroki. Czyli to bardziej taki schemat jak będziemy pracować, natomiast dokładnie to, co będzie tym naszym materiałem, który będziemy wytwarzać, jest niemożliwy do dokładnego zdefiniowania.
Takie podejście wcale nie stoi w sprzeczności ze Scrumem, bo pamiętajmy, że mamy do dyspozycji codziennego Scruma, żeby sobie taki bardzo precyzyjny poziom codziennie ustalać. Natomiast ten schemat, który stworzyliśmy, odpowiadał na kilka podstawowych tematów typu: ile mamy dni na załatwienie jakichś danych czy zrobienie jakiegoś eksperymentu, kiedy ponownie przeplanujemy te rzeczy. Zatem na takim wysokim poziomie ogólności schemat czy szkic pracy w Sprincie, może być uszczegóławiany z dnia na dzień, na kolejnych codziennych Scrumach.
Nic też nie stoi też na przeszkodzie, żeby spróbować różnych stylów i zobaczyć czy czasami nie jesteśmy zespołem, który na siłę planuje bardzo szczegółowo, mimo że nasza domena na to nie pozwala.
Warto tu pamiętać, że w którym obszarze byśmy się nie znajdowali, dokładnego planu czy takiego bardziej eksperymentowania, nadal mamy najlepszy plan, jaki jesteśmy w stanie przygotować. Mówimy o tym, żebyście nie wpadli w taką pułapkę pod tytułem „tak niewiele wiemy, że w sumie nic nie jesteśmy w stanie zaplanować”.
Zawsze jakiś Plan jesteśmy w stanie przygotować, no i tylko tutaj będziemy mówić o tym, jak dokładny on będzie, co planujemy wykonać.
Kolejne kontrastujące sytuacje, to gdy planujemy znane rozwiązanie lub mamy stały zakres prac na etapie planowania, w przeciwieństwie do planowania eksperymentów, czyli podejścia do Sprintu jako sposobu na realizację różnych wersji i dojścia do tego, jak to zrobić w środku Sprintu, gdyż podczas Planowania nie wiadomo, które z możliwych rozwiązań się sprawdzi.
W tej pierwszej sytuacji łatwo wpaść w taką pułapkę, że tak bardzo jesteśmy wpatrzeni w tę ścieżkę, którą już sobie z góry wymyśliliśmy, że w ogóle nie dostrzegamy, że są też inne ścieżki. Dlatego zespoły mogą minimalnie rozszerzać sobie tę swoją perspektywę i zastanowić się, czy są jakieś lepsze rozwiązania niż takie, które automatycznie nam przychodzą do głowy. Być może otworzy się przed nami opcja, że najlepszym z rozwiązań jest nie robić nic i należy odesłać ten problem do zupełnie innego zespołu. Stąd warto być otwartym na to, że tych opcji jest więcej i fajnie, jeśli Product Owner oraz Scrum Master zachęcają Zespół, żeby sobie tę perspektywę rozszerzać.
Bardzo często to czy Zespoły mają po prostu realizować to, co zostało powiedziane czy mają przestrzeń do eksperymentowania, jest osadzone w kulturze organizacyjnej. Są firmy, które traktują Zespoły Deweloperskie, jako takie zespoły, które po prostu zrealizują to, co im powiemy, a są firmy, które traktują te zespoły jako takich eksploratorów, odkrywców i widzą w tych zespołach coś więcej. Oczywiście całym sercem jesteśmy bliżej tej drugiej opcji.
Jak nałożymy na to taki aspekt transformacyjny, to też w każdej firmie, która jest eksperymentująca, na początku musi być ten pierwszy najbardziej odważny, który zachęci pozostałych do przetestowania innej z możliwych opcji.
Kolejne z możliwych spektrów w kwestii Planowania i kolejny kontrast, jaki tu mamy jest związane z tym od czego, zaczynamy Planowanie Sprintu.
Jednym z mechanizmów jest rozpoczynanie od Celu Sprintu i pod ten cel dobierany jest zakres pracy i rozwiązanie. Z kolei odwrotną sytuacją jest, gdy najpierw znane są elementy zakresu i z nich potem definiowany jest jakiś Cel Sprintu.
Mieliśmy okazję pracować zarówno z zespołami, które zaczynały od Celu, jak i z tymi, które startowały od zakresu. I tutaj oboje zgadzamy się, że lepiej jest jednak rozpocząć od Celu Sprintu.
Pierwszym powodem jest to, że zaczniemy od odpowiedzenia sobie na pytanie “dlaczego w ogóle powinnyśmy poświęcić nadchodzący Sprint na konkretną pracę?”. Chcemy zrozumieć, co ma być efektem tej pracy. Drugi powód to to, że jasno określony Cel Sprintu faktycznie sprawia, że Zespół Deweloperski zaczyna myśleć trochę bardziej o sobie jako o zespole i dąży się, żeby zrealizować cel całego zespołu, a nie pojedyncze zadania, które mamy do siebie przypisane. Natomiast trzeci powód jest taki, że przygotowany Cel Sprintu na początku Planowania zwykle oznacza też, że Product Owner, czy właściciel produktu, odrobił jakąś tam lekcję w głowie i wie, co powinno być biznesowo zrealizowane w kolejnym etapie. Pozwala to założyć, że za produktem stoi jakiś większy Plan i nie działamy w zależności od tego, jak tam zawieje wiatr. Niekoniecznie musi być precyzyjnie określone, co po kolei dostarczymy, ale jakie efekty chcemy uzyskać i jaką ścieżką mamy podążać.
Z kolei podejście, w którym rozpoczynamy od zakresu Backlogu lepiej się sprawdza w zespołach z większym stażem lub których produkt jest trochę bardziej dojrzały, przez co opieka nad nim i jego rozwój nie polega na wdrażaniu nowych dużych funkcji, tylko na dodawaniu drobnych usprawnień i wykonywania małych prac z pogranicza utrzymania produktu. Tam tak naprawdę zakres prac może być bardzo różnorodny, ale wiele z tych rzeczy jest np. dosyć pilna albo robi dużą różnicę małym kosztem – stąd sens może być w tym, żeby tworzyć elementy zakresu i zobaczyć, czy czasami one nie tworzą jakiegoś większego celu. To jednak nie zmienia faktu, że warto myśleć perspektywą przyrostowej pracy – czyli każdy Sprint doprowadza do Przyrostu, a Cel Sprintu pozwala go zdefiniować.
Kolejnym podejściem w temacie szerokiego spektrum Planowania jest podejście związane z odpowiedzialnościami. Tu też mamy taki kontrast, w którym albo potrafimy imiennie wskazać, kto będzie wykonywał konkretne zadania, albo wiemy jaka praca ma być wykonana, ale podczas Planowania nie wiemy jeszcze kto,za co będzie odpowiedzialny.
Takie podejście, w którym nie ustalamy odpowiedzialności, może się sprawdzić jeśli w zespole jesteśmy w stanie w miarę płynnie wymieniać się zadaniami bez dużej starty na jakości ich wykonania czy czasu ich wykonania. Pomaga tu też bardzo drobne podzielenie zadań, a także dojrzałość zespołu i odpowiedzialność jego członków. Tutaj każdy jest takim liderem lub inicjatorem tego, żeby Plan zrealizować. Poczucie obowiązku jest tu niezbędne, aby nie czekać, aż ktoś przydzieli mi zadanie, tylko samemu realizować kolejne lub pomagać innym członkom zespołu.
Ostatnim aspektem, jaki chcemy poruszyć, jest sposób płynności dostarczania Przyrostu produktu. Tu też mamy dwie kontrastujące ze sobą opcje. W pierwszej mamy Sprint, gdzie dopiero w ostatnim jego dniu pojawia się Przyrost. Na wykresie (nazwaliśmy go “klifowym”) widoczna byłaby bardzo długa pozioma linia, pokazująca, że nic nie zrobiliśmy, a następnie nagły jej skok mówiący o tym, że wszystko co było do zrobienia, zostało zrobione. W drugim podejściu mamy bardzo płynne dostarczanie wartości, a wykres zbliża się do linii trendu pokazującej jak ten wykres powinien wyglądać w praktyce.
Jako zespół warto zadać sobie pytanie: „Jak to dostarczenie w środku Sprintu będzie wyglądać?”. Są korzyści dostarczania płynnego, są też sytuacje, w których relatywnie ciężko jest uzyskać – zwłaszcza w bardzo krótkim Sprincie – dodatkowo jeszcze płynność. Z kolei jeśli patrzymy na podejście “klifowe” z perspektywy biznesowej czy Przyrostu to często dzieje się tak, że np. analityk ma zalew pracy pierwszych dni Sprintu, tester nie ma nic do roboty, po czym na koniec Sprintu tester nie wie, w co ręce włożyć, a analityk szuka sobie zajęcia. Dlatego być może warto uwzględniać te specjalizacje w zespole na etapie planowania i np. rozsunąć to obciążenie konkretnych osób oraz zastanowić się, czy to dostarczanie nie może być bardziej płynne.
Jak porządnie zaplanować Sprint – wskazówki
Podzielimy się z Tobą 5 wskazówkami, które mogą pomóc w skutecznym Planowaniu Sprintu.
1. Zadbajcie o dobry Backlog Produktu
Dzięki temu będzie większe zrozumienie w zespole, co jest do zrobienia, na czym polegają zadania i czas przeznaczony na Planowanie będzie faktycznym planowaniem, a nie samym odpowiadaniem na pytania i wyjaśnienia. Stworzony Plan Sprintu bez porządnie przygotowanego Backlogu może się wysypać już pierwszego dnia, bo okaże się, że np. źle się zrozumieliśmy, zadania są zbyt duże albo wpadliśmy w pułapkę założeń. Wystarczy, jak będziemy mieć porządnie przygotowany Backlog na przynajmniej 1 Sprint do przodu, a zadania będą wystarczająco małe, dobrze opisane, z jasnym celem biznesowym i oszacowane.
Jeśli w Twoim zespole planowanie zajmuje wiele godzin, np. pół dnia lub nawet więcej, to warto się zastanowić, czy nie powinniście zrobić krok wstecz i przygotować porządny Backlog Produktu, a dopiero potem zabrać się za Planowanie. Możecie ustalić sobie Definition of ready, czyli standard przygotowania zadań, który uważamy za wystarczający do rozpoczęcia planowania. Warto sobie to wspólnie określić, być może nawet zrobić jakąś listę kontrolną – punkty, które każdy element Backlogu Produktu musi spełnić, żebyśmy w ogóle mogli je uwzględniać w planowaniu.
2. Uwzględnijcie dostępność członków zespołu
Z praktyki wiemy, że często jakieś elementy z Planu Sprintu nie zostały zrealizowane, bo okazało się, że ktoś miał urlop, ktoś inny się rozchorował, a ktoś prowadził rekrutację. Dlatego uwzględnijcie to podczas Planowania i sprawdzajcie w kalendarzu dostępność poszczególnych osób. Oczywiście zdarzeń losowych nie jesteśmy w stanie przewidzieć, ale i o nich warto pamiętać i wziąć pewien bufor czasowy.
3. Bazujcie na historycznych wynikach zespołu
Chodzi tu o to, aby co jakiś czas dokonywać refleksji na temat ilości wykonanej pracy w jednostce czasu i uwzględnić tę informację podczas sesji Planowania. Przykładowo, jeżeli mówimy o zespołach, które wykorzystują np. Story Pointy, jako sposób na określenie prędkości, no to, jeżeli przez trzy ostatnie Sprinty nasza prędkość oscylowała w granicach 30, to trudno zakładać, że w kolejnym Sprincie osiągnie 50 czy 60. Oczywiście, jeśli nie korzystacie ze Story Pointów i oceniacie pracę np. w godzinach, to i tak warto poszukać jakiejś jednostki wartości, którą dostarczacie.
To też uchroni Was przed takim antywzorcem, w którym co Sprint Planujemy podwojenie naszych możliwości dostarczania, a w rzeczywistości za każdym razem realizujemy tylko połowę z planu. Teoretycznie może nie ma nic w tym złego, tylko problem się zaczyna wtedy, jeśli dużą część naszej energii poświęcamy zaplanowanie tych niezrealizowanych zadań, a z kolei w czasie Sprintu, obniżamy jakość, aby jak najwięcej zrobić. Dlatego warto patrzeć na te dane historyczne i podejść bardziej realistycznie do Planowania, bo przeciążenie pracą wcale nie sprawi, że więcej zrobimy.
Ktoś kiedyś policzył ile razy w Scrum Guide, występuje słowo Velocity, a ile Cel Sprintu. Wynik (Velocity chyba tylko 1 raz, zaś Cel kilkanaście razy) jasno pokazuje, że cały Scrum zorientowany jest raczej na rezultat, a nie na prędkość pracy. Prędkość wykonywania zadań to jedno, natomiast ważniejsze jest to drugie, to co dostarczamy tą prędkością, czyli wartość i jakość tego, co dostarczamy. I właśnie na tym drugim powinniśmy się skupić przede wszystkim: co chcemy osiągnąć, jakich efektów się spodziewamy po realizacji Celu Sprintu. Dlatego też Cel Sprintu powinien się pojawić na samym początku Planowania.
4. Zaczynajcie od Celu Sprintu
Zamiast skupiać się na tym, ile jakiś tam umownych punktów dowieziemy lub ile godzin wyrobimy, powinniśmy raczej sfokusować się na wartości biznesowej, jaką dostarczymy. Niestety Zespoły czasem same pozwalają wkręcić się w to liczenie jakichś punktów, zamiast skupić się na faktycznie istotnych rzeczach. I tu jest zadanie dla Product Ownera, Scrum Mastera i wszystkich Interesariuszy, aby przypominać o wartości biznesowej i kolejnych o Celach.
5. Wizualizualizujcie Plan Sprintu
Mamy tu na myśli próbę przedstawienia powstałego Planu w postaci czy to jakiegoś kalendarza, na który sobie naniesiemy konkretne zadania, które chcemy wykonywać czy to w postaci jakiegoś diagramu, szkicu lub jakiejś osi. Forma tej wizualizacji jest drugorzędna, natomiast dobrze zwizualizowany Plan na bardzo wczesnym etapie upewnia nas, że pewne rzeczy rozumiemy tak samo.
Ponadto jeśli wspólnie, jako zespół, budujemy taki Plan pracy, to jest dużo większa szansa, że wszyscy się zaangażują, a planowanie przebiegnie dużo szybciej, właśnie dzięki zrównolegleniu pracy.
Te 5 porad może wydawać się oczywistościami, jednak z doświadczenia wiemy, że nawet oczywiste rzeczy warto od czasu do czasu powtórzyć lub głośno nazwać, gdyż w toku codziennej pracy po prostu o nich zapominamy.
Jesteśmy ciekawi Twoich doświadczeń związanych z Planowaniem Sprintu. Czy może masz jakieś dobre praktyki lub pułapki z Twojego własnego podwórka? Podziel się nimi w komentarzu.
Obejrzyj nasze webinary!
Zobacz nasze materiały premium:
- Co to jest agile? - Najnowszy webinar już w sprzedaży! 🥳
- Dekompozycja elementów Backlogu Produktu
Dodatkowe materiały
Sprawdź nasz webinar o dzieleniu elementów Backlogu Produktu na mniejsze elementy.
TRANSKRYPCJA
Kuba: W dzisiejszym odcinku porozmawiamy o Planowaniu Sprintu. Zdefiniujemy, na czym polega porządne Planowanie Sprintu, porozmawiamy o tym, jakie są różne opcje na możliwe sposoby Planowania Sprintu i cały odcinek zakończymy naszą subiektywną listą pięciu porad praktycznych na temat tego, jak może wyglądać Planowanie Sprintu w Scrumie. Jacku, czym jest Planowanie Sprintu?
Jacek: W największym uproszczeniu zdefiniowałbym Planowanie Sprintu jako wydarzenie, podczas którego planujemy prace na nadchodzący Sprint. W dużym uproszczeniu podzieliłbym to wydarzenie na dwie części. Pierwsza część odpowiada nam na pytanie, co będziemy realizować, natomiast druga część odpowiada na pytanie, jak tą konkretną pracę będziemy wykonywać jako zespół. To, na co zwróciłbym uwagę podczas planowania, to fakt, że to Zespół Deweloperski decyduje, ile faktycznie pracy jest w stanie wykonać – i opiera się na danych historycznych.
Kuba: To ma ciekawe korzenie historyczne – to rozróżnienie na dwa etapy, bo jak uczyłem się Scruma na szkoleniu Certified ScrumMaster w 2009 roku, to wersja, którą ja wtedy poznawałem, to jest taka, że Planowanie Sprintu składa się z dwóch osobnych, wyraźnie odróżnialnych części – właśnie ustalenie zakresu Sprintu i ustalenie planu pracy w Sprincie. I to były, jakby, dwie wyraźne, oddzielne czynności. Jedne z kolejnych aktualizacji Scruma trochę zatarły to odróżnienie wyraźne, że faktycznie planowanie to są obie rzeczy w miarę równolegle, czy naprzemiennie, a nie wyraźnie odseparowane – plan pracy od zakresu pracy. Możemy o tym jeszcze rozmawiać, dlaczego tak wyszło.
Jacek: Dodałbym do tej definicji jeszcze tylko fakt, że powstaje Cel Sprintu. Celu Sprintu nie będziemy dzisiaj pogłębiać, ponieważ rozmawialiśmy o nim w odcinku 007, który załączymy do notatek, natomiast z perspektywy planowania jest to ważna informacja, że taki Cel Sprintu dokładnie podczas tego wydarzenia powstaje.
Kuba: I ważna definicyjna kwestia to też to, że Planowanie Sprintu – czy ten Cel Sprintu – dąży do tego, żeby powstał na końcu Sprintu Przyrost. Czyli planujemy uzyskanie Przyrostu – to nie jest tylko planowanie bycia zajętym, to jest planowanie w celu osiągnięcia Przyrostu będącego efektem pracy całego Zespołu Deweloperskiego. W kolejnej części odcinka zanurkujemy głębiej w temat różnych opcji na planowanie – nazwaliśmy to spektrum opcji Planowania, ponieważ przygotowując się, wyliczyliśmy co najmniej 5 wymiarów, różnego rodzaju typów czy wariantów czy różnego rodzaju akcentów, jakie mogą przybierać Planowania w różnych zespołach, w zależności od różnych rzeczy. I będziemy o nich, tak właśnie trochę przez przykłady i trochę przez pokazanie pewnych kontrastów opowiadać, bo tak… podstawowa myśl, z jaką wychodzimy, i jaka jest do przekazania w ramach tego odcinka, to też to, że różne zespoły planują na różne sposoby i nie ma takiego jednoznacznego sformułowania, że jakiś sposób jest lepszy, jakiś jest gorszy, ten jest efektywny, ten jest nieefektywny. W różnych zespołach różne metody planowania będą działały. I też bywa, że są konkretne powody czy też konkretne konteksty funkcjonowania zespołu, od których te metody planowania mogą zależeć, czy może też zależeć ich skuteczność. Pierwsze ze spektrum, o którym myślimy, to taki kontrast: realizowanie (czy przygotowywanie) bardzo dokładnego planu pracy na Planowaniu – jako pewne przeciwieństwo sformułowania bardziej celu i realizowania tego planu tak trochę ad hoc, czy trochę wyłaniania się go w trakcie Sprintu. Jakie tutaj masz, Jacek, przemyślenia w tym punkcie?
Jacek: Na bazie doświadczeń powiedziałbym, że im bardziej zespół rozumie produkt, który tworzy, im lepiej ten produkt rozumie, im lepiej zna możliwości zespołu, im bardziej domena, w której się porusza, jest bliższa domenie prostej bądź domenie skomplikowanej – nie jest to domena jakoś wybitnie złożona, tym bardziej zespoły są w stanie przygotować bardzo konkretny plan. I mówiąc „bardzo konkretny plan” mam na myśli, że wiemy konkretnie, jakie zadania wykonamy, wiemy, kto wykona te zadania, mniej więcej potrafimy to osadzić w czasie – oczywiście im krótszy Sprint, tym ta precyzja jest większa – tak więc powstaje plan, który możemy sobie prześledzić dzień po dniu, osoba po osobie – i on rysuje nam krajobraz na najbliższe dni.
Kuba: Tak w skrócie – co, kto, kiedy.
Jacek: Tak, to jest, myślę, dobry skrót – taki upewniający się, czy ten plan taki dokładny powstał.
Kuba: No to przeciwieństwem tego jest sytuacja, w której zespół właśnie wykonuje jakieś bardzo złożone przedsięwzięcie, jakieś bardzo eksperymentalne – być może jest to zespół, który korzysta ze Scruma do tego, żeby w ogóle poznać jakieś rozwiązanie albo w ogóle wymyślić coś na nowo, nikt tego jeszcze przed nami nie zrobił, albo my w ogóle o tym nie wiemy, że ktoś to już rozwiązał – no i tak naprawdę bardziej jest to projekt badawczy, bardziej jakiś eksperymentalny, gdzie po prostu próbujemy odkryć, próbujemy wymyśleć, próbujemy wpaść na rozwiązanie, ale na etapie rozpoczynania kolejnej iteracji prac nie mamy zielonego pojęcia, jak długo zajmie nam przygotowanie jakiegoś robota, jakiejś sztucznej inteligencji, jakiegoś rozwiązania cloudowego, którego jeszcze nigdy nikt nie wymyślił. No i wtedy bardziej możemy operować w świecie celów, jakie mamy ambicję osiągnąć i być może pomysłów na pierwsze działania albo jakiegoś szkicu, nie wiem, w dobrym scenariuszu to będziemy najpierw robić to, potem to, a potem to. Ale tak naprawdę ten plan nie przeżywa pierwszego kontaktu z rzeczywistością, już pierwszego, drugiego dnia widzimy, że się rozsypuje ten scenariusz, że jednak są jakieś negatywne sytuacje, coś nam się przedłuża, coś jest niemożliwe, a coś się okazuje zupełnie szybkie do zrealizowania i cała taka misterna konstrukcja „co, kto, kiedy”, to w zasadzie dłużej ją tworzyliśmy niż ona się rozsypała po pierwszych godzinach roboty.
Jacek: …niż funkcjonowała.
Kuba: Tak.
Jacek: Moje doświadczenie jest takie – i to w szczególności z zespołów kompletnie nie IT, czyli są to zwykle zespoły, które po prostu rozwiązują jakieś problemy biznesowe, to bardzo często to planowanie to jest coś takiego bardziej, że znamy cel, plus na takim metapoziomie wiemy, że podzielimy się na grupy, zrobimy jakieś rozpoznanie, ktoś zdobędzie jakieś informacje, potem za dwa dni o 14 grupa się spotyka, synchronizuje, coś się wyłania, wiemy coś więcej, robimy kolejne kroki – czyli bardziej taki schemat jak będziemy pracować, natomiast dokładnie to, co będzie tym naszym materiałem, który będziemy wytwarzać, ze względu na to, że nie wiemy co to będzie, no to nie jesteśmy w stanie tego zdefiniować, natomiast cały taki szkielet i plan, jako taki – współpracy, synchronizacji – mamy, on istnieje.
Kuba: I takie podejście wcale nie stoi w sprzeczności ze Scrumem, bo pamiętajmy, że mamy do dyspozycji codziennego Scruma, żeby sobie taki bardzo precyzyjny poziom codziennie ustalać, natomiast ten szkielet, schemat odpowiadał na kilka podstawowych właśnie tematów typu: wewnątrz Sprintu ile mamy dni na załatwienie jakichś danych czy zrobienie jakiegoś eksperymentu, kiedy ponownie przeplanowujemy te rzeczy – albo na codziennym Scrumie, a być może potrzebujemy jakiejś kolejnej, nie wiem, mini-nasiadówy, warsztatu, jakkolwiek to nazwiemy, czyli tak naprawdę ten metapoziom, o którym powiedziałeś, czyli jakiś tam na wysokim poziomie ogólności szkielet czy szkic pracy w Sprincie, może być doszczegóławiany z dnia na dzień na kolejnych codziennych Scrumach. Ale nic nie stoi też na przeszkodzie, żeby spróbować różnych styli, bo to jest taka w sumie generalna rada, która będzie nam się przewijała przez wszystkie te różne opcje. No i zobaczyć czy czasami nie jesteśmy zespołem, który na siłę planuje bardzo szczegółowo – mimo że nasza domena na to nie pozwala. Albo dokładnie odwrotnie – wydaje nam się, że jesteśmy tutaj nie wiadomo jakimi wielkimi eksperymentatorami, a my najzwyczajniej w świecie robimy relatywnie proste rzeczy – po prostu jeszcze kolejną zakładkę dokładamy do systemu.
Jacek: I guzik.
Kuba: I to się… Te guziki czy te przyciski, czy te kolejne jakieś tam rozwijalne listy, no, da się niedużym nakładem czasu rozłożyć na części pierwsze i jakoś precyzyjnie je poplanować, żeby widzieć, ile jesteśmy w stanie zrealizować i ewentualnie wykryć jakieś – czy to zależności, czy to jakieś „wąskie gardła”, czy odkryć, że ten plan ma jakieś ryzykowne miejsca.
Jacek: To, co, myślę, warto dodać, tak podsumowując rozważania na temat tego aspektu, to jest to, że w którym obszarze byśmy się nie znajdowali, dokładnego planu czy takiego bardziej eksperymentowania, nadal mamy najlepszy plan, jaki jesteśmy w stanie przygotować, a mówię to dlatego, żeby nie wpaść w taką pułapkę pod tytułem „tak niewiele wiemy, że w sumie nic nie jesteśmy w stanie zaplanować”.
Kuba: Nie da się tu zaplanować po prostu.
Jacek: Tak, zdecydowanie z doświadczenia wiem, że zawsze jakiś plan jesteśmy w stanie przygotować, no i tylko tutaj będziemy mówić o tej jego takiej głębi odwzorowania, o tym, jak dokładnie będzie on nam mówił, co planujemy wykonać.
Kuba: Albo plan będzie szczegółowym pomysłem na realizację prac, albo będzie pomysłem na pewne podejście do pracy w ramach Sprintu, ale zawsze to może być plan i mamy punkt startu do kolejnych wersji, kolejnej ewolucji czy kolejnych pomysłów. Jeśli chodzi o ewolucję, to możemy tutaj kolejną z możliwych kontrastujących się opcji pokazać. No to taka kwestia planowania znanego rozwiązania, czy stałego zakresu na etapie planowania lub planowania eksperymentów, czyli podejścia do Sprintu jako sposobu na realizację różnych wersji i wymyślenia, czy dojścia do tego, jak to zrobić w środku sprintu, jak wybrać tą najlepszą. Innymi słowy, Planowania w niektórych zespołach mają z góry znane rozwiązanie, pewien Cel Sprintu, do którego w zasadzie jedną jedyną słuszną ścieżką trzeba dojść i przedmiotem planowania i ewentualnego też dopasowywania jest: jak to dokładnie będziemy robić, ewentualnie jak dzielimy się zadaniami. Ale są też możliwe wersje, czy są też zespoły, w których to planowanie będzie bardziej polegało na tym, że mamy jakiś problem do rozwiązania i nawet jeszcze na Planowaniu nie mamy pewności, które z możliwych rozwiązań będzie nam się sprawdzało.
Jacek: I jak o tym mówisz, to też od razu mi się taka pułapka otwiera w głowie na takiej zasadzie, że jeśli zbyt dobrze się czujemy z rozwiązaniem – w sensie ono jest już tak idealnie przygotowane od dawna, no to to też może świadczyć o tym, że realizujemy jakiś z góry założony projekt i bardziej chcemy dostarczyć pewne konkretne efekty, konkretne wymagania, zrealizować coś namacalnego, a nie jesteśmy w sytuacji, w której rozwiązujemy problem, mamy kontekst biznesowy i tak naprawdę to od Zespołu Deweloperskiego zależy, które rozwiązanie zostanie wykorzystane.
Kuba: Tak bardzo jesteśmy wpatrzeni w tą ścieżkę, którą już sobie z góry wymyśliliśmy, że w ogóle nie dostrzegamy, że są też inne ścieżki. I tutaj niektórym zespołom po prostu nie jest dane wybrać jednej z tych opcji po prostu jeśli ich rozwiązanie jest w miarę powtarzalne czy w miarę zdefiniowane, to to planowanie po prostu polega na tym, żeby to sformułować i to zrobić, a jedną jedyną przestrogę, jaką bym robił, to też takie powiedzonko jest, że są ludzi, którzy każdy problem traktują jako gwóźdź do wbicia, bo bardzo dobrze operują swoim młotkiem, no i jeśli, nie wiem, jesteśmy zespołem, który tworzy apki mobilne i ciągle biznes nam przynosi problemy, a my na każde z tych rozwiązań widzimy jako rozwiązanie: „to dołóżmy jeszcze jedną apkę, jeszcze tu do ekosystemu, jeszcze tu coś, tu połączmy, tu rozbudujmy”, to, jakby… jest wiele innych alternatywnych wersji na rozwiązanie niż ta jedyna, w której się czujemy najbardziej pewni. Oczywiście teraz automatycznie zahaczyliśmy o wielki temat zarówno architektury, jak i takiego, powiedzmy, biznesowego podejścia do rozwiązywania problemów, ale również zespoły mogą minimalnie rozszerzać sobie tą perspektywę – czy są jakieś lepsze rozwiązania niż takie, które automatycznie nam przychodzą do głowy, że po prostu tak to zróbmy. No i to wtedy otwiera taką fajną perspektywę, że na przykład najlepszym z rozwiązań jest nie robić nic, najlepszym rozwiązaniem na dany problem jest odesłać ten problem do zupełnie innego zespołu niż nasz i fajnie jest mieć otwartość w dyskusji – na Planowaniach Sprintu – na takie rzeczy. To może czasem oznaczać konieczność rozmowy jeszcze wcześniej na Refinemencie, ale również wewnątrz Sprintu jest wiele różnych opcji na rozwiązanie danego problemu – i bądźmy otwarci na to, że tych opcji jest więcej. I teraz, jakby, zarówno Product Owner, jak i Scrum Master, fajnie, jeśli zachęcają zespół, żeby sobie tą perspektywę rozszerzać, no i, jakby, jeśli w zespole i w Planowaniu jest miejsce, żeby sobie tą różnorodność wersji wymyślać, dopuszczać ją, zaeksperymentować.
Jacek: To zasygnalizuję może też taki obszar tutaj, który może determinować to, w której części tego spektrum, o którym mówimy, się znajdujemy, ponieważ widzę, że bardzo często to oczekiwanie od zespołu czy mają po prostu realizować to, co zostało powiedziane czy mają przestrzeń do eksperymentowania, jest osadzone w kulturze organizacyjnej. I po prostu są firmy, które traktują Zespoły Deweloperskie, obojętnie z jakiej branży są, jako takie zespoły, które po prostu zrealizują to, co im powiemy, są firmy, które traktują te zespoły jako takich eksploratorów, odkrywców i widzą w tych zespołach coś więcej. Całym sercem jestem bliżej oczywiście tej drugiej opcji, natomiast nie każda firma, wydaje mi się, w ogóle wie, że tak możemy spojrzeć na zespół, albo świadomie po prostu chcą realizować rzeczy tak, jak zawsze realizowali, czyli ktoś inny wymyśli, ktoś inny realizuje, a ci, co realizują, mają tylko realizować i najlepiej nie zadawać pytań.
Kuba: No i jak nałożymy na to taki aspekt transformacyjny to też w każdej firmie, która jest eksperymentująca, na początku musi być ten pierwszy najbardziej odważny, który zachęci pozostałych, że: „Hej, to chyba jest opcja jedna z kilku i może pomyślmy, czy są jakieś inne niż ta, która jest nam zlecona”, więc tutaj nawet jeśli jesteś, słuchaczu, w realiach firmy, która jest taka bardziej zleceniodawca-zleceniobiorca i zespół jest po prostu wykonawcą i ma nie zadawać pytań czy nie kwestionować, no to ten pierwszy odważny musi się znaleźć, może to możesz być Ty. Przejdźmy do kolejnego z możliwych spektrów – też takie dosyć wyraźnie kontrastujące dwa możliwe rozwiązania na Planowanie Sprintu, to jest to, od czego zaczynamy – jeden bardzo fajny mechanizm to jest: rozpoczynamy od Celu Sprintu i pod ten cel dobieramy zakres pracy i rozwiązanie. W wielu zespołach spotykamy dokładnie odwrotną kolejność – najpierw znane są elementy zakresu, elementy Product Backlogu, które są najważniejsze, są w pierwszej kolejności realizowane i wybrane przez Product Ownera jako najbardziej priorytetowe i zespół dopiero mając ustalony zakres Sprintu, próbuje zdefiniować Cel Sprintu. Te dwie rzeczy są tutaj, no, ewidentnie kontrastujące – albo zaczynamy od celu, albo zaczynamy od pojedynczych elementów, z których dopiero lepimy cel.
Jacek: Miałem przyjemność pracować z zespołami, które pracowały zarówno startując od celu, jak i startując od zakresu. Ostatnie moje doświadczenia raczej – i takie też wydaje mi się, że chyba nawet bym powiedział, że taka moja prywatna preferencja jest taka, żeby jednak rozpocząć od Celu Sprintu. Z wielu powodów. Po pierwsze, dlatego, że zapewnia to, że zaczniemy od tego „why”, od tej informacji „dlaczego w ogóle powinniśmy poświęcić nadchodzący Sprint na pracę? Co miałoby być efektem tego Sprintu?”. Drugi aspekt jest taki, że jasno określony Cel Sprintu faktycznie sprawia, że Zespół Deweloperski zaczyna myśleć trochę bardziej o sobie jako o zespole i że całe to dążenie w Sprincie jest, żeby zrealizować cel, a nie żeby zrealizować pojedyncze zadania, które mamy do siebie przypisane. Natomiast trzeci aspekt, który uważam za wartościowy w tym kontekście, jest taki, że przygotowany Cel Sprintu na początku Planowania zwykle oznacza też, że Product Owner, czy właściciel produktu, odrobił jakąś tam lekcję w głowie – na zasadzie: „Co ja bym chciał biznesowo zrealizować w kolejnym Sprincie?”, czyli to zwykle mi pozwala uwierzyć w to, że za produktem stoi jakiś większy plan i to nie jest coś takiego, że zobaczymy, co wyjdzie na Planowaniu – i w zależności od tego, jak tam zawieje wiatr, to to zrobimy, tylko jest jednak jakaś koncepcja, jakaś wizja, jakaś roadmapa, taka w rozumieniu – niekoniecznie, że wiemy dokładnie po kolei, co dostarczymy, a raczej… jakie efekty chcemy uzyskać, no i po prostu na tą ścieżkę wchodzimy.
Kuba: Moja osobista preferencja też jest po tej stronie tego kontrastu, więc wcielę się chwilowo w adwokata diabła. Jeśli miałbym powiedzieć, że te rozwiązanie „dobieramy zakres z Backlogu Produktu” jest lepsze, na pewno widzę, że ono się o wiele lepiej sprawdza w zespołach, które mają trochę większy procent maintenance’u albo ich produkt jest już trochę starszy i tak naprawdę opieka nad tym produktem i jego rozwój, to już nie jest stricte tylko pokonywanie kolejnych jakichś przełomowych, nie wiem, wersji czy odkryć, czy dodawanie nowych dużych funkcji – ale to też jest szereg drobnych zleceń z pogranicza utrzymania, drobnych usprawnień, dokładania jeszcze czegoś i tam tak naprawdę może być dosyć różnorodny zakres prac, ale wiele z tych rzeczy jest np. dosyć pilna, albo robi dużą różnicę małym kosztem – stąd, no, może być sens w tym, żeby tworzyć elementy zakresu i zobaczyć, czy czasami one nie tworzą jakiegoś większego celu, lub część z nich nie tworzy większego celu – żebyśmy tutaj nie powtórzyli całego odcinka 7, do którego jeszcze raz zachęcimy. To nie zmienia faktu, że warto myśleć tą perspektywą przyrostowej pracy – czyli każdy Sprint doprowadza do Przyrostu. No i Cel Sprintu jest bardzo fajną praktyką pozwalającą zdefiniować ten Przyrost i ona otwiera też tą różnorodność możliwych opcji – o czym wspominaliśmy chwilę temu.
Jacek: Kolejnym aspektem, który chcielibyśmy przedstawić – w ramach przedstawiania szerokiego spektrum Planowania – jest podejście, w którym bądź wiemy, kto dokładnie będzie wykonywał jaką pracę, natomiast po drugiej stronie osi – absolutnie nie wiemy, kto będzie wykonywał prace. W sensie: wiemy, że jest jakiś plan, ale w jednej opcji potrafimy powiedzieć imiennie kto konkretne zadania wykona, natomiast w drugim wariancie wiemy, że jest jakaś praca, natomiast co do zasady, kto tą pracę wykona, nie jesteśmy w stanie powiedzieć – oczywiście świadomie – podczas Planowania.
Kuba: I teraz, wracając do tego takiego oldschoolowego „co, kto, kiedy”, to w tym przypadku w ogóle nie wiadomo „kto”. I może niektórym się wydawać, że takie opcje na Planowanie są po prostu błędem, natomiast widziałem w praktyce funkcjonujące zespoły – jest kilka warunków, zaraz o nich powiem – takie zespoły, które po prostu tworzyły Backlog Sprintu, były w stanie określić plan, w sensie: jakie aktywności muszą być wykonane, niektóre z nich w jakiej kolejności, żeby cały Przyrost został uzyskany, ale nie potrzebowały ustalić tego planu w dniu Planowania Sprintu, bo na tyle wymienne były funkcje i na tyle zespół był też otwarty na ewentualne zmiany, że w ogóle nie było to problemem, że nie mamy bardzo precyzyjnej listy osób przydzielonych do konkretnych zadań. Jakie są tu warunki, żeby to mogło nastąpić? No, pewnie nie trzeba tak precyzyjnie planować osób, jeśli jesteśmy w stanie się zadaniami w miarę płynnie wymieniać, bez dużej straty na jakości wykonania czy czasie wykonania tych zadań. Też bardzo pomaga w takiej wymienności bardzo drobne podzielenie zadań – jeśli zadania są bardzo małej wielkości, to też regularnie jest okazja, żeby się albo tymi zadaniami dzielić, albo współpracować nad nimi – popracować w dwie, trzy osoby nad jednym zadaniem. Jeśli tego warunku nie spełniamy, to bardzo ciężko jest taką płynność wymieniania się i brak konieczności szczegółowego zaplanowania, no, zrealizować.
Jacek: Inny aspekt, który jest, uważam, też konieczny do tego, żeby to podejście mogło zadziałać, jest taki, że pewna dojrzałość zespołu jest wymagana – taka odpowiedzialność.
Kuba: Tak.
Jacek: Na zasadzie: to nic, że nikt mnie nie przypisał czy ja się nie zgłosiłem do zadania, mnie nadal zależy, żeby Cel Sprintu zrealizować, więc – jako że wszystkim nam zależy – no to każdy tak naprawdę jest takim inicjatorem czy liderem tego, żebyśmy ten plan, czy na codziennym Scrumie czy po prostu w trakcie dnia na bieżąco przygotowywali, uzgadniali – natomiast w zespołach takich, gdzie osoby są przyzwyczajone do tego, że ktoś im przydziela zadanie, to to w skrajnym przypadku może się wydarzyć, że ktoś tam porobi jakieś zadania, ale nigdy nie nastąpi ten moment synchronizacji, w sensie: ja nie miałem tego zadania, nikt mi nie powiedział, no i na koniec Sprintu twarze w podkówkę, smutne twarze Stakeholderów.
Kuba: Albo jedna twarz bardzo uśmiechnięta: „Ja swoje zrobiłem”.
Jacek: Brawo.
Kuba: Brawo ty! No, zahaczyliśmy tym fragmentem mocno już w ogóle o temat, powiedzmy, wartości czy takiego poczucia obowiązku, zaangażowania – są zespoły, których takie przydzielanie zadań do poszczególnych osób, no, nie wynikają li tylko z samej kultury organizacyjnej albo przyzwyczajeń, czy przyzwyczajeń do starych styli zarządzania, ale pamiętajmy chociażby o takim przypadku, też go spotykam, zwłaszcza w tych projektach, w których Scrum jest wykorzystywany poza światem IT, że zespół jest multidyscyplinarny, składa się ze specjalistów o różnych kompetencjach, ale każdy z tych specjalistów jest specjalistą w swoim obszarze – jest w stanie do jakiegoś stopnia wykonywać inne zadania, no, ale załóżmy, nie wiem, analityk danych najbardziej zna się na robieniu jakichś tam raportów i inni co najwyżej mogą usilnie się starać przybliżyć do jego poziomu jakości i jego poziomu też tempa pracy, więc zazwyczaj będzie tak, że dokładnie tylko konkretny Michał, który jest analitykiem, będzie wykonywał analizę danych – i to to samo z siebie się rozumie i co najwyżej zespół długofalowo może, jakby, pracować czy rozwijać się, żeby coraz mniej tych „wąskich gardeł” w zespole było, ale specjalizacja wewnątrz Zespołu Scrumowego jest szarą codziennością w wielu zespołach, no i wtedy nieplanowanie pracy pod konkretne osoby jest wręcz niebezpieczne czy ryzykowne, no, bo może się okazać, że sobie tak dosyć radośnie wrzuciliśmy kilka zadań w Backlogu i damy radę, po czym się okazuje, że co bierzemy zadanie, to one wszystkie są na konkretnego Michała, a inna Kasia w ogóle jest nieobciążona zupełnie. I to nie chodzi o to, żeby teraz się wszyscy obciążali zadaniami, ale w szczególności apeluję o to, żeby się nie przeciążać – nie brać za dużo zadań, jeśli widzimy, że po prostu jako cały zespół nasza przepustowość jest tak duża, jak przepustowość naszego „wąskiego gardła” kompetencyjnego.
Jacek: Zgadza się. Ostatni aspekt, o którym chcielibyśmy powiedzieć, to jest sposób płynności dostarczania Przyrostu produktu, czyli z jednej strony możemy mieć Sprint, gdzie długo, długo nie ma nic i dopiero w ostatni dzień pojawia się Przyrost, co by odzwierciedlał wykres spalania, który nazwaliśmy roboczo „klifowy”, czyli bardzo długo pozioma linia pokazująca, że nic nie spaliliśmy pracy i nagle uskok pokazujący, że nagle wszystko, co było do zrobienia, jest zrobione. W drugim wariancie, druga skrajność to jest bardzo płynne dostarczanie wartości, czyli ten wykres spalania zbliża się do linii trendu pokazującej jak ten wykres powinien wyglądać w praktyce.
Kuba: I to płynne spalanie to jest taki fajny pomysł, taka fajna wytyczna prosto ze szkolenia czy prosto z jakiejś sesji coachingowej ze Scrum Coachem, natomiast w praktyce nie spotyka się w przyrodzie takich prostych linii, czyli zawsze tam będzie jakaś sinusoida. Jesteśmy w tym odcinku w kontekście Planowania Sprintu, no i wiele zespołów może sobie już na Planowaniu zadać pytanie, jak będzie wyglądał rozkład pracy z tej perspektywy skończonych fragmentów tego przyrostu, który chcemy uzyskać na koniec Sprintu. I będą zespoły, które świadomie planują klif, czyli wszystko będzie dopiero ostatniego dnia. I będą zespoły, które zupełnie nieświadomie planują klif – na zasadzie: „No, rozdzieliliśmy się zadaniami, każdy robi swoje i tak się zawsze składa, że do ostatniego dnia walczymy i, no, uda się lub się nie uda”. To jest pytanie, które warto sobie, jako zespół, w ogóle zadać: „Jak to dostarczenie w środku Sprintu będzie wyglądać?”. Są korzyści dostarczania płynnego, są też sytuacje, w których relatywnie ciężko jest uzyskać – zwłaszcza w bardzo krótkim Sprincie – jeszcze dodatkowo superpłynność, że dokładnie 1/5 zakresu Sprintu będzie dostarczana pierwszego dnia tygodniowego Sprintu.
Jacek: No, w szczególności, jeśli to takie… po jednym dniu chcielibyśmy mieć taki mikroprzyrost Przyrostu. Używalne cały czas.
Kuba: Tak. Możemy zakończyć na tym etapie i jest wszystko super.
Jacek: No to… Duże wyzwanie, bym powiedział, to jest taki szczyt Zwinności – by tutaj trzeba było twórców Manifestu zapytać, jak często też w praktyce doświadczają aż takiej elastyczności, czy takiej zdolności dostarczania płynnie wartości.
Kuba: No i trochę ironizujemy, ale to też ironizujemy po to, żeby może trochę wybić z możliwego kompleksu, że ten nasz Burndown Sprintu, jeśli stosujemy w ogóle takie narzędzie, no, nie wygląda optymalnie, nie wygląda jak od linijki, kreska, prosto pod kątem 45 stopni, ładnie schodząca w dół. Ale dlaczego w ogóle pokazujemy to spektrum – bo to jest też, tak jak mówiłem chwilę temu, to jest coś, o czym można pomyśleć na Planowaniu i zastanowić się, czy nie przegrupować naszego planu, żeby tą wartość rozłożyć trochę w czasie. Bardzo prosta konsekwencja, teraz rozmawiamy o klifie z perspektywy wartości biznesowej czy Przyrostu, jeśli tylko w naszym zespole są takie kompetencje czy specjalizacje, na przykład testerska albo analityczna – to te dwie specjalizacje bardzo cierpią na podejściu klifowym, no bo np. analityk ma zalew pracy pierwszych dni Sprintu, tester nie ma roboty, po czym na koniec Sprintu tester nie wie, w co ręce włożyć, analityk szuka sobie zajęcia. Oczywiście oddzielny temat, zasługujący na kompletnie oddzielny odcinek to jest temat kompetencji w zespole, możliwości pomagania sobie itd. – tego teraz nie poruszamy, no ale realia – tak jeszcze raz to powiem – szare realia wielu zespołów tu i teraz są takie, że, no, te specjalizację się czasem pojawiają i być może warto je uwzględniać na etapie planowania. I np. rozsunąć to obciążenie konkretnych osób, zastanowić się czy te dostarczanie nie może być bardziej płynne niż „każdy bierze po jednym zadaniu i dostarcza je na koniec”.
Jacek: Tak. No, ja myślę jeszcze jeden komentarz, że lepszy ten klif niż taki płaski horyzont przez kilka Sprintów, bo takie „Stepy akermańskie” też w przyrodzie występują, niestety. No i to jakby to bym mocno rozróżnił jako taka potencjalnie niebezpieczna ścieżka.
Kuba: No tak, mówisz o niebezpiecznej ścieżce, to czasem widzę dokładnie świadome wzięcie zadań na Sprint, z myślą o tym, że nie zostaną one wykonane. No to to też sobie głośno nazwijmy, że to nie jest okej. Jeszcze jest akceptowalny klif, jeśli z góry przewidujemy czy prognozujemy, że nam się uda zrealizować co najwyżej możemy z tego wyciągać wnioski. No już niewskazaną praktyką, niezgodną ze Scrumem, jest: wziąć sobie zadania i „się zobaczy”, a tak naprawdę Przyrostu to już w poniedziałek na planowaniu wiemy, że na koniec Sprintu na pewno Przyrostu nie będzie, bo nie ma opcji.
Jacek: Tak, tak.
Kuba: No to jak nie ma opcji, no to tak naprawdę musimy wrócić do zupełnie innego tematu, czyli dekompozycji zadań, dobrania takiego zakresu, żeby ten Przyrost był realny czy był prognozowalny do dostarczenia w środku Sprintu. No i albo potniemy chociaż średnio i wtedy będziemy mieli pewnie klif albo naprawdę drobno potniemy te zadania, no i wtedy jest spora szansa na płynne dostarczanie przez cały Sprint.
Jacek: Tak, ale w obu tych przypadkach na końcu Sprintu jest Przyrost – no, jakby to powoduje, że pozostajemy w ramach Frameworka, natomiast jeśli tego Przyrostu nie ma, no to… to nie. Dobrze, to omówiliśmy kilka możliwych opcji Planowania, starając się jak najszerzej zarysować Ci potencjalne możliwości i chcielibyśmy zamknąć odcinek bardzo konkretnymi poradami praktycznymi. Na zasadzie: co albo jakie czynności mogą wpłynąć na to, żeby takie Planowanie Sprintu nam się po prostu udało.
Kuba: Gdy przygotowywaliśmy listę tych pięciu porad, mieliśmy trochę dylematu, czy nie ocieramy się o oczywistości, ale wychodzimy z założenia, że pewne rzeczy trzeba powtórzyć, pewne rzeczy trzeba głośno nazwać, bo być może czasami o nawet najprostszych rzeczach zapominamy. No i taka pierwsza najważniejsza, prosta porada czy sekret na udane Planowanie, tani i prosty i wygodny sposób, to jest: mieć dobry Backlog Produktu.
Jacek: Tak. I tu oczywiście możemy podyskutować co to znaczy „przygotowany Backlog Produktu”, jak do tego dotrzeć, natomiast taki prosty test, który możesz zastosować w swoim zespole jest taki, czy podczas planowania faktycznie zespół jest w stanie zaplanować, czy raczej popadamy w sytuację, w której jest bardzo dużo pytań, jest bardzo dużo niejasności, ktoś podnosi rękę i mówi: „A ja nie rozumiem”, ktoś inny mówi: „Ja nic nie wiem o tym zadaniu”. Czyli to pokazuje, że najprawdopodobniej ta praca, która powinna zostać wykonana na Refinemencie po prostu nie została wykonana i, jak bardzo byśmy się nie starali, no to nieprzygotowany Backlog Produktu powoduje, że ten plan nawet jak jakikolwiek powstanie, to on może kompletnie się wysypać już pierwszego dnia, jak wsadzimy ręce w pracę, i się okaże, że źle zrozumieliśmy, nie dogadaliśmy, te zadania są zbyt duże, nie rozumiemy ich, wpadliśmy w pułapkę założeń. Tak więc porządnie przygotowany Backlog w takim rozumieniu, że zaplanowana góra Backlogu na jakiś tam horyzont czasowy – niech to będzie minimum ten jeden Sprint do przodu – zadania dostatecznie małe, żeby można było je wziąć na Sprint. Zadania jasno opisane, z jasnym celem biznesowym, oszacowane też, że Product Owner mógł podejmować decyzje na zasadzie: wartość a koszt. No to powiedziałbym takie absolutne minimum, żeby nie wpaść w tą pułapkę, że nie mamy przygotowanego Backlogu.
Kuba: Symptomem tego, że nasz Backlog nie jest wystarczająco przygotowany, może być to, że Planowanie się przeciąga. To znaczy – w praktyce zespoły, które spotykam, niezależnie od tego, jak różne konteksty, jak różne sytuacje otoczenia by nie miały, to te czasy na Planowania powinny wystarczać – w zależności od tego, ja zespół sobie to ustali, ale załóżmy, że to jest godzinka, dwie na tygodniowy, dwutygodniowy Sprint – moim zdaniem są w stanie wystarczyć do tego, żeby sobie tę pracę rozplanować. No i jeśli w Twoim zespole planowanie zajmuje wiele godzin, pół dnia i więcej – i jest męczarnią, a na końcu i tak wszyscy czują, że planowanie nie zostało zrealizowane, no to bardzo poważnie bym się zastanowił, czy czasami zamiast nieudanego planowania nie wyszło całkiem niezłe doskonalenie Backlogu, tylko niestety, ale na siłę zlepione z próbą Planowania. No i niestety, ale tak to jest, że jeśli nie zrobimy Refinementu porządnego i nie uzyskamy dzięki temu gotowego do rozpoczęcia pracy, czy przygotowanego Backlogu, no to jest tutaj konsekwencja. I wracając do tego, co powiedziałeś jakiś czas temu, że temat definicji tego, co to znaczy przygotowany Backlog jest otwarta albo zależna od zespołu, no to stąd w Scrumie stosowana bywa praktyka Definition of Ready, czyli definicja gotowości, gdzie zespół sobie po prostu ustala, jaki standard zadań uważamy za wystarczająco przygotowane, żeby rozpocząć czy móc je wziąć na Planowanie Sprintu. I w różnych zespołach, w różnych kontekstach, w różnych produktach, w różnych technologiach to mogą być różne rzeczy, ale warto sobie to jawnie nazwać, ustandaryzować, być może zrobić sobie jakąś listę kontrolną – punkty, które każdy element Backlogu Produktu musi spełnić, żebyśmy w ogóle mogli je podejmować. I jeśli nie spełnia tej Definition of Ready, no to po prostu nie podejmujemy tego, bo one są niewystarczająco przygotowane. Następną radą praktyczną, również trochę w naszym odczuciu zahaczającą o w miarę oczywiste rzeczy, ale zaraz spróbujemy pokazać, że wcale takie nie są, to jest uwzględnienie mocy przerobowych zespołu, które są do dyspozycji w ramach Sprintu, który podlega Planowaniu.
Jacek: Tak, może dając konkretny przykład tutaj, też zaczynając od momentu, kiedy jesteśmy na Przeglądzie Sprintu, zespół próbuje pokazać Przyrost, tego Przyrostu właściwie nie ma. Tak jak mówiliśmy – smutne twarze, przechodzimy na Retrospektywę, no i tam zaczynamy dyskusję, dlaczego nam się nie udało. No i zaczyna się cała litania i historia pod tytułem: „Tomek miał dwa dni szkolenia, był wycięty, Krzysiek trzy razy pracował z domu, Kasia miała rekrutację, ktoś tam coś tam” itd. itd. itd. No i są zespoły, które mówią: „No tak, gdybyśmy wiedzieli wcześniej, że te rzeczy się zadzieją, tobyśmy zaplanowali”. No tylko tak – oprócz takich zdarzeń losowych, wszelkiego rodzaju takie rzeczy, że ktoś ma jakieś spotkania umówione, wydarzenia, że go nie ma, że ma konferencję – zwykle jesteśmy w stanie przewidzieć, a wręcz jest to już bardzo dobrze zaplanowane, tak więc użycie tej wiedzy świadomie na Planowaniu, do tego stopnia, że jeżeli planujemy sobie wizualnie, po prostu wykreślić pewne obszary z naszej dostępności z kalendarza powodują, że nagle się okazuje: „hm, z tego tygodniowego Sprintu to tak naprawdę to nam zostały może trzy dni” – i to zupełnie zmienia perspektywę Planowania. Tylko po prostu trzeba sobie taki punkt dołożyć na checkliście przygotowywania Planu Sprintu uwzględnijmy naszą dostępność, spójrzmy w nasze kalendarze, zobaczmy, jak faktycznie jesteśmy dostępni. No, doświadczenie moje jest takie, że stuprocentowa dostępność członków Zespołu Deweloperskiego to jest rzadkość.
Kuba: I są rzeczy, których zaplanować nie jesteśmy w stanie – i na nie po prostu możemy wziąć pewną poprawkę, poprawkę, czy jakiś bufor, ale cała masa rzeczy planowalna jest. Do listy przykładów, które wymieniłeś, która była dosyć kompletna i bardzo długa, no to jeszcze dołożyłbym jakieś aktywności związane ze współpracą w ramach kilku zespołów. Jeśli dostarczamy jakiś serwis, z którego korzystają inne zespoły, jeśli jesteśmy częścią jakiegoś skalowanego projektu, jeśli nasi eksperci są jednocześnie mentorami dla jakichś początkujących deweloperów z innych zespołów – no to to są wszystko aktywności, które mogą nam konsumować czas i być może takim po prostu nawykiem czy takim dobrym zwyczajem jest, że każdy członek zespołu dokonuje refleksji na temat tego, jaką będzie mieć dostępność w ramach Sprintu i Planowanie Sprintu właśnie zaczynamy od takiej inwentaryzacji znanych niedostępności lub czasami odwrotnie patrząc – znanych dostępności, jeśli nie jesteśmy w stanie sobie tego jakoś inaczej rozłożyć.
Jacek: Kolejną poradą, którą uważamy, że warto uwzględnić w trakcie Planowania Sprint, jest uwzględnienie historycznych wyników zespołu. Na czym to polega? No, przede wszystkim na tym, żeby dokonać refleksji na temat wcześniejszych możliwości, jeśli chodzi o ilość wykonanej pracy, i uwzględnić tą informację podczas bieżącej sesji Planowania. Czyli przykładowo: jeżeli mówimy o zespołach, które wykorzystują np. Story Pointy, jako sposób na określenie prędkości, no to, jeżeli trzy ostatnie Sprinty nasza prędkość oscylowała w granicach 30, a zespół przekonuje, że tym razem się uda dostarczyć 60, no to na pewno jakaś tutaj lampka by mi się zapaliła w głowie, co takiego się wydarzyło, że zespół podwoił swoją wydajność.
Kuba: Te historyczne wyniki łączą się z tym poprzednim, czyli nawet jeśli Sprint w Sprint robiliśmy 30, ale w tym Sprincie akurat wyjątkowo duży poziom niedostępności mamy z powodów jakichś np. szkoleń czy konferencji, to wręcz nawet jedno i drugie bym połączył i uwzględnił nie tylko historyczne wyniki, ale też typowe capacity, jakie zazwyczaj w ramach Sprintu mamy. No a wracając do tych historycznych wyników, nawet jeśli nie liczymy Story Pointów albo oceniamy naszą pracę w godzinach, co w zasadzie przekreśla możliwość takiego sensownego policzenia, takiego porównywania zadań do siebie, no bo zazwyczaj zaplanujemy pracę dokładnie na pełen Sprint i te historyczne dane nam niewiele mówią. To i tak jest cała masa miejsc, w których możemy sobie porozmawiać o tym, np. perspektywą jakiejś jednostki wartości, którą dostarczamy. Jeśli nasz zespół dostarcza np. raporty, no to typowo w Sprint dostarczamy trzy raporty, czy na pewno jesteśmy przekonani, że w ten Sprint wyjątkowo zaplanujemy dostarczenie sześciu. I też ewentualnie odwrotnie patrząc – to tak trochę temat ze styku Retrospektywy i Planowania, jaką część planowanej pracy w poprzednim Sprincie nam się udało zrealizować. Bo może wpadamy w ten antywzorzec takiego efektu, który ja znam z zarządzania strategicznego zwanego „efektem łyżwy”, że Sprint w Sprint planujemy podwojenie naszej możliwości dostarczania, tylko nikt nam głośno tego nie wytknął, czyli co Sprint przewidujemy, że zrobimy 60, robimy 30, i na kolejnym Sprincie jakby nic się nie zmieniło, znowu planujemy 60 i dostarczamy 30. I teoretycznie może nie ma nic w tym złego, tylko problem się zaczyna wtedy, jeśli dużą część naszej energii poświęcamy w Sprincie na zadania, których w tym Sprincie nie skończymy, a wręcz tam gdzieś „przyduszamy”, tu coś… obniżamy jakość, tu jakoś byle jak coś traktujemy, tu się nie dokomunikowujemy, czyli pędzimy przeciążeni zamiast wyluzować, zrzucić 1/3 bagażu, w ogóle na etapie Planowania nawet nie próbować do tego podchodzić i skupić się na tym, na czym jesteśmy w stanie się skupić – jest niezerowa szansa, że planując 35, zrealizujemy 35. W sytuacji tej alternatywnej, w której zaplanowalibyśmy 60, a dowieźli 30. Niestety nie działa, zwłaszcza w pracy kreatywnej zasada, że jak jesteś przeciążony robotą, to zrobisz więcej. Może to działa w obowiązkach domowych, może to działa przy przerzucaniu węgla, ale na pewno nie w pracy kreatywnej.
Jacek: Kolejną poradą, którą dla ciebie mamy, jest porada zachęcająca do tego, co już trochę zdradziliśmy na początku odcinka, żeby zacząć od Celu Sprintu. Ciekawego tweeta ostatnio widziałem – ktoś policzył, ile razy w Scrum Guidzie występuje velocity, i zdaje się, że występowało raz. I z drugiej strony policzył, ile razy występuje Cel Sprintu – ten Cel Sprintu występował kilkanaście razy – i to bardzo fajnie pokazuje, jak zorientowany jest Scrum – raczej na konkretny rezultat, na konkretne efekty, a nie na to, żeby się tam zastanawiać, jaką mamy prędkość, no bo prędkość pracy to jest jedno, natomiast to, co dostarczamy tą prędkością, to drugie. I to drugie to właśnie jest to, na czym się powinniśmy skupić przede wszystkim, czyli jaka jest wartość, co chcemy osiągnąć, jakich efektów się spodziewamy po realizacji Celu Sprintu. No i żeby w ogóle wejść na te tony i w tą dyskusję, no to ten Cel Sprintu powinien się na tym Planowaniu Sprintu, gdzieś na początku tego wydarzenia, pojawić.
Kuba: Naszym największym zmartwieniem na Planowaniu Sprintu powinno być to, jaką różnicę biznesową zrobimy, a nie ile punktów jakichś umownych czy sztucznych, czy jak bardzo obciążeni godzinami czy dniami pracy będziemy i jak to będzie wyglądało w raportach. Żaden manager nie będzie się skupiał na pracy członków zespołu – żaden mądry manager, może dopowiem – jeśli ten zespół po prostu będzie Sprint w Sprint robił różnicę biznesową, dostarczał rezultaty, fajne rozwiązania, eksperymenty, kreatywne rzeczy dostarczał. A czy oni będą robili tam 17 umownych jednostek czy 15 czy 19, czy zaraportowane będzie 8 czy 7 godzin, to powinien być zastępczy temat, temat zupełnie nieistotny. Ale niestety czasem jest zaklęte koło, że zespoły same sobie pozwalają wkręcić się w te takie liczenie jakichś punktów, zamiast po prostu stwierdzić: „Słuchajcie, co jest najważniejsze”. I tu jest rola i Product Ownera, i Scrum Mastera, i wszystkich członków zespołu, oraz również managementu czy Interesariuszy pojawiających się na Sprint Review. Oni wszyscy powinni rozmawiać o tym, jaką wartość biznesową dostarczamy, jakie cele kolejne realizujemy i jakie cele stoją jeszcze przed nami.
Jacek: I ostatnia wskazówka, którą mamy praktyczną do wykorzystania podczas Planowania Sprintu, to jest zachęta do budowania wizualnego Planu Sprintu, czyli próby przedstawienia naszego planu w postaci czy to jakiegoś kalendarza, na który sobie naniesiemy konkretne zadania, które chcemy wykonywać czy to w postaci jakiegoś diagramu, szkicu, jakiejś osi – forma tak naprawdę jest tutaj drugorzędna, natomiast dobrze zwizualizowany plan na bardzo wczesnym etapie upewnia nas, że pewne rzeczy rozumiemy tak samo. I bardzo długo możemy się zgadzać, w takiej komunikacji werbalnej, czy rozumiemy – „tak, rozumiemy”, natomiast bardzo dużo mam takich doświadczeń: nagle ktoś bierze marker, rysuje to rozwiązanie albo rysuje, jak będziemy współpracować i nagle ktoś mówi: „Czekaj, czekaj, chwila, ja myślałem zupełnie inaczej”. „A jak?”. „No to daj markera” – i zaczyna się malowanie. No i nagle się okazuje, że to poczucie, że doskonale wiemy i rozumiemy w ten sam sposób, to są dwa albo trzy kompletnie różne pomysły, które tak naprawdę dopiero wyłoniły się na skutek tego, że spróbowaliśmy je zwizualizować.
Kuba: I są korzyści takie, jakie mówisz, ale też jest taka bardzo przyziemna korzyść, taka moderacyjna czy facylitacyjna, że jeśli wspólnie, jako zespół, budujemy taki plan pracy, to jest dużo większa szansa, że się wszyscy zaangażujemy w jego tworzenie, czyli sama ta sesja, sam ten warsztat czy to wydarzenie scrumowe, będzie po prostu o wiele bardziej angażujące, bo jeśli, no, zachęcamy jakimś takim ćwiczeniem typu: „To teraz wspólnie rozpiszmy nasz pomysł na realizację Sprintu”, jakąkolwiek metodą planowania byśmy nie próbowali operować, no to zapraszamy do wypisywania wszystkich członków zespołu, układania ich na jakiejś osi, przestrzeni, jakimś schemacie, bloku, cokolwiek – i też razem przy tym manipulujemy. Tak naprawdę jesteśmy w stanie ogarnąć takie Planowanie bardzo szybko, właśnie też dzięki zrównolegleniu pracy, a to zrównoleglenie jest możliwe, właśnie jeśli dobieramy metody prezentowania tego planu, które mogą być równolegle przerabiane czy tworzone, a później poprawiane.
Jacek: I to była ostatnia porada, którą mieliśmy dla Ciebie dzisiaj. Podsumowując, rozpoczęliśmy odcinek, definiując czym jest Planowanie Sprintu, następnie porozmawialiśmy sobie o dostępnym spektrum opcji planowania, starając się z jak najdalszych i najszerszych perspektyw spojrzeć na to konkretne wydarzenie i zamknęliśmy odcinek konkretnymi, praktycznymi poradami, które możesz użyć w swoim zespole już od najbliższego Planowania.
Kuba: Dostajemy od Was czasem informacje o tym, że przegapiacie kolejne odcinki. Publikujemy je regularnie co trzecią środę od rana, ale jest bardzo proste rozwiązanie systemowe – zwróćcie uwagę czy jesteście zapisani na naszym newsletterze, czy obserwujecie nasze media społecznościowe – Facebook, Twitter. Możecie też zapisać się w kanałach, w których słuchacie naszego podcastu na urządzeniach mobilnych, możecie nas obserwować na Spotify, subskrybować na Podcast Apple’a. Dzięki takim rozwiązaniom – relatywnie proste, jeden klik – będziecie mieli pewność, że dostaniecie powiadomienie o każdym kolejnym odcinku.
One Reply to “Porządne Planowanie Sprintu”