Święta się zbliżają i co bardziej zapobiegliwi właśnie wykorzystują pozostałe dni urlopu, by dzięki sprzyjającym okolicznościom kalendarzowym pojawić się w pracy za 10 do 14 dni. Co jednak, jeśli ci bardziej zapobiegliwi to jakieś 85% zespołu scrumowego? Scrum Guide niewiele w tej kwestii mówi, ale dwie frazy są warte uwagi: czas trwania Sprintu jest ustalany w chwili jego rozpoczęcia i nie może być skracany ani wydłużany oraz najlepiej, jeśli Sprinty mają stałą długość przez cały okres trwania prac. Ograniczenia? A może dodatkowe możliwości?
Młode, dopiero co ukonstytuowane zespoły zazwyczaj starają się jak najściślej przestrzegać wyznaczonych terminów. Z tego powodu nierzadko decydują się na odprawienie ceremonii w bardzo okrojonym składzie, byle tylko nie zakłócić długości sprintów, a jeśli review lub planning wypadają w święto, przekładają ceremonie na pierwszy dzień roboczy przed lub po nim. Jakie kryją się za tym wyborem zagrożenia? Ano choćby takie, że brak całego zespołu to konieczność powtarzania informacji, które mogą ulec zniekształceniom, to brak pełnego komentarza od zespołu dla Product Ownera i interesariuszy w czasie rozmowy o produkcie na review, to zagrożenie rozminięcia się z rzeczywistością na planningu i podejmowania się zrealizowania prac, do których będzie zbyt mało osób lub zbyt mało kompetencji. Co doradzić takim zespołom? Zazwyczaj dobrze sprawdza się delikatne skrócenie lub wydłużenie sprintu tak, by zespół spotkał się na ceremoniach w pierwszym możliwym terminie, gdy jest w pełnym lub niemalże pełnym składzie. A zatem nie patrzymy na datę pierwszego, dostępnego dnia roboczego, ale na liczbę osób, które są w stanie uczestniczyć w ceremoniach. Jeśli okaże się, że dopiero dwa lub trzy dni później jesteśmy w stanie zebrać się całym zespołem, warto się zastanowić, czy takie rozwiązanie nie będzie korzystniejsze od ścisłego przestrzegania wyznaczonych wcześniej terminów.
Część zespołów, które zdążyły już się zaprzyjaźnić z zasadami Scruma i w toku pracy zapewne nagiąć, bądź złamać każdą z nich, podchodzą do tematu świąt w bardziej pragmatyczny sposób. Nie szukają najbliższych, dla większości zespołu wspólnych terminów, tylko od razu przekładają ceremonie o tydzień lub dwa, gdy cała gorączka świąteczno-urlopowa opadnie i wszyscy wrócą do pracy. Oczywiście, w ten sposób z tygodniowego sprintu często robi się iteracja trwająca nawet trzy tygodnie, ale z dobrze określonym celem i backlogiem zespół nadal jest w stanie dowieźć znaczącą wartość dla Product Ownera, a przynajmniej pracuje ze spokojem, nie martwiąc się o okrojony skład osobowy. A co z prędkością zespołu? Większość zespołów traktuje miarę osiągniętą w takim świątecznym sprincie jak miarę dodatkową, obarczoną wieloma zależnościami, którą niekoniecznie należy brać pod uwagę, a jeśli już to pamiętając o nich.
Inną opcją jest pogodzenie się z rzeczywistością i, jeśli przez cały okres świąteczny skład osobowy zespołu waha się pomiędzy jedną i dwiema osobami, nieodpalanie świątecznego sprintu. Zespoły, które decydują się na ten krok, odwołują się do idei slack time’u (przystępnie opisanej przez Pawła Brodzińskiego), wywodzącej się ze świata leanu i Kanbana. W tym „wolnym czasie” nie są tworzone nowe rozwiązania dla klienta, a zespół poświęca swoje ograniczone siły na usprawnienia – automatyzację pewnych rozwiązań, refaktoring kodu, posprzątanie na swoim podwórku, usunięcie jakichś błędów, naukę i poszerzenie swoich umiejętności. Efektem jest dobrze wykorzystany czas i dobre samopoczucie zespołu wynikające ze świadomości, że zostały zrobione rzeczy, które zaprocentują w dalszych sprintach.
Wszystkie podejścia są, moim zdaniem, dobre i mogą się świetnie sprawdzić w zespołach o określonych cechach. Tak naprawdę należy bowiem przede wszystkim pamiętać o podstawowej idei stojącej za sprintem – w określonym czasie chcemy dowieźć klientowi to, co jest dla niego najbardziej wartościowe. Czy z powodu świąt zrobimy to w dłuższej iteracji, czy zrobimy tego mniej, bo w okrojonym składzie, ale dotrzymując niemalże w stu procentach pierwotnych timeboxów – to rzecz drugorzędna. Najważniejsze jest, jak sądzę, by na review klient otrzymał to, co zespół mu obiecał, a jeśli nie możemy mu nic zadeklarować, to może warto poświęcić ten czas właśnie na samorozwój zespołu.