Święta za pasem, #białko odpoczywa po intensywnej końcówce roku i zbiera siły na kolejny. Tymczasem jest wiele miejsc, w których praca trwa nieprzerwanie, iteracja po iteracji. I wszędzie tam pojawi się problem świątecznego Sprintu.
Polska specyfika świąt
Nie lubię odwoływać się do „lokalnej specyfiki”, bo zwykle stanowi to wymówkę do robienia wyłomów w sprawdzonych zasadach. Zgodnie z Broken Window Theory, jeden wyłom rozpoczyna szybko postępującą degradację całego systemu.
Nie da się jednak ukryć, że nasza lokalna specyfika dni wolnych ma ogromne znaczenie w kontekście planowania naszej pracy. Mamy przecież Majówki i coroczne Boże Ciało wypadające w czwartek. Poza tym okres między Bożym Narodzeniem, a Nowym Rokiem też jest zauważalnie „wolniejszy”. Te ostatnie spowolnienie w niektórych firmach trwa aż do święta Trzech Króli.
Bożonarodzeniowe „międzyświęcie” i Majówka to dwie najczęstsze okazje, podczas których pojawia się pomysł wydłużenia Sprintu. Bo skoro i tak wszyscy znikną na kilka dni, to możemy kolejne kilka dni dołożyć, prawda?
Stała długość Sprintu
Stała długość Sprintu pozwala nam być bardziej przewidywalnymi. Szczególnie zależy na tym Product Ownerowi, który często patrzy na bardziej odległy horyzont czasowy. Nic w tym dziwnego, komunikując się z interesariuszami i resztą organizacji często rozmawia o terminach.
Stała długość Sprintu upraszcza obliczenia i powoduje, ze na wiele pytań możemy odpowiedzieć opierając się tylko na backlogu. Co prawda niektórzy PO budują skomplikowane tabelki z prognozami uwzględniającymi urlopy, dni wolne i fazy księżyca, ale doświadczenie pokazuje, że nie są one bardziej dokładne niż proste wyliczenia oparte o Velocity.
W tym miejscu warto przypomnieć, że jakiekolwiek manipulacje długością Sprintu przez permanentne nadgodziny również są naganne. Wspominaliśmy już o tym w tekście „Nadgodziny w Scrum„. Priorytetem dla nas powinno być stabilne, zrównoważone tempo i jak najwyższa przewidywalność naszych działań, a nie okazyjne zrywy. Te i tak zwykle kończą się powiększaniem długu technologicznego.
Pamiętajmy też, że jeśli na projekcie mamy wiele zespołów, to kadencja musi być jednostajna. Znaczy to tyle, że długości Sprintów zespołów pracujących nad jednym produktem muszą być swoimi wielokrotnościami. Więcej na ten temat mówiliśmy na naszym kanale na YouTube przy okazji omawiania idealnej długości Sprintu.
Co więc zrobić z dniami ustawowo wolnymi od pracy?
Sytuacja bez wyjścia
Jeżeli nasz Sprint trwa dwa tygodnie, a jakieś święto wypada w czwartek i mamy pewność, że większość osób weźmie wolne w piątek, to nasza teoretyczna prędkość (Velocity) zmniejszy się o ponad 20%. Poza samym efektem czasowym należy też dodać brak doświadczenia w Sprintach trwających krócej niż dziesięć dni roboczych.
Wydłużenie naszego Sprintu o dwa dni spowoduje, że nie skończymy go w piątek, ale we wtorek. A kolejny zaczniemy w środę. Nie ma w tym nic złego, o ile nie przyzwyczailiśmy się już do rytmu poniedziałek-piątek. Niestety, jeśli nie wszyscy biorą dodatkowy dzień wolnego, to dla niektórych Sprint będzie dłuższy niż zwykle, co już na pewno zaburzy nasze statystki za tę iterację.
Z kolei, jeśli nie wydłużymy Sprintu, to będzie on efektywnie krótszy, co też wpłynie na ilość pracy, jaką zrealizujemy. Co prawda jest to taka sama sytuacja, jak wzięcie urlopu przez kilka osób z naszego zespołu, ale ten przypadek też miesza nam w statystykach.
Nie ma dobrego rozwiązania tej sytuacji, niezależnie od tego, na co się zdecydujemy. Albo zaburzymy capacity naszego zespołu, albo naruszymy zasadę równej długości Sprintów.
Rekomendacja #białko
W naszej praktyce zawodowej najczęściej spotykaliśmy się z sytuacją, w której Sprinty rozpoczynały się w poniedziałek, a kończyły w piątek, niezależnie od okoliczności i dni wolnych po drodze. Czy jest to zgodne ze Scrumem? Na pewno można to obronić, twierdząc, że „dwa tygodnie” to stała długość Sprintu. Podobnie zresztą można powiedzieć o „dziesięciu dniach roboczych”, jeśli ktoś decyduje się na przesuwanie zakończenia iteracji.
W sytuacjach bez wyjścia prostota zawsze wygrywa. Wydaje się, że skoro Daily Scrum zawsze powinien odbywać się w tym samym miejscu i o tej samej porze, tak i samo „serce Scruma” powinno bić w jednostajnym rytmie. I tu wracamy do sedna problemu i powodu, dla którego nie jesteśmy ewangelizatorami Scruma: to, co zadziała w jednej organizacji, niekoniecznie musi sprawdzić się w drugiej.
„Proste rozwiązanie” dla jednego zespołu to Sprinty 10-dniowe, liczone według dni roboczych. Dla innego będzie to uciążliwe i lepiej poradzi on sobie ze Sprintami startującymi w poniedziałek i kończącymi się w piątek. Trzeba przeanalizować wszystkie aspekty i wybrać jedno rozwiązanie, spójne dla całej organizacji.
Jeżeli zaś chodzi o statystyki i Velocity – nie próbujmy przeliczać wyników specyficznych Sprintów. Po prostu pomińmy je w naszych wyliczeniach.
Zupełnie osobnym problemem jest kwestia „międzyświęcia”, Majówki i innych okresów, w trakcie których biura świecą pustkami. W teorii kolejny Sprint powinien zacząć się od razu po poprzednim, ale w praktyce i tak w tym czasie nie za wiele się dzieje. Dajmy więc wszystkim odpocząć i pozwólmy im zająć się tym, na co mają ochotę.
A najlepiej dajmy im po prostu wolne.
Tym tekstem kończymy rok 2018 i życzymy wszystkim Wesołych Świąt oraz rewelacyjnego roku 2019. Mamy nadzieję, że wkrótce spotkamy się na prowadzonych przez nas szkoleniach Scrum i agile. Do zobaczenia!
