Porządne Planowanie Sprintu

Planowanie Sprintu rodzi wiele pytań w zespole. Przedstawiamy Sprint Planning, analizujemy to wydarzenie z różnych perspektyw a w drugiej części materiału dzielimy się praktycznymi poradami, które można wykorzystać od zaraz, podczas najbliższego planowania.

W tym artykule poruszymy następujące kwestie:

Czym jest Planowanie Sprintu?

Najprościej mówiąc Planowanie Sprintu, jest wydarzeniem Scrumowym, podczas którego Zespół Scrumowy ustala 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 Deweloperzy (w Scrumowym rozumieniu tego słowa) decydują, ile faktycznie pracy są w stanie wykonać, opierając się na danych historycznych.

To rozróżnienie na dwa etapy ma ciekawe korzenie historyczne. Na szkoleniu Certified Scrum Master 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. Historycznie były to dwie wyraźne, oddzielne czynności. Jedna z kolejnych aktualizacji Scruma trochę zatarła to rozróżnienie, a te obie aktywności (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, jeśli temat jest dla Ciebie interesujący, zapoznaj się też z podlinkowanym materiałem.

Zarówno Planowanie Sprintu, jak i Cel Sprintu, dążą do tego, aby w każdym Sprincie powstał Przyrost Produktu, będący efektem pracy całego Zespołu Scrumowego.

Jak powinno wyglądać Planowanie Sprintu?

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 różnych zespołach mogą funkcjonować. Nic też nie stoi też na przeszkodzie, żeby spróbować różnych stylów planowania 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. Zawsze jakiś Plan jesteśmy w stanie przygotować, ale jego konkretny kształt niech kształtuje się na bazie kolejnych prób i rosnącego doświadczenia.

Budować dokładny plan pracy czy tylko zarys działania?

Pierwszym spektrum jest kontrast: przygotowanie na Planowaniu Sprintu 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 szkic działania 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ł. Tak naprawdę bardziej jest to projekt badawczy, a Zespół próbuje wpaść na rozwiązanie. Stąd 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 Zespół będzie operować na poziomie celów: jakie ma ambicję osiągnąć? jakie ma pomysły na pierwsze działania? Z takiego podejścia nie da się najczęściej uzyskać więcej niż szkicu Planu. Dodatkowo ten szkic nie przeżywa pierwszego kontaktu z rzeczywistością, zwykle już pierwszego-drugiego dnia Sprintu widać, że plan się rozsypuje (z powodu negatywnego rozwoju sytuacji, przedłużania pracy, czy odkrycia elementów niemożliwych do realizacji). Czasami dochodzi do paradoksu, w którym plan był dłużej tworzony, niż pozostał aktualny. W takiej sytuacji bardziej istotne jest, by zespół znał cel swojego działania i ustalił schemat jak będzie przebiegać praca.

Takie podejście wcale nie stoi w sprzeczności ze Scrumem, bo pamiętajmy, że Zespół ma do dyspozycji Codzienny Scrum, żeby codziennie ustalać plan działania na bardzo precyzyjnym poziomie.

Planować stały zakres rozwiązania czy przewidzieć eksperymenty?

Kolejny kontrast w podejściu do planowania, to planowanie znanego rozwiązania (ze znanym stałym zakresem), albo planowanie eksperymentów (gdzie rozwiązanie pojawi się dopiero w środku Sprintu). 

W tej pierwszej sytuacji łatwo wpaść w pułapkę zbyt wczesnego założenia o obranej ścieżce na rozwiązanie. Dlatego zespoły mogą minimalnie rozszerzać sobie swoją perspektywę i zastanowić się, czy są jakieś lepsze rozwiązania niż takie, które automatycznie przychodzą im do głowy.

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 Scrumowe, jako takie zespoły, które po prostu zrealizują to, co im się zleci, a są firmy, które traktują te zespoły jako eksploratorów/odkrywców, którzy mają dużą dozę swobody działania. Oczywiście całym sercem jesteśmy bliżej tej drugiej opcji.

Planować zaczynając od Celu czy kończyć Planowanie ustalając Cel?

Kolejne z możliwych spektrów w kwestii tego, jak może wyglądać Planowanie Sprintu i kolejny możliwy kontrast, to pytanie od czego zaczynamy sesję planowania.  

Jedną z możliwości jest rozpoczynanie od Celu Sprintu i pod ten cel dobierany jest zakres planowanej pracy i rozwiązanie. Przeciwieństwem tego jest podejście, w którym najpierw ustalane są elementy zakresu i z nich potem definiowany jest Cel Sprintu, który je łączy.   

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. Uważamy, że lepiej jest rozpocząć od Celu Sprintu.

Dobrze jest zaczynać każde działanie od pytania „Dlaczego to robimy”. Zgodne z tym będzie, by Planowanie Sprintu rozpoczynać 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.

Dodatkowo 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 każdy członek zespołu ma do siebie przypisane.

Cel Sprintu przygotowany na początku Planowania zwykle oznacza też, że Product Owner wie, co powinno być biznesowo zrealizowane w kolejnym etapie rozwoju danego produktu. Pozwala to założyć, że za produktem stoi jakiś większy plan i Zespół nie działa w sposób chaotyczny. Niekoniecznie musi być precyzyjnie określone, co po kolei dostarczymy w wielu Sprintach w przyszłości, ale dobry Cel Sprintu (i powiązany z nim Cel Produktu) daje wyobrażenie jakie efekty PO chce uzyskać i jaką ścieżką zespół ma podążać przy rozwoju kolejnych Przyrostów. 

Z kolei podejście, w którym Planowanie Sprintu rozpoczyna się od ustalenia zakresu Backlogu lepiej się sprawdza w zespołach z większym stażem lub których produkt jest bardziej dojrzały. 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. W takiej sytuacji zakres prac może być bardzo różnorodny a wiele z tych rzeczy jest np. dosyć pilna albo robi dużą różnicę małym kosztem. W takiej sytuacji może mieć sens, żeby ustalić najistotniejsze elementy zakresu i zobaczyć, czy czasami nie łączą się do jakiegoś większego celu.

Przydzielać zadania do osób czy zostawić je nieprzydzielone?

Kolejnym spektrum Planowania jest kwestia odpowiedzialności za zadania. Niektóre zespoły planują tak, że w efekcie wydarzenia na początku Sprintu możliwe jest imienne wskazanie, kto będzie wykonywał konkretne zadania. Inne zespoły prowadzą swoje Planowanie Sprintu tak, że ustalają jak cała praca w Sprincie ma być wykonana, ale podczas wydarzenia nie planują kto za co będzie odpowiedzialny. 

To drugie podejście, w którym nie ustalamy odpowiedzialności za zadanie, może się sprawdzić, jeśli w zespole jest możliwość w miarę płynnego wymieniania się zadaniami bez dużej straty na jakości czy czasu ich wykonania. Pomaga tu też bardzo drobne podzielenie zadań na mniejsze czynności, a także dojrzałość zespołu i odpowiedzialność jego członków. Każdy może być inicjatorem tego, żeby Plan zrealizować, podjąć się konkretnego zadania albo zwrócić uwagę na nie innym członkom zespołu. 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. 

Planować utworzenie Przyrostu na końcu Sprintu czy wcześniej?

Ostatnim aspektem, jaki warto wyróżnić, jest moment dostarczania Przyrostu produktu w Sprincie. W jednej skrajności mamy Sprint, gdzie dopiero w ostatnim jego dniu pojawia się Przyrost. Na wykresie spalania Sprintu (nazwalibyśmy go “klifowym”) widoczna byłaby bardzo długa pozioma linia, pokazująca, że prawie nic nie jest skończone, a następnie nagły jej skok mówiący o tym, że wszystko co było do zrobienia, zostało zrobione tuż przed zakończeniem iteracji. W przeciwnym podejściu mamy bardzo płynne dostarczanie wartości, a wykres spalania zbliża się do linii absolutnie równomiernego postępu dzień po dniu. 

Gdy Zespół Scrumowy realizuje Planowanie Sprintu, warto by zadane zostało pytanie: „Jak będzie wyglądać dostarczenie Przyrostu w trakcie Sprintu?”. Są korzyści dostarczania płynnego, są też sytuacje, w których relatywnie ciężko jest je uzyskać – zwłaszcza w bardzo krótkim Sprincie. Z kolei gdy obserwujemy Zespoły stosujące podejście “klifowe”, to często widać w nich dodatkowe zjawisko nierównomiernego obciążenia poszczególnych specjalistów np. analityk ma zalew pracy w pierwszych dniach Sprintu, gdy 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. Warto uwzględniać istniejące 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 zrealizować Planowanie Sprintu?

Podzielimy się z Tobą 5 wskazówkami, które mogą pomóc skutecznie przeprowadzić Planowanie Sprintu.

1. Zadbajcie o dobry Backlog Produktu

Dzięki dobrze zaopiekowanemu Backlogowi Produktu w zespole będzie większe zrozumienie tego, co jest do zrobienia, na czym polegają zadania i czas przeznaczony na Planowanie Sprintu 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. Developerzy źle się zrozumieli, zadania są zbyt duże albo ktoś w Zespole wpadł w pułapkę błędnych założeń. Wystarczy, gdy Backlog Produktu jest porządnie przygotowany 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 Sprintu 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żacie za wystarczający do rozpoczęcia planowania. Warto sobie to wspólnie określić, być może nawet zrobić jakąś listę kontrolną, czyli punkty, które każdy element Backlogu Produktu musi spełnić, żebyście w ogóle mogli je uwzględniać w planowaniu.

2. Uwzględnijcie dostępność członków zespołu

Z praktyki wiemy, że zdarza się zależność między tym, że wybrane elementy z Planu Sprintu nie zostały zrealizowane, a urlopem, chorobą, albo innego rodzaju niedostępnością potrzebnego specjalisty (szkolenia, rekrutacje, działania w innych zespołach). Dlatego warto by Planowanie Sprintu miało w jednym ze swoich elementów sprawdzenie w kalendarzu dostępności 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, pozwalający Zespołowi zareagować i zmodyfikować plany, jeśli zdarzy się niedostępność.

3. Bazujcie na historycznych wynikach zespołu

Warto co jakiś czas (np. na Retrospektywie Sprintu, zwłaszcza po nieudanym Sprincie) dokonywać refleksji na temat ilości faktycznie wykonanej pracy w danej iteracji i uwzględnić tę informację podczas sesji Planowania. Przykładowo, jeżeli przez trzy ostatnie Sprinty prędkość Zespołu oscylowała w granicach 30 StoryPointów, to trudno zakładać, że w kolejnym Sprincie osiągnie 50.

Odwołanie się do danych historycznych na temat realnego poziomu dostarczania pozwala też uchronić się przed antywzorcem, w którym co Sprint planuje się radykalne przyspieszenie (i w związku z tym prognozowana jest realizacja bardzo dużej ilości elementów), gdy w rzeczywistości za każdym razem realizowana jest tylko ułamkowa część zakresu. Szczególnie problematyczne jest to wtedy, gdy dużą część energii Zespół poświęca na zaplanowanie tych niezrealizowanych zadań, a z kolei w czasie Sprintu obniża jakość, aby jak najwięcej obiecanych zadań zrobić. Warto patrzeć na dane historyczne i podejść bardzo realistycznie do Planowania, bo przeciążenie pracą wcale nie sprawi, że zostanie więcej zrobione.

4. Zaczynajcie Planowanie Sprintu od Celu Sprintu

Ktoś kiedyś policzył ile razy w Scrum Guide występuje słowo Velocity, a ile Cel Sprintu. Wynik dla ówczesnej wersji Przewodnika po Scrumie (Velocity 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. Ważniejsze jest to jaka jest wartość i jakość tego, co Zespół Scrumowy dostarcza. I właśnie na rezultatach Zespół powinien się skupić przede wszystkim. Warto zacząć Planowanie Sprintu od zadania sobie pytania co chcemy osiągnąć i jakich efektów się spodziewamy po realizacji Celu Sprintu. Zadaniem Product Ownera i Scrum Mastera może być przypominanie o wartości biznesowej i o kolejnych Celach (Produktu i Sprintu).

5. Wizualizujcie Plan Sprintu

Warto spróbować przedstawić przygotowywany Plan w postaci wizualnej. Może to mieć formę kalendarza, na który naniesione są konkretne zadania, które Zespół chce wykonywać. Plan wizualny może mieć też postać diagramu, szkicu lub osi z ukazaniem zależności między zadaniami. Forma tej wizualizacji jest drugorzędna, natomiast dobrze zwizualizowany Plan na bardzo wczesnym etapie upewnia członków Zespołu, że pewne rzeczy (zwłaszcza sekwencja zadań i ich ułożenie względem siebie) rozumieją tak samo.

Dodatkowo wspólne budowanie takiego wizualnego planu pracy jest bardziej angażujące, a samo Planowanie Sprintu przebiega dzięki temu dużo szybciej, również przez to, że daje to okazję do zrównoleglenia aktywności planistycznych.

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.

Dodatkowe materiały

• Cel Sprintu
• Porządny Backlog Sprintu
• Dlaczego zespoły nie planują zespołowo?
• Co uwzględnić w planowaniu zespołowym?
• Praktyki wspomagające planowanie Sprintu

Transkrypcja podcastu „Porządne Planowanie Sprintu”

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 Sprintu 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 Sprintu – 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 Sprintu 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 Sprintu 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 Sprintu 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 Backlogu Produktu, 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 Sprintu 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 Sprintu, 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 Sprintu 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 Sprintu zajmuje wiele godzin, pół dnia i więcej – i jest męczarnią, a na końcu i tak wszyscy czują, że planowanie Sprintu 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. 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ć. A 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. I są zespoły, które mówią: „No tak, gdybyśmy wiedzieli wcześniej, że te rzeczy się zadzieją, tobyśmy zaplanowali”. 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 Sprintu 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.