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. Dopóki przekroczony nie zostanie limit miesiąca, działamy zgodnie z definicją metody.

Obalamy mity

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ń. Lub ż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 niepoprawnego.

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 interpretację użytkownikom 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 zostaje produkt, jaki wytwarza Zespół. 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. Rośnie też ryzyko zabrnięcia zbyt daleko w niewłaściwą stronę. 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ń interesariuszy, 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, dla którego to tylko miesiąc. Scrum wymaga, by przynajmniej na koniec iteracji powstał działający produkt, którego można potencjalnie użyć (czyli taki, który jest używalny, ale oczywiście użyty być nie musi, jeśli wciąż nie jest dostatecznie wartościowy dla tych, co będą z niego korzystać). Bez Sprintów prace nad produktem mogłyby się ciągnąć i ciągnąć, bo przecież „już prawie wszystko działa”. Koniec iteracji zmusza do zmierzenia się z twardym pytaniem o to, czy warto kontynuować pracę nad tym, czego zbudować się na razie nie udało.

Zdolność do tworzenia działających rozwiązań, dających wymierne korzyści interesariuszom, jest kluczowa dla każdej firmy. Jeśli organizacja nie jest w stanie przynajmniej 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łaby sobie uzyskanie działającego produktu 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 w regularnych odstępach zobaczymy działający produkt i zdecydujemy, co robić z nim dalej.

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

Kluczowe są trzy czynniki:

1. zmienność i wynikająca z niej presja na dopasowywanie się do zmian,
2. nieprzewidywalność i związane z nią ryzyko podjęcia chybionych decyzji,
3. realne możliwości organizacji (przede wszystkim Developerów w Zespołach).

Sprint musi być na tyle krótki, by zapewnić zdolność reagowania na zmieniające się potrzeby interesariuszy. 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 użytkowników i klientów.

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ę często (niestety!) 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.

W szczególności, jeśli jeden produkt rozwija wiele Zespołów, 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?

To 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ą odpowiedzią, może być: decyduje o tym Zespół Scrum, 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ć, że na stałe, o ile nie ujawni się w przyszłości przyczyna, by zmienić ją 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 sporządzanie prognoz dat realizacji poszczególnych zmian w produkcie itd.

Co ciekawe, jest też mechanizmem ograniczenia ilości pracy w toku (co kojarzy się bardziej z Kanbanem, niż ze Scrumem): stały skład Zespołu w określonym czasie krótkiej iteracji nie może podjąć się realizacji zbyt wielu rzeczy naraz, przez co szansa na ich szybkie ukończenie rośnie.

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, utrudniają też ukrywanie nieefektywności.

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