Jak radzić sobie z wrzutkami w Scrumie?

Ważne jest, żeby zespół miał zdolność do ewaluacji wrzutek i podjęcia merytorycznej dyskusji z interesariuszami. Wrzutki to normalne zjawisko w trakcie Sprintu. Są to nieplanowane prace niebędące rzeczami krytycznymi czy awariami. Jak zatem zapanować nad zadaniami, które się nagle pojawiają? Skorzystaj z naszych kilku rozwiązań, żeby sobie z tym poradzić.

Wrzutki, znamy je wszyscy. Są one normalnym zjawiskiem w trakcie trwania Sprintu. Dlatego warto nauczyć się nimi zarządzać i rozmawiać z interesariuszami na ich temat.

Nieplanowane zadania, czyli wrzutki, otrzymujemy od różnych osób w trakcie trwania Sprintu. Nie są one awariami ani nie są krytyczne dla poprawnego działania usługi, produktu czy ogólnie firmy, jednak dla zlecającego często mają status pilnych i na wczoraj.

W tym artykule dzielimy się z Tobą naszymi wskazówkami jak zapanować nad zadaniami, które pojawiają się nagle i potrafią zaburzyć plan Sprintu.

Jak radzić sobie z wrzutkami w Scrumie?

Przede wszystkim przestrzegamy Cię przed skrajnościami. Z jednej strony nie przyjmuj wszystkich wrzutek, jak leci, pamiętaj o Celu Sprintu i nie sabotuj jego osiągnięcia przez realizowanie nieplanowanych zadań.

Podejście odwrotne, czyli odrzucanie każdej wrzutki, też nie jest dobrym podejściem. Nie zasłaniajcie się Celem Sprintu, odmawiając interesariuszom. Jest to z jednej strony niezgodne z samą definicją Scruma (czyli elastyczne podejście do pracy, reagowanie na zmiany), z drugiej strony jest to niepragmatyczne.

Kluczową umiejętnością zespołu jest zdolność do oceny konkretnej wrzutki i podjęcie merytorycznej dyskusji z interesariuszami, która powinna się zakończyć przemyślaną decyzją uwzględniającą potrzeby i cele obu stron.

Nim przejdziemy do konkretnych wskazówek jak radzić sobie z wrzutkami, to chcemy zaznaczyć, że nie będziemy tu poruszać sytuacji, gdy wrzutki są nagminne, a ich podłoże ma problem systemowy dotyczący całej organizacji. Tu należy dokonać głębszej analizy i przeprowadzenia bardziej złożonych usprawnień.

5 sposobów na wrzutki w Scrumie:

1. Przetestuj krótsze Sprinty
   W tym podejściu nie zajmujemy się wrzutką od razu, a jednocześnie oferujemy interesariuszom większą responsywność i stosunkowo krótki czas oczekiwania na zaopiekowanie się nowym zadaniem. Po prostu częstotliwość sesji planowania się zwiększa.
   
   Wyobraźmy sobie, że pracujemy w Sprincie dwutygodniowym. Wystartowaliśmy go w poniedziałek, a już w środę pojawia się interesariusz z pilnym tematem do zrealizowania. Dzięki krótszym Sprintom nie musi on czekać aż 1,5 tygodnia na nowy Sprint, tylko 2 dni. My z kolei nie burzymy planu Sprintu.
   
   Tygodniowy Sprint? Tak. Pamiętaj, że Przewodnik po Scrumie nie narzuca przeprowadzania dwutygodniowych Sprintów. Takie podejście jest bardzo popularne, jednak nie musi się sprawdzać w każdym zespole.
   
   Krótsze Sprinty mogą w efekcie sprawić, że wrzutki przestaną być na tyle pilne, żeby interesariusz nie mógł poczekać kilku dni do nowego planowania.  

2. Zaplanuj bufor
   Jeśli w naszych Sprintach wrzutki pojawiają się od czasu do czasu, to dobrą praktyką jest zaplanowanie sobie przestrzeni czasowej na takie dodatkowe zadania. Czyli nie jesteśmy zaplanowani na 100%. Dzięki temu fakt, że w środku Sprintu pojawia się wrzutka, nie powoduje np. zawalenia Celu sprintu.
   
   Wielkość bufora określ bazując na danych historycznych, patrząc jak często wrzutki się pojawiały, jak duże były i ile czasu zajmowały zespołowi. A jeśli nie posiadacie danych historycznych, to po prostu testujcie różne bufory.
   
