Blog

W definicji Scruma maksymalna długość sprintu określona jest na jeden miesiąc – pojawia się tam nawet stwierdzenie, że to miesiąc „kalendarzowy” (są jakieś inne?). Minimum nie jest określone, co oznacza, że całkowicie poprawnymi będą sprinty dziewięciodniowe, trzydniowe lub… kilkugodzinne. Tak długo, jak przekroczony nie zostanie limit miesiąca, działamy zgodnie z definicją metody.

Obalamy mity dotyczące długości sprintu

Między bajki należy włożyć opinię, że sprinty muszą mieć długość będącą wielokrotnością całych tygodni. Podobną nieprawdą jest, że minimalna długość to jeden tydzień. Albo że sprinty mogą być wyłącznie tygodniowe, dwutygodniowe lub miesięczne. To, że najczęściej spotykaną obecnie długością iteracji w Scrumie są dwa tygodnie, nie oznacza bynajmniej, że nie może być inaczej. Ba, często musi być inaczej – o czym w dalszej części artykułu.

Jak już rozprawimy się z myśleniem w kategoriach „całych tygodni”, jasnym stanie się, że mitem jest również wymóg, by sprinty zaczynały się w poniedziałki i kończyły w piątki. Jako żywo czterodniowych iteracji tak nie dałoby się robić, a przecież wolno robić czterodniowe sprinty… Jeśli zatem w kontekście jakiejś konkretnej organizacji lub zespołu zaczynanie sprintów w środy ma sens, niech zaczynają się w środy, nie ma w tym niczego „nielegalnego”.

Jak właściwie liczyć te dni…

Czy chodzi o dni robocze? A może kalendarzowe? Takie pytania, całkiem serio, pojawiają się na szkoleniach. A wraz z nimi cały zalew przypadków problematycznych i wątpliwości… „a co z długimi weekendami?”, „a co z okresem bożonarodzeniowym?”.

Tak naprawdę twórcy Scruma nie określili tego wprost, pozostawiając decyzję w gestii użytkowników metody. Jeśli umówimy się na posługiwanie dniami kalendarzowymi, a nie roboczymi, póki będziemy w tym konsekwentni, nie zrobi się bałagan.

Jeśli dla odmiany (co rzadko spotykane, ale zdarza się) będziemy liczyć wyłącznie dni robocze – też będzie dobrze. Przy czym wtedy dość szybko pojawi się pytanie: ile maksymalnie w takim przypadku sprint może trwać – 31 dni, 21 dni, 20 dni czy jeszcze inaczej?

Dlaczego maksymalnie miesiąc?

Najpierw warto uświadomić sobie, skąd się maksymalna długość iteracji w Scrumie wzięła. Czas trwania sprintu wyznacza rytm, w którym przeglądowi (inspekcji) poddany zostanie produkt, jaki wytworzył zespół developerski. Im sprint dłuższy, tym rzadziej będzie można takiej inspekcji dokonywać, a tym samym mniej będzie okazji, by zmienić kierunek działania. Jeśli uświadomimy sobie, że miesięczny sprint to tylko dwanaście okazji w roku, by dostosować plany do ciągle zmieniających się potrzeb i oczekiwań biznesu, jasnym stanie się, że to niewiele.

Inaczej mówiąc iteracje, w jakich pracujemy, muszą być na tyle krótkie, by realnie dać nam szansę na reagowanie na zmienność otoczenia. W przeciwnym razie przestaniemy być dość zwinni, by za tymi zmianami nadążyć. Pojawi się presja na przewidywanie przyszłych potrzeb, a praca układana będzie pod takie domniemania… i z empiryzmu nici, zostanie on zastąpiony starym, predykcyjnym podejściem.

Jest i drugi powód czemu tylko miesiąc. Scrum wymaga, by przynajmniej raz na koniec iteracji powstał działający produkt, którego można potencjalnie użyć (czyli taki, który jest używalny, ale o tym, czy rzeczywiście go użyjemy bez dalszych zmian, zdecydować musi Product Owner).

