Przerwanie Sprintu to nie jest popularny temat, bo i występuje ono niezwykle rzadko. Jednak są takie sytuacje, w których Przerwanie Sprintu powoduje pewne scrumowe problemy…
Zagadka
Zwykle w okolicach sezonu świątecznego i noworocznego przypominamy tekst o „Świątecznych Sprintach„. Święta już jednak za pasem, ale jeśli ktoś jeszcze go nie zna to zapraszamy do lektury. Tymczasem przedstawiamy małą scrumową zagadkę, która również jest związana z długością Sprintu.
Wyobraźmy sobie, że mamy kilka zespołów pracujących nad jednym produktem. Wygląda to typowo: jeden Product Owner, jeden Product Backlog, kilka Zespołów Scrumowych. Wszystkie zespoły zaczynają i kończą Sprint w tym samym momencie. Co się dzieje w sytuacji, w której Sprint jednego z zespołów zostanie przerwany przez Product Ownera? Czy tracimy tę synchronizację, czy też może robimy coś innego?
Zagadka jest mało „życiowa”, bo w swojej scrummasterskiej i agilecoachowej karierze Przerwanie Sprintu widziałem dwa razy na grubo ponad dekadę obserwowania Zespołów Scrumowych. Ale jednak takie pytania trafiają do nas, więc postanowiłem na nie odpowiedzieć raz na zawsze (czytaj: do następnej zmiany Scrum Guide’a).
Kiedy Przerywamy Sprint?
Zacznijmy od wyjaśnienia, po co w ogóle zotało wymyślone Przerwanie Sprintu i czemu ma ono służyć. Jak dobrze wiecie, Sprint to nie jest mechanizm do „dzielenia projektu na kawałki”, tylko pewien okres w którym chcemy zrobić „coś” wartościowego. Co więcej, chcemy osiągnąć nasz mały cel biznesowy, zwany Celem Sprintu.
Może się zdarzyć, że dany Cel Sprintu się zdezaktualizuje. To znaczy, bieżący Sprint robimy głównie po to, żeby w następny poniedziałek uruchomić pewną promocję. W Backlogu Sprintu znajdują się elementy związane zarówno z tą promocją, jak i inne rzeczy, które robimy w tym samym czasie. Jeśli jednak cały nasz plan na promocję pójdzie w diabły, to czy jest sens w ogóle kontynuować pracę w tym Sprincie? Nie! Wszystkie nasze plany i nasze skupienie było skierowane na tej promocji, więc lepiej jest wyrzucić wszystko, co niepotrzebne do kosza i zaplanować się jeszcze raz.
Przerwanie Sprintu najczęściej jest związane ze zmianą kierunku i jest konsekwencją myśli „nie ma co się na tym skupiać” bądź „nie ma co w ogóle tego już robić”. W takiej sytuacji przeplanowanie działań zespołu. czyli nowe Planowanie Sprintu, jest konieczne.
Gdybyśmy pracowali w trybie ciągłym i nie miałoby żadnego znaczenia co zrobimy teraz, a co w następnym Sprincie – nigdy nie byłoby pretekstu do Przerwania Sprintu. Jeśli nie zbieramy informacji zwrotnej, nie mamy dobrego Sprint Review, nie wdrażamy częściowych rozwiązań, nie badamy zachowań użytkowników w reakcji na nowe funkcjonalności to faktycznie Sprinty nie mają znaczenia.
Ale przyjmijmy jednak, że faktycznie pracujemy scrumowo, a nie tylko „w Sprintach” i zastanówmy się, jakie konsekwencje ma Przerwanie Sprintu.
A co z synchronizacją Sprintów?
Następne akapity dotyczą tylko i wyłącznie teorii i jako takie nie mają wiele wspólnego z codziennym życiem Scrum Mastera i Zespołów Scrumowych. Przejdźmy do doktoryzowania się ze Scruma.
Co do zasady, data startu i końca Sprintu nie musi być taka sama dla wszystkich zespołów pracujących nad jednym Product Backlogiem, bo… nie każdy zespół musi mieć Sprint tej samej długości. Ani Scrum Guide ani Nexus Guide nic nie mówią o tym, że Sprinty poszczególnych zespołów miałyby być takie same. Konsekwencją braku takich zapisów jest więc fakt, że nie ma przymusu synchronizowania kadencji. A skoro tak, to nie muszą one startować w tym samym dniu – no bo i jak, jeżeli jeden zespół ma Sprinty trzytygodniowe, a drugi dwutygodniowe.
Oczywiście, praktyka mówi, że lepiej jest mieć odpowiednie wydarzenia zsynchronizowane. Inkrement, czyli Przyrost powinien być zintegrowany z wszystkimi poprzednimi Inkrementami. To znaczy, że to, co chcemy nazwać Przyrostem musi być zintegrowane jeszcze przed Sprint Review. Ktoś może powiedzieć, że jeśli Sprint Review mamy co chwila, to taka integracja będzie następowała praktycznie cały czas (Continuous Integration)! Jest to pozytywny efekt, bo możemy wtedy zapomnieć o konieczności synchronizacji. Wtedy Sprinty latają jak jest wygodniej zespołom, a nasz produkt jest zintegrowany i gotowy do wdrożenia cały czas.
Tylko zwykle okazuje się, że wygodniej jest mieć wszystkie Wydarzenia zsynchronizowane, bo logistyka, integracja, wdrożenia, kalendarze, dostępność interesariuszy, etc.
Wydaje się, że ma to wiele wspólnego z dojrzałością zespołów, technologicznym przygotowaniem do CI/CD oraz doświadczeniem w tych kwestiach. Wiele organizacji używa przestarzałych technologii bądź ma już systemy napisane w taki sposób, że ekstremalnie trudno byłoby tworzyć przetestowane, zintegrowane Inkrementy częściej niż raz na koniec zsynchronizowanego Sprintu. To niedobrze, ale takie są realia i nie możemy działać życzeniowo, tylko empirycznie.
Rozwiązanie zagadki Przerwania Sprintu
Oczywistym rozwiązaniem problemu różnych kadencji jest takie ich ułożenie, aby wydarzenia spotykały się co jakiś czas. Tzn. jeden zespół niech ma Sprinty tygodniowe, a drugi dwutygodniowe. Niech będą one ułożone tak, że co dwa tygodnie spotykamy się na Review i jakiejś wspólnej części Planowania. To najczęściej spotykane rozwiązanie takiej sytuacji.
Wróćmy do naszej zagadki. Co powinniśmy zrobić, jeżeli Product Owner przerywa Sprint, a nasze zespoły pracują na podstawie jednego Backlogu Produktu? Odpowiedź czysto teoretyczna to: nic. Zespoły dalej mają swoje Sprinty, dalej pracują z jednego Backlogu Produktu, dalej mają jednego Product Ownera. Tylko przestają mieć swoje wydarzenia w tym samym dniu. I teoretycznie nic złego się nie zadzieje.
W praktyce wiemy jednak, że taka destabilizacja kalendarza przyniesie więcej szkody niż pożytku. I w praktyce większość Scrum Masterów decyduje się na inne bluźnierstwo, czyli krótszy bądź dłuższy Sprint tak, aby „wyrównać” kadencje i ponownie zsynchronizować Planowanie i Review. Czy to dobrze? Czy tak powinien działać doświadczony Scrum Master?
Pamiętajmy, że nie pracujemy scrumowo po to, żeby pracować scrumowo, tylko po to, aby uzyskiwać pewne określone korzyści. I to one są ważniejsze niż zgoda ze Scrum Guide. Szczególnie w nowych zespołach. Gdy ktoś pyta mnie „Czy raz na te parę lat, jak już wystąpi taka sytuacja jak Przerwanie Sprintu, możemy zrobić krótszy bądź dłuższy Sprint, żeby wyrównać kadencje?” odpowiadam „Raz na parę lat możemy wszystko.” Najważniejsze jest, żeby odstępstwa nie weszły nam w krew.
Powyższy tekst po raz pierwszy pojawił się, w nieco innej formie, na naszej liście mailingowej jeszcze w 2022 roku. Serdecznie zapraszamy do subskrypcji – raz w tygodniu otrzymasz podobny, przepełniony wiedzą tekst.