3. Policz Koszt Opóźnienia (Cost of delay)
   W podejściu tym zastanawiamy się, czy opóźnienie realizacji tego zadania będzie nas kosztować. Jeśli tak, to ile będzie kosztować to opóźnienie.
   
   Przykładowo, rozwijamy jakąś aplikację e-commerce’ową. Przestała działać możliwość udzielania kredytu osobom, które chcą kupić coś na naszej stronie. Aby podjąć decyzję, czy powinniśmy od razu zająć się tą sytuacją, należałoby się zastanowić, jak dużo pieniędzy firma straci w momencie, kiedy przez na przykład trzy dni nie będziemy w stanie tych rat udzielać. Dodatkowo warto byłoby tę potencjalną stratę zestawić z kosztem elementów, które były pierwotnie zaplanowane. Co będzie bardziej kosztowne dla organizacji?
   
   Mnogość możliwych scenariuszy jest tu ogromna. Jakaś drobna rzecz i kilka dni roboczych całego zespołu, może czasami robić gigantyczny wynik, a wtedy ważniejsze może będzie zareagowanie na to.
   
   Oczywiście zakładamy tu, że mamy miary i wszystko jest policzne, a nie, że każdy wymyśla swoje liczby, które nie są poparte czymkolwiek.
   
4.  Wymieniaj elementy 1 za 1 (Changes for free)
   Jesteśmy z tym ok, że od czasu do czasu pojawiają się wrzutki. Mamy jednak w Zespole taką zasadę, że jeśli coś nowego wchodzi do Sprintu, to my z tego Sprintu coś podobnego zabieramy. Zastanawiamy się, z czego możemy zrezygnować, co możemy zapauzować, aby pojawiła się przestrzeń na niezaplanowane zadanie.
   
   Nawet jeśli mamy bufor na takie sytuacje, to bywa on za mały lub jest zużyty przez inne wrzutki. Wtedy taka wymiana może być najlepszym rozwiązaniem. Zaznaczamy tu jednak, że nie mówimy tu o nagminnych wymianach i sytuacji, że na 10 zaplanowanych tasków 9-10 podlega wymianie na inne.
   
   Dodatkowo pamiętajmy tu o podatku za “context switching, czyli za zmianę kontekstu. Jest on nieunikniony, gdyż musimy zastopować to, co obecnie robimy, przeanalizować sytuację i podjąć decyzję co robimy dalej. To nasz kosztuje, bo tracimy nie tylko kontekst, ale i czas. 

5. Rozważ przerwanie Sprintu 
   Jest to rzadko spotykane rozwiązanie, natomiast nadal możliwe i przewidziane też przez twórców Scruma. Sugerowane jest wtedy, gdy zmiana, która przychodzi do zespołu, powoduje, że Cel Sprintu przestaje mieć sens lub dużo większy sens ma zrealizowanie tej wrzutki. Jest ona tak pilna i na tyle ważna, że należy rzucić wszystko, co aktualnie robimy i zająć się nią. 
   
   Tego typu sytuacje występują raczej rzadko, sami może widzieliśmy je może 2-3 razy w życiu.
   
   Na jednym ze szkoleń, Jeff Sutherland, podzielił się zasadą, zgodnie z którą, gdy następuje przepełnienie buforu na nieprzewidziane zadania, a interesariusze upierają się przy podjęciu kolejnej wrzutki, to następuje przerwanie Sprintu i odbywa się to w widowiskowy sposób. Chodzi o to, aby cała firma, włącznie z zarządem, dowiedziała się, że z powodu tej i tej wrzutki cały Sprint został przerwany, jego Cel nie zostanie zrealizowany, a my zajmujemy się innym tematem.
   
   Jest to nie tylko bardzo transparentne działanie, ale stanowi także pewien rodzaj zabezpieczenia i wytłumaczenie, dlaczego Zespół nie realizuje kolejnych etapów rozwoju produktu, tylko zajmuje się czymś innym. Dzięki temu też, osoba, która tę wrzutkę dostarcza, ma świadomość, że cała organizacja się o tym dowie i oceni czy było zasadne upieranie się przy realizacji jego zadania.

Na koniec mamy jeszcze dwie uwagi dotyczące wrzutek. Po pierwsze radzenie sobie z problemem wrzutek jest pracą na wielu frontach dla całego zespołu. Dlatego świadomie unikaliśmy mówienia, do kogo adresujemy te porady, bo często dotyczą całego Zespołu Scrumowego.

Po drugie, jeśli w organizacji wrzutki są standardem i trudno cokolwiek zaplanować, to może warto rozważyć rezygnację ze Scruma i znalezienie innego sposobu pracy. Scrum rzeczywiście zakłada pewną elastyczność, ale też to, że to, co robimy, jest w jakimś stopniu pod naszą kontrolą.

Podsumowując temat radzenia sobie z wrzutkami w Scrumie, to wypróbujcie krótsze Sprinty, albo planujcie bufor czasowy, który będzie przeznaczony na niezaplanowane zadania. Warto też policzyć koszt opóźnienia realizacji Celu Sprintu lub wrzutki oraz pomyśleć nad wymianą 1:1 z wcześniej zaplanowanym elementem. Jeżeli żadna z powyższych opcji nie wystarcza, wtedy Product Owner może przerwać sprint. 

Ciekawi nas jak Ty lub Twój zespół radzi sobie z wrzutkami? Macie do czynienia z nimi często? Jak do nich podchodzicie? 

Dodatkowe materiały

• Zarządzanie utrzymaniem w Agile

Transkrypcja podcastu „Jak radzić sobie z wrzutkami w Scrumie?”

Jacek: Bardzo dobrze pamiętam historię, która wydarzyła się no, na pewno z 10 lat temu, kiedy pracowałem jako Scrum Master w świeżo wystartowanym zespole. Mieliśmy w tym zespole Product Ownera, osobę z biznesu, z którą generalnie bardzo dobrze się nam współpracowało. Pamiętam dzień, w którym ten Product Owner przyszedł do zespołu z taką dosyć dużą potrzebą, żebyśmy zestawili to co aktualnie robimy i żebyśmy zrobili jakieś tam konkretne ficzer, jakąś zmianę w produkcie, która jest, która była wydawało się rzecz, istotna na tamten moment. Cała długa historia rozmowy z Product Ownerem powinna się tutaj pojawić na zasadzie – Czy na pewno musimy to robić? Czy na pewno to jest ważne? I dzisiejszy odcinek będzie właśnie o tym, jak radzić sobie z wrzutkami w Scrumie.

Kuba: Przy czym dodefiniujemy, co to znaczy wrzutka. Mamy tu na myśli nieplanowaną pracę, która pojawia się w trakcie sprintu, ale nie są to rzeczy krytyczne, związane z wszelkiego rodzaju utrzymaniem, stabilnością, opieką rozwiązania, które już funkcjonuje na przykład produkcyjnie. Więc wrzutką dla nas w ramach tego odcinka nie są awarie krytyczne, błędy, czy jakiś taki techniczny maintenance, techniczne utrzymanie. Mamy tu na myśli tylko te rzeczy, o których właśnie Jacek w powiedział. Czyli czy to Product Owner, czy interesariusze, czy ktoś spoza zespołu przychodzi z pilną potrzebą rzucenia wszystkiego, albo do tego, co robimy, dołożenia jeszcze jakiegoś elementu, kawałka funkcjonalności, jakiegoś zadania, kawałka zakresu, którego do tej pory nie przewidywaliśmy. I cechą tej wrzutki jest to, że jest ona pilna, czyli niekoniecznie ląduje w Backlogu Produktu, tylko jest oczekiwanie, że będzie zrealizowana as soon as asap.

Jacek: I o obsłudze wrzutek możemy pomyśleć na zasadzie pewnych skrajności. Czyli z jednej strony, przyjmowanie wszystkiego jak leci, no jest oczywiście złe. Na takiej zasadzie, że z jakiegoś powodu mamy konkretny cel sprintu, z jakiegoś powodu mamy prognozę zakresu do zrealizowania. Gdzieś tam z tyłu głowy mamy jakiś cel produktu. Tak więc sytuacja, w której byśmy ciągle reagowali na wrzutki na zasadzie – Dobrze robimy. Dobrze bierzemy. No to oczywiście jest to rozwiązanie, które w jakimś sensie sabotuje nam wcześniejsze ustalenia i dążenia do jakichś konkretnych przyrostów produktu.

Kuba: Ale absolutne odrzucanie jakiejkolwiek wrzutki też może być przesadzone. Czyli takie zasłonięcie się tym, że mamy Scrum, że mamy sprint, że mamy zaplanowany cel sprintu i to powoduje, że już absolutnie nie możemy tknąć żadnej innej pracy. Po pierwsze, ściśle z samą definicją Scruma też nie do końca jest zgodne, ale na pewno jest przede wszystkim bardzo niepragmatyczne. Czyli jak rozmawiam z zarządzającymi firmami, na przykład jakiś prezes się żali, że biznes im się wali, pali, coś tam jest pilnego do zrobienia, a Product Owner mówi, że oni teraz mają Scrum i od teraz już w ogóle nie jest możliwe zrobienie czegokolwiek spoza planu. No to absolutnie słuszne jest pytanie, to gdzie tu jest w ogóle ta cała zwinność i reagowanie na zmiany, zamiast podążania za panem. No bo w tym sensie taki sztywny Scrum, sztywny sprint może stać się właśnie takim podążaniem za pierwotnym planem i kompletne ignorowanie potrzeby zmiany.

Jacek: I w dzisiejszym odcinku będziemy się zastanawiać właśnie, jak nie popaść w żadną z tych skrajności. I uważamy, że kluczową umiejętnością zespołu jest zdolność do oceny konkretnej wrzutki i podjęcie merytorycznej dyskusji z interesariuszami, która może się skończyć albo decyzją, ok ma sens i faktycznie powinniśmy się może tym tematem zająć. Albo druga strona, czyli wygląda na to, że to może poczekać i najprawdopodobniej nic strasznego się nie stanie.