Zdolność tworzenia działających rozwiązań dających wymierne korzyści jest kluczowa dla każdej firmy i każdego biznesu. Jeśli organizacja nie jest w stanie chociaż dwanaście razy do roku wytworzyć działającego produktu, to coś jest mocno nie w porządku, nieprawdaż? A cóż dopiero można by powiedzieć o organizacji, która za cel stawia sobie działający produkt tylko raz na kwartał…

Dlatego sposób liczenia tych dni ma małe znaczenie. Dużo ważniejsze jest, czy rzeczywiście przynajmniej dwanaście razy do roku zobaczymy działający produkt i zdecydujemy, co robić z nim dalej.

Określenie jaka powinna być długość sprintu

Kluczowe są trzy czynniki: zmienność i wynikająca z niej presja na dopasowywanie się do zmian, nieprzewidywalność i związane z nią ryzyko podjęcia chybionych decyzji, oraz realne możliwości organizacji (przede wszystkim zespołów developerskich).

Sprint musi być na tyle krótki, by zapewnić adekwatną do potrzeb biznesu zdolność reagowania na zmieniające się potrzeby. Im ta zmienność większa, tym iteracje powinny być krótsze. Podobnie im większa nieprzewidywalność, tym bezpieczniej pracować w krótkich sprintach. To pozwoli zredukować ryzyko, że zrealizowane prace okażą się marnotrawstwem, bo zmieniły się oczekiwania biznesu.

Z drugiej strony sprint musi być na tyle długi, by możliwe było zbudowanie wartościowego, nadającego się do użycia rozwiązania. Nieuchronnie uwzględnić w tym trzeba obecny stan praktyk developerskich i technologii, ilość zależności, standardy i formalne wymogi, jakie trzeba będzie spełnić.

Skalowanie i zależności

W dużych organizacjach pojawia się konieczność synchronizacji między zespołami, zwłaszcza jeśli budują one produkty, które są ze sobą blisko powiązane. Swoboda wyboru długości sprintu jest w tej sytuacji dużo mniejsza.

A jeśli jeden produkt rozwija wiele zespołów jednocześnie, wtedy często tej swobody nie ma prawie wcale (tu odsyłam zainteresowanych do metod opisujących jak skalować Scruma).

Kto ustala długość sprintów?

Dobre pytanie, na które twórcy Scruma nie odpowiadają, bo odpowiedź zależeć będzie od kontekstu produktu i organizacji, która go buduje. Prostą, acz niekoniecznie zawsze poprawną odpowiedzą może być: decyduje o tym zespół scrumowy, uwzględniając wszystkie czynniki opisane powyżej i biorąc pod uwagę konieczność synchronizacji się z otoczeniem.

Inaczej zatem wyglądać to będzie w przypadku jednego zespołu pracującego dla Product Ownera, który jest zarazem głównym interesariuszem, a inaczej w organizacji skalującej Agile (Scruma), w której konieczna jest koordynacja wysiłków kilkunastu zespołów nad rozwojem jednego produktu.

Zmiana długości sprintu

Jeśli już jest dokonywana, to na stałe. Lub raczej powinienem napisać „na stałe” – bo wszak można ją kiedyś w przyszłości zmienić ponownie. Chodzi o to, by nie wydłużać lub skracać iteracji co chwilę, wtedy bowiem niemożliwa stanie się empiryczna kontrola procesu.

Ta stała długość ma wiele celów. Nadaje rytm inspekcji i adaptacji, umożliwiając empiryczne działanie. Daje możliwość zauważenia trendów (na przykład tego, że działamy szybciej lub wolniej), umożliwia Product Ownerowi robienie planów wydań, przewidywanie na kiedy mniej więcej może być gotowa pożądana lista funkcjonalności…

Stałe granice sprintów zmuszają do poszukiwania efektywnych sposobów organizacji pracy, stosowania skutecznych praktyk i narzędzi – są więc mechanizmem stymulującym rozwój, zapobiegają też ukrywaniu problemu nieefektywnego działania.

Nieprzekraczalna długość sprintu (czyli efekt stałej długości sprintu) jest też jednym ze źródeł presji, dzięki której samoorganizacja może w ogóle zafunkcjonować. Ponieważ do zrobienia jest dużo, a czas jest ograniczony, nie można go marnować.