Zalety krótkich Sprintów
Im krótszy Sprint, tym szybciej dostaniesz informację zwrotną. Łatwiej też będzie Ci reagować na zmiany i nową wiedzę. Mniej zgadywania, bo planujesz tylko na kilka dni do przodu. Mniej też zainwestowanego czasu (i pieniędzy), jeśli dowiesz się, że idziesz w złym kierunku. Jeśli operujesz na bardzo zmiennym rynku, a wymagania zmieniasz częściej niż podkoszulki to staraj się utrzymywać jak najkrótsze iteracje.
Zalety długich Sprintów
Czasami w ciągu jednego tygodnia nie jesteście w stanie dostarczyć przetestowanego, działającego produktu. W związku z tym potrzebujecie dłuższy Sprint, aby móc wykonać wszystkie prace niezbędne do stworzenia „Skończonego Przyrostu” (Done Increment).
Co wziąć pod uwagę?
Tym co ma największy wpływ na długość iteracji są Twoje obecne praktyki inżynieryjne. Pamiętam pierwszy produkt, w którym pracowałem. Kompilacja kodu zajmowała kilkanaście godzin, potem ręczny deployment i manualne testy. No, ale to zamierzchła przeszłość. Stan twojej ciągłej integracji i automatyzacji testów powie Ci dużo na temat możliwości skrócenia Sprintu. Nie możesz też zapominać o stanie kodu. Jeśli wygląda jak spaghetti i nigdy nie był refaktoryzowany to szanse na szybkie i bezbolesne dodanie nowej funkcji są niewielkie.
Przy nowoczesnych językach programowania możesz spokojnie mieć działający produkt co chwilę, więc tygodniowe iteracje są jak najbardziej realne. Z moich obserwacji najpopularniejsze obecnie są dwutygodniowe Sprinty. Jeżeli masz jakieś antyczne technologie i dużo manualnych testów to rozważ trzytygodniowe Sprinty. Jeżeli wreszcie robisz produkty fizyczne, które trzeba wydrukować na drukarce 3D i zintegrować, to cztery tygodnie może być dla Was dobrym rozwiązaniem.
Czego unikać?
Jeżeli piszesz w Java albo w Ruby i potrzebujesz miesiąca, żeby dostarczyć działający produkt to problemem nie jest długość Sprintu a jakość kodu albo waszych praktyk. Pamiętaj, Scrum nie rozwiązuje problemów, on je tylko pokazuje. W tym przypadku większość waszych usprawnień powinna być skoncentrowana na poprawie stanu praktyk inżynieryjnych i współpracy w ramach zespołu.
Gdzieniegdzie pojawia się pokusę ustalania długości Sprintu pod ilość planowanej pracy. Nie tędy droga. To podejście świadczy o tym że nie radzicie sobie z podziałem pracy na mniejsze elementy. Poznaj różnorodne techniki dekompozycji, popracuj z PO i stakeholderami aby nauczyć się jak dostosować pracę do wielkości Sprintu, a nie na odwrót. Dzięki temu będziesz mógł utrzymać stałą długość Sprintu, co bardzo ułatwi Wam życie. Po pierwsze uprości to planowanie, bo z doświadczenia wiecie ile możecie zrobić. Po drugie eliminuje zbędną dyskusję w trakcie planowania każdej iteracji. Po trzecie wreszcie ogranicza presję na wydłużenie Sprintu, żeby „coś tylko dokończyć”. Owszem, można zmienić datę zakończenia Sprintu, jak akurat wypada w Wielkanoc lub Boże Narodzenie, ale to sytuacje podbramkowe, a nie praktyka.
Jesteśmy przyzwyczajeni do rytmu tygodnia. Sprinty 8- czy 30-dniowe, jeśli nie są uzasadnione krytycznymi warunkami biznesowymi sprawią wam więcej kłopotów niż pożytku. Zdecydowanie jest łatwiej zaprosić biznes na Review, jeżeli odbywa się w co drugą środę, niż co 17-cie dni pracujących. Dlatego trzymaj się rytmów o podstawie tygodnia, gdzie wiadomo, że ceremonie odbywają się regularnie w ten sam dzień i można je zaplanować w kalendarzu.
No i ostanie. Jeśli wasze poniedziałki wyglądają jak sen wariata, to zaplanowanie przełomu Sprintu na ten dzień tylko Cię pogrąży. Nikt nie powiedział, że Sprint nie może zaczynać się w środę.
Jak zacząć?
Z mojego doświadczenia wynika, że dużo łatwiej jest zespołom nauczyć się pracować w krótkich, tygodniowych cyklach i potem przejść na dwa tygodnie, niż zacząć od czterotygodniowych Sprintów i próbować zejść do dwóch. W pierwszym przypadku Zespół szybko się uczy jak pracować razem i bez problemu sobie poradzi z dłuższym Sprintem. W drugim, wszystkie problemy dopiero ujrzą światło dzienne po skróceniu iteracji, a winę za ich pojawienie często zrzuca się na Scruma. Jeżeli uznacie, że Wasza długość Sprintu nie jest optymalna możecie się zdecydować na zmianę długości dla wszystkich kolejnych Sprintów.