Kuba: Natomiast jest fragment, którego nie poruszymy w tym odcinku – czyli podejście systemowe. Wrzutki, zwłaszcza powtarzające się wrzutki, zwłaszcza takie wrzutki, które powodują, że w zasadzie nic nie da się zrobić, mogą być objawem jakiegoś większego problemu w całym systemie, w całej organizacji, w jej kulturze, jakichś może zasadach funkcjonowania. Tych kwestii w ramach tego odcinka nie poruszymy, tylko w ramach tego, co teraz mówię zaznaczę, że jeśli te problemy z wrzutkami są naprawdę rozwalające wszystko to co robi zespół, czy cała grupa zespołów, to być może jest to jakiś inny temat, problem całej organizacji systemowy. Tam może być dużo różnych powodów, dużo różnych wątków. Coś, co wymaga głębokiej analizy i głębokiego tam gdzieś usprawnienia. Natomiast w tym nagraniu tego nie tkniemy. Czyli mimo wszystko opowiemy o tym, jak sobie radzić z wrzutkami w sytuacji, gdy one się zdarzają, ale nie są jakimś dramatem, czy nie są czymś, co w zasadzie można w ciemno liczyć, że zawsze będzie i nic nie jesteśmy w stanie zrealizować. Czyli systemowe problemy z wrzutkami to jest coś, co jest poza zakresem tego, o czym za chwilę będziemy wspominać. 

Kuba: Dobra to po tych wszystkich wstępach przejdźmy do tego, jak faktycznie można sobie poradzić z wrzutkami – rzeczami, które są nieplanowane i przychodzą nam do sprintu w trakcie jego trwania. 

Jacek: Po pierwsze warto spróbować krótszych sprintów. Czyli jest to takie rozwiązanie, w którym tak naprawdę nie będziemy tej wrzutki w jakikolwiek sposób obsługiwać, a raczej zaoferujemy naszym interesariuszom czy klientom, po prostu trochę większą responsywność naszego procesu. Czyli wyobraźmy sobie, że pracujemy w sprincie dwutygodniowym. Wystartowaliśmy go w poniedziałek, no i w środę pojawia się jakaś konkretna osoba, no i przekonuje nas, że coś jest pilne i że coś trzeba zrobić. No i że powinniśmy co najmniej rozważyć podjęcie jakiejś dodatkowej pracy. No więc gdyby pójść strategią przyjdź do nas na kolejne planowanie, no to tak naprawdę ta osoba musi czekać półtora tygodnia, żeby ten temat został przez zespół potencjalnie podjęty. Natomiast gdybyśmy pracowali w sprincie tygodniowym i konkretna osoba do nas przychodzi, znowu startujemy w poniedziałek, osoba przychodzi w środę, no to tak naprawdę kolejna szansa zespołu, taka powiedzmy sobie wynikająca wprost z frameworka na zaplanowanie prac, to jest kolejny poniedziałek. Więc ta osoba tak naprawdę czeka tylko trzy dni pracy, a nie półtora tygodnia. Tak więc jest to taka dosyć prosta metoda, czy dosyć prosty patent na to, żeby po prostu zwiększyć częstotliwość tych sesji planistycznych. Przez co ten – nazwijmy to pociąg zespołowy – odjeżdża częściej. I częściej mamy możliwość zmiany prognozy zakresu, którą planujemy na sprint.

Kuba: Dla niektórych ta porada może wydawać się oczywista, a inni w ogóle mogli jej nie rozważać. Ci, co nie rozważają tego mogą czasem wpadać w pułapkę takiego mainstreamowego podejścia do Scruma. Częścią mainstreamowego podejścia do Scruma dla mnie jest dwutygodniowy sprint. Czyli sprint musi mieć dwa tygodnie. Po pierwsze, nie jest zgodne ze Scrumem, to jest na pewno pewna norma. Jeśli myślę o Scrumowych Zespołach w różnych organizacjach, to one najczęściej mają te dwutygodniowe sprinty. Ale tutaj akurat w kontekście wrzutek, jak o tym mówimy, to jest ten przypadek, że być może częstsze to okienko planistyczne, też krótszy horyzont, takiego troszkę zabetonowania, czy takiego może zamknięcia tych naszych planów. Jeśli to okienko jest częściej, to tak jak Jacek mówi, jest też być może mniejszy stres wynikający z tego, że pojawia się jakaś wrzutka i trzeba ją wprowadzić. W przypadku tych krótszych sprintów, taka rada taka trochę dodatkowa, wspierająca to, co mówimy. To też jest częściej prawdopodobnie ten proces refinementowy. Czy te okienka planistyczne to jest jedno, a dwa, że być może jest też więcej okazji do częstszego refinemenetu. Zespoły refinementy sobie rozwiązują na różne sposoby. No ale zespoły, które mają tygodniowy sprint, prawdopodobnie te refinementy też mają dosyć gęsto, dosyć często. Być może też ta okazja do tego, żeby porozmawiać też się pojawia częściej. Więc tutaj nie wpadamy w pułapkę takiej normy, rutyny. I zastanówmy się, czy te krótsze sprinty nie spowodują, że nie tyle rozwiążemy problem wrzutek, tylko po prostu te wrzutki nie będą na tyle pilne, że będą mogły poczekać na przykład parę dni. Bo najpóźniej za parę dni będzie kolejna okazja do tego, żeby rozpocząć pewną pracę. 

Kuba: Druga porada to zaplanuj bufor. Jeśli nasze sprinty od czasu do czasu miewają wrzutki, jeśli taki jest nasz produkt, jeśli takie jest nasze otoczenie i spodziewamy się, że te wrzutki będą, no to tutaj takie rozwiązanie jakby pośrednie radzenia sobie z wrzutkami, to po prostu sytuacja, w której nie jesteśmy zaplanowani na sto procent. Zostawiamy sobie trochę przestrzeni czasowej na sytuacje nieprzewidziane. No i te sytuacje nieprzewidziane to mogą być między innymi wrzutki. Więc fakt, że się pojawia w środku sprintu wrzutka, nie powoduje między innymi na przykład zawalenia celu sprintu, albo nie powoduje, że absolutnie nie jesteśmy w stanie sobie już poradzić i się nie wyrabiamy, jest tragedia. Tylko raczej czekaliśmy. Mamy przygotowane miejsce na tę wrzutkę. Oczywiście musimy ją rozważyć, czy ma ją zrobić? Ale przede wszystkim nie ma tych dramatycznych konsekwencji wrzutek, czyli całkowite rozwalenie planu, rozwalanie też częściowo rozgrzebane roboty, bo musimy się szybko przełączyć na jakieś inne zadanie.

Jacek: Wielkość bufora, o którym Kuba mówi, warto go sobie zbudować na podstawie danych historycznych. Czyli w sytuacji, w której wrzutki co jakiś czas się pojawiają w zespole, no to wystarczy je albo policzyć, na zasadzie ile ich było. Albo można spojrzeć na to, jak duże one były, czy ile czasu zajęły zespołowi. No i po prostu ten bufor wtedy nie będzie ani za mały, ani za duży, po prostu będzie uwzględniał to, z jaką intensywnością takich wrzutek możemy się spotykać. Generalnie uważam, że warto jednak szukać danych i liczb i na tej podstawie podejmować decyzje. Bo w przypadku bufora wielokrotnie słyszałem pytania, jak duży powinien być ten bufor. Moją naturalną odpowiedzią jest – Użyjcie danych historycznych. Natomiast jeśli nie ma tych danych historycznych, no to po prostu przyjąłbym jakąś wielkość i po prostu zobaczył, czy to jest wystarczające, czy za duże, czy za małe. No i po prostu dopasowywał to ze sprintu na sprint.

Jacek: Kolejną radą, którą przygotowaliśmy to rada – policz koszt opóźnienia. Wielokrotnie, kiedy pojawia się osoba z jakąś konkretną wrzutką dla zespołu, najczęściej używa argumentów w stylu, że musimy to zrobić teraz. Dlatego ta osoba teraz przyszła, a nie na przykład czeka na kolejne planowanie. I to, co proponujemy, to podejście, w którym faktycznie zastanawiamy się, czy opóźnienie realizacji tego zadania będzie nas kosztować. Jeśli będzie nas kosztować, to ile będzie nas kosztować. Przykładowo wyobraźmy sobie, że rozwijamy jakąś aplikację e-commerce’ową. No i powiedzmy przestała działać możliwość udzielania kredytu osobom, które chcą kupić na naszej stronie. Żeby teraz wyciągnąć z tej sytuacji jakieś konkretne informacje, no to warto byłoby się zastanowić, jak dużo pieniędzy firma straci w momencie, kiedy przez na przykład trzy dni nie będziemy w stanie tych rat udzielać. I teraz warto byłoby pod tą potencjalną stratę zestawić sobie z tym, że mamy w sprincie zaplanowane jakieś inne elementy, no i niezrobienie tych elementów, które były pierwotnie zaplanowane, z jakim kosztem to się wiąże. Czyli spróbować tak naprawdę zważyć, co się stanie i ile nas to będzie kosztować, jeżeli konkretną wrzutkę zrealizujemy później. 

Kuba: I możecie to usłyszeć już nawet w tym, jak Jacek o tym mówi. Że to jest metoda bardzo taka analityczna, bardzo taka rozważna. My tutaj nie decydujemy, czy ten, kto przychodzi z wrzutką ma rację, czy my mamy rację, że ją chcemy odrzucić. Bo to najczęściej jest taka domyślna postawa, tylko raczej rozważamy alternatywy. W scenariuszu, w którym my opóźniamy trochę nasze rozwiązanie i ono będzie później na rynku, później będzie zarabiać, to stracimy jakąś przewidywaną kwotę, czy może nie zarobimy na jakichś oszczędnościach. No i w scenariuszu B mamy tę jakąś pilną potrzebę, ile zyska firma, jeśli ją szybko zrobimy. Zrobimy ją kilka dni wcześniej, bo tak naprawdę to też nie jest kwestia – zrobimy, nie zrobimy – tylko zrobimy ją wcześniej lub później. No i co się stanie w tym scenariuszu, że jednak ją odłożymy i przez jakiś czas to będzie nie funkcjonowało. No i sytuacje są różne. Tutaj warto naprawdę docenić tą mnogość możliwych scenariuszy. Jakaś drobna pierdoła, kilka dni roboczych całego zespołu, może czasami robić gigantyczny wynik, i jednak ważniejsze będzie zareagowanie na to. Porzucenie pierwotnych planów i zrealizowanie tej wrzutki. Tak w ogóle liczenia kosztu opóźnienia, to jest bardzo analityczna metoda. Byłem na warsztatach u Donalda Reindertsena i mamy tam w ogóle bilans spółki jakieś analizowaliśmy. Jak się zmieni wynik finansowy wieloletni przez robienie lub nierobienia jakiejś alternatywy? Ale ja myślę, że ten sposób myślenia można też w dużym stopniu uprościć i po prostu rozważyć sobie ile się zarabia na opcji bez wrzutki, ile się zarobi na opcji z wrzutką. Porównać te sytuacje. I troszkę upraszczając, może troszkę na chłopski rozum, ale mimo wszystko nadal trzymając się pewnych konkretów, pewnych danych, być może przenieść rozmowę też z emocji, pilności na perspektywę – Dobra. Coś stracimy na pewno. To teraz stracimy jak najmniej. – I zobaczmy, w którym scenariuszu tracimy jak najmniej. Oczywiście wszystko to, co mówimy zakłada, że jednak mamy miary. Mamy to wszystko policzone. Mamy takie powiedzmy rzetelne ujęcie tego i wszyscy wierzymy w te liczby, a nie bywałem i widziałem też takie zjawisko, że tak naprawdę każdy wymyślał swoje liczby. One były niepoparte w niczym. No i wygrywał ten, kto wymyślił wyższą liczbę, zupełnie bez konsekwencji. No to w tym scenariuszu ta porada nie zadziała.

Jacek: Przypomniałem sobie zabawę z córką. Jak była trochę młodsza. Tato powiedz liczbę. Ja mówiłem 17, ona mówiła 19. Wygrałam. 

Kuba: To nie może tak wyglądać. Dobra czwarta porada. Jeśli te wszystkie elementy wcześniejsze rozważaliśmy. Czyli mamy pewien bufor, mamy policzoną wrzutkę, że warto ją faktycznie zrealizować. To nasza czwarta rada – wymieniaj jeden za jeden. Czyli w tej radzie mamy na myśli to, że jeśli pojawia się wrzutka, to bądźmy OK z tym. Bądźmy na to gotowi. Miejmy taką zasadę w zespole, że jeśli coś nowego wchodzi do sprintu, to my z tego sprintu coś adekwatnego, analogicznego zabieramy. Czyli niekoniecznie przyjmujmy założenie, że dajmy więcej, wytrzymają – tylko raczej koncepcje. Czy jest coś, z czego możemy zrezygnować? Czy jest coś, co możemy zapauzować? Może w najgorszym razie porzucić, żeby pojawiła się przestrzeń na to, żeby tę wrzutkę zrealizować. Co prawda chwilę temu mówiliśmy o buforze, ale to też jest tak, że czasami ten bufor jest za mały, czasami jest może już zużyty, może już jest też troszkę za późno, nie użyjemy go w tej całej wielkości. Więc jeśli jednak ta wrzutka się pojawia, to zdrową zasadą, którą rekomenduję jest to, żeby podejść do założenia, że zrobimy to, ale kosztem czegoś. Czyli to nie jest bezkosztowe popychanie jeszcze kolejnych elementów.

Jacek: Warto też powiedzieć, że mamy na myśli jednak nadal okazjonalne takie wymiany, no bo w skrajnym przypadku ktoś może powiedzieć, że no skoro mogę wymienić jeden za jeden, macie zaplanowane, prognozowane zrobienie dziesięciu elementów, to ja wszystkie te 10 chcę wymienić. Więc oczywiście to jest skrajny przypadek, którego tutaj nie rozważamy. Natomiast nawet w tym takim popularnym modelu, czy przypadku, w którym po prostu ktoś przychodzi z jakimś jednym tematem, no i my szukamy alternatywnego, w sensie adekwatnego pod względem wielkości tematu, który mamy już zaplanowany. No to nadal powinniśmy pamiętać o tym, że to jest taki nazwijmy to – podatek związany z przyłączeniem kontekstu. Czyli sam ten proces wymiany, on już nas kosztuje. Bo ktoś do nas przychodzi z tematem. My musimy zapauzować prace, w ogóle poddać pod analizę, z czym przychodzi, zastanowić się. Czyli to wszystko, co mówiliśmy wcześniej. Na przykład liczymy sobie cost of delay. Liczymy, czy po prostu rozmawiamy sobie o tym. Decydujemy się na wymianę. Musimy znaleźć element, który chcemy wymienić. No i rozpocząć pracę nad nowym elementem. W tych wszystkich punktach, o których mówię, my tak naprawdę tracimy, czas tracimy kontekst. To nas kosztuje. Więc warto tutaj pamiętać o tym, że to nie jest bezkosztowe. Więc ta wymiana jeden za jeden brzmi tak bardzo, że w sumie jest równo. Natomiast cały ten proces, on też ma swój koszt i warto po prostu o tym pamiętać. 

Jacek:  Ostatnie rozwiązanie, które chcemy opowiedzieć brzmi – rozważ przerwanie sprintu. Jest to rzadko spotykane rozwiązanie, natomiast nadal możliwe i przewidziane też przez twórców Scruma. Polega ono na tym, że jeżeli zmiana, która przychodzi do zespołu, powoduje, że cel sprintu przestaje mieć tak naprawdę sens. Czyli coś tak dużego dostajemy do zespołu, że właściwie już wiemy, że cel sprintu jest nie do zrealizowania, no to mamy taką możliwość, żeby sprint przerwać. 

Kuba: Ja bym może nawet lekko skorygował to co powiedziałeś, że nie tyle cel sprintu nie ma sensu, tylko coś innego ma sens jeszcze większy. Czyli ta wrzutka prawdopodobnie jest tak pilna, tak ważna. Cały los firmy zależy od tego, żeby rzucić wszystko, co robimy i zacząć to robić. No to tutaj nie zapomnijmy właśnie o tym, że Scrum przewiduje taki scenariusz, że możemy przestać robić, to co robimy i po prostu zabrać się za to coś nowego. Skończyć ten poprzedni sprint wcześniej niż planowaliśmy. I w takim razie rzucić wszystkie siły na to co jest tutaj jakąś taką naprawdę ponad normatywną wrzutką. Taką, która uzasadnia wszystko to, co musimy zrobić, żeby to zrobić. 

Jacek: Ja myślę, że dwa, może trzy razy w życiu widziałem przerwanie sprintu. Czyli to jest powiedzmy ta częstotliwość, jak mówimy, że rzadko. Natomiast występuje w przyrodzie. I gdy ostatnio rozmawiałem podczas warsztatów z grupą Scrum Masterów z jednej z firm, to też pojawiały się osoby, które mają takie doświadczenie i ta skala była porównywalna. Na zasadzie jeden, dwa razy w trakcie – nazwijmy to – kariery zwinnej. Więc nic takiego, co by się działo co tydzień, czy raz w miesiącu. 

Kuba: Natomiast jeśli w organizacji do Scruma podchodzimy w miarę poważnie i to przerwanie sprintu faktycznie jest rzadkością, no to jednak gdy go zastosujemy, no to też wszyscy czują powagę sytuacji. No i ten scenariusz, rozważany scenariusz, czy bierzemy wrzutkę, czy przerywamy w związku z tym sprint, po prostu ma swój ma swój kaliber. Pamiętam taką zasadę ze szkolenia Jeffa Sutherlanda, który opowiadał między innymi o takim powiedzmy połączeniu tego, co mówimy z buforem, zaplanowanym buforem, ewentualnym przetrwaniem się tego buforu – przepełnieniem się jego. No to on mocno sugerował taki wzorzec postępowania. Że jeśli bufor się przepełnia, pojawia się kolejna wrzutka, albo pojawia się zrzutka większa niż przewidywany bufor na te wrzutki, no to po prostu mamy taką ogólną firmową zasadę, że w takim razie z automatu upieranie się przy podjęciu tej wrzutki oznacza przerwanie sprintu, a to przerwanie sprintu robimy w bardzo widowiskowy sposób. Czyli cała firma się dowiaduje włącznie z zarządem, że właśnie o to z powodu wrzutki X, cały sprint, cały cel, przerywamy wszystko, porzucamy i będziemy przeskakiwać na tę wrzutkę X. I to jest o tyle istotne, że to jest taki pewnego rodzaju bezpiecznik, że bardzo przejrzyście, w bardzo transparentny sposób, realizujemy pewną wrzutkę. Bo tutaj może tak nie do powiedziane wcześniej jest to, że osoby, które się na taką wrzutkę na przykład upierają, mogą mieć swój prywatny interes, taki organizacyjny, ale jednak swój własny interes w tym, żeby robić to, co one chcą, a nie to, co jest planami rozwojowymi danego produktu. I jeśli tak bardzo chcą bronić swojego interesu, no to muszą być gotowe na to, że cała organizacja oceni to, będzie to widać. Będzie to w bardzo przejrzysty sposób rozważone. Czy faktycznie należało porzucić wszystko, żeby zrealizować tę wrzutkę? No i jeśli to jest coś krytycznego dla biznesu, to wszyscy powiedzą – Świetna decyzja. Super piękna akcja. Dobrze, że to zrobiliście. No ale jeśli ktoś miał nazwijmy to fanaberię, żeby upierać się przy swojej wrzutce, nie zgodził się na to, żeby poczekać jeszcze parę dni na kolejny sprint, no to to też powinno być widoczne, no i być może również ocenione i odpowiednio docenione. 

Kuba: Dobra to wychodząc z porady jeszcze kilka takich uwag, w zasadzie dokładnie dwie uwagi takie o wrzutkach. Pierwsza myśl to jest to, że radzenie sobie z problemem wrzutek jest pracą na wielu frontach dla całego zespołu. I tu bardzo świadomie unikaliśmy mówienia adresata naszych porad, bo tak naprawdę te porady często są dla całego Zespołu Scrumowego. Czyli dla Product Ownera, częściowo dla Scrum Mastera. Również mają w tym wszystkim udział deweloperzy. Więc różne osoby mogą robić różne rzeczy. Z jednej strony Product Owner ma jakąś sieć, czy nić porozumienia z interesariuszami. Scrum Master może trochę edukować tę całą sytuację. Deweloperzy też oczywiście z otwartością z jednej strony, ale również z jakąś efektywnością podchodzą do tego, żeby pewne rzeczy działały, pewne rzeczy były fair względem wszystkich stron. Więc tutaj to, jak radzimy sobie z wrzutkami jest grą zespołową i absolutnie nie możemy zostawić jednej ze stron, albo tylko oczekiwać, że jedna ze stron, czy jedna z części Zespołu Scrumowego, będzie tutaj tamą, albo będzie sobie dawać radę, albo będzie ponosić konsekwencje. 

Jacek: Natomiast jeżeli wrzutek jest bardzo dużo i właściwie występują one cały czas i można odnieść wrażenie, że właściwie nasza praca to cały czas są wrzutki, a nie coś, co można zaplanować, przewidzieć, ubrać w jakieś ramy, to warto rozważyć czy na pewno, albo czy aby na pewno praca w Scrumie to jest najlepsze rozwiązanie. Scrum jednak zakłada, że materia, którą się zajmujemy, jest w jakimś stopniu pod naszą kontrolą. Jak słyszycie, nie wyklucza jakichś tam zmian. Zresztą nie bez powodu mówimy o prognozie zakresu. Natomiast, jeżeli to jest cały czas praca taka ad hoc i reagowanie na wrzutki i to faktycznie ma sens organizacyjny, no to ja bym się zastanowił, czy nie zainspirować się inną metodą pracy, a niekoniecznie upierać się, że chcemy pracować w Scrumie

Kuba: Podsumowując treść tego odcinka. Jak można sobie poradzić z wrzutkami? Wrzutki są mniejszym problemem, jeśli stosujemy krótsze sprinty. Można też na nie zaplanować bufor czasowy, więc ich pojawienie się nie powoduje zawalenia całego planu pracy. 

Jacek: Jeśli pojawi się wrzutka, warto policzyć koszt opóźnienia i gdy już bierzesz ją do sprintu wymień 1:1 z wcześniej zaplanowanym elementem. Jeżeli żadna z powyższych opcji nie wystarcza, wtedy Product Owner może przerwać sprint. 

Kuba: Na moment nagrania mam dosłownie dwa ostatnie miejsca na warsztaty z case studies Prawdziwe Przypadki Scrumowe, które odbędą się 16-17 maja w Warszawie. Reszta grupy już się cieszy i grzeje na to, że będzie fajna praca warsztatowa. Zapraszam. Jeśli jeszcze się wahasz. Zapisy na 202procent.pl/przypadki-scrumowe.

Jacek: Natomiast notatki do tego odcinka, artykuł, transkrypcję oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/86. I to było wszystko na dzisiaj. Dzięki Kuba.

Kuba: Dzięki Jacek. 

Jacek: I do usłyszenia wkrótce.