Krótka odpowiedź na tytułowe pytanie brzmi następująco: nie, nie można. Możliwe jest co najwyżej anulowanie przez Product Ownera już rozpoczętej iteracji, ale wyłącznie pod warunkiem, że Cel Sprintu stał się nieistotny i nie warto go osiągać. Przy czym Product Owner nie musi wcale z tej opcji skorzystać. Przedłużenia Sprintu metoda nie przewiduje w żadnej sytuacji.

Sprint to specyficzne zdarzenie w Scrumie. Po pierwsze, jest kontenerem na wszystkie pozostałe zdarzenia (a więc wbrew błędnemu rozumowaniu wielu osób iteracja nie rozpoczyna się dopiero po Planowaniu Sprintu). Po drugie, w odróżnieniu od pozostałych zdarzeń, Sprint ma stały czas trwania zamiast timeboxu określającego jego maksymalną długość. Nie można więc go skrócić, nawet jeśli dawno już osiągnięty został Cel Sprintu i ukończona została praca nad wszystkimi elementami Backlogu Produktu podjętymi do realizacji.

Ktoś może uznać, że Sprint to ograniczenie swobody decyzyjnej Zespołu dowodzące braku pragmatyzmu metody. Tymczasem stałej długości Sprinty mają głęboki sens, jeśli dobrze rozumiemy, w jaki sposób działa empiryczna kontrola procesu. Zostawmy jednak na razie empiryzm na boku i pochylmy się nad powodami, dla których ktokolwiek chciałby zmienić długość trwającego Sprintu.

Powód 1: brak czasu na development

Wyobraźmy sobie Zespół, któremu zaczyna brakować czasu na osiągnięcie Celu Sprintu albo na ukończenie prac nad wszystkimi elementami Backlogu Produktu podjętymi do realizacji. To nie jest niezwykła sytuacja i nawet najlepszym doświadczonym Zespołom może zdarzyć się z wielu powodów:

  • Nie wszystko da się przewidzieć w trakcie Planowania Sprintu, a każda prognoza obarczona jest błędem. Część pracy, jaką trzeba będzie wykonać, ujawnia się dopiero w czasie Sprintu.
  • W każdym dniu Sprintu może wydarzyć się coś, co wpłynie negatywnie na przebieg developmentu.
  • Być może ujawni się brak wiedzy lub kompetencji Developerów, którzy będą musieli się czegoś douczyć.
  • Odkryty zostanie dług techniczny w produkcie, a jego usunięcie zajmie sporo czasu.
  • Może dojść do niespodziewanej awarii, która musi zostać pilnie usunięta, co na długo odciągnie Developerów od pracy nad Celem Sprintu.

Większość Zespołów w trakcie Planowania pozostawia zapas czasu na nieprzewidywaną pracę, ale nie zawsze okaże się on wystarczający. Pokusa, by Sprint przedłużyć w takiej sytuacji, jest silna i często podbudowana autentyczną troską o to, by na koniec każdej iteracji dostarczyć coś interesariuszom.

Bywa też i tak, że Product Owner prosi Developerów o realizację pilnej zmiany w produkcie, która wymaga dużej ilości pracy. Na tę pracę brak przestrzeni w Sprincie, o ile się go – w dobrych intencjach, a jakże! – nie wydłuży.

Powód 2: pozorny pragmatyzm

„Przedłużenie Sprintu to pragmatyczne działanie, które da nam czas na poradzenie sobie z nieprzewidzianym problemem wynikającym z dużej złożoności tego, co robimy” – mówią często Zespoły. I zwykle mają rację: to złożoność i wynikająca z niej nieprzewidywalność doprowadza często do sytuacji, że już w trakcie Sprintu ujawnia się potrzeba wykonania pracy, na którą brakuje czasu. Piszę, że zwykle mają rację, bo część problemów wynika bynajmniej nie z obiektywnej złożoności środowiska, w jakim Zespoły funkcjonują, ale ze sposobu, w jaki Zespoły te działają.

Niezależnie od przyczyn braku czasu w Sprincie, jego wydłużenie nie ma nic wspólnego z pragmatyzmem, bo nie rozwiązuje żadnego problemu, a może spowodować kilka nowych. Jakich?

Wzrost ryzyka

Scrum pozwala Zespołom lepiej radzić sobie z niestabilną złożonością dzięki empirycznej kontroli procesu. Stała długość Sprintów zmusza Zespoły do sprawdzenia stanu spraw nie wtedy, gdy jest to dla nich wygodne, ale regularnie. Ta regularność pozwala uniknąć długiego brnięcia w ślepe zaułki w przekonaniu, że „jeszcze momencik i skończymy”.

Jeśli prognoza, że coś da się zrealizować przed końcem Sprintu, okazała się błędna, należy zatrzymać się i dokonać oceny, czy prace warto kontynuować. A jeśli tak, to w jaki sposób i kiedy – bo wcale nie musi to być kolejny Sprint.

Przypominam, że Sprint jest nie tylko kontenerem na development i wszystkie zdarzenia w Scrumie, ale również na ryzyko. Inaczej mówiąc, koszt przeprowadzenia jednego Sprintu jest zarazem maksymalnym kosztem nietrafionej inwestycji, gdyby okazało się, że zmiany w produkcie, nad jakimi pracował Zespół, są niewłaściwe albo wręcz niewykonalne.

Jeśli na wykonanie zaplanowanych prac brakuje czasu, to znaczy, że poprzednie prognozy odnośnie do tego, co da się zrobić w trakcie iteracji, okazały się nietrafione. Przedłużenie Sprintu tylko po to, by kontynuować realizację nietrafionego planu, dodatkowo zwiększa ryzyko poniesienia strat.

Założenia zamiast empiryzmu

Decydując się na przedłużenie Sprintu, Zespoły zawsze mówią o wyjątkowości sytuacji, która rzekomo uzasadnia to łamanie podstawowych zasad stosowanej metody. Czy ujawnienie dodatkowej pracy, na której wykonanie brakuje czasu, jest naprawdę czymś niespodziewanym i niezwykłym w domenie o dużej złożoności? Absolutnie nie, bo nieprzewidywalna zmienność podstawowa cecha takiej domeny.

Jeśli Zespół wydłuża Sprint po to, by kontynuować rozpoczęte prace, w istocie dokonuje trzech istotnych założeń:

  1. Rozpoczęte prace da się ukończyć.
  2. Ukończenie prac przyniesie wartość.
  3. Kontynuowanie prac bez żadnej przerwy przyniesie więcej korzyści zatrzymanie się po to, by dokonać świadomego wyboru czy, jak i kiedy prace te kontynuować.

Przy czym żadnego z tych trzech założeń nikt nie formułuje wprost i Zespół nie dokonuje żadnej oceny prawdopodobieństwa ich trafności. Żeby to bowiem zrobić, trzeba by zakończyć Sprint zgodnie z planem, dokonać oceny jego przebiegu (czyli przeprowadzić Przegląd Sprintu), poszukać ewentualnych usprawnień (w ramach Retrospekcji Sprintu), a następnie dokonać zmian w Backlogu Produktu i zaplanować kolejną iterację. Tymczasem tego właśnie Zespół postanowił na razie nie robić.

W konsekwencji działania odbywają się oparciu o założenia, a Zespół dąży do tego, by rozwiązać duży problem raz-a-dobrze bez dzielenia go na mniejsze kawałki. I jedno i drugie jest fundamentalnie sprzeczne z ideą inkrementalnego i iteracyjnego rozwoju produktu z użyciem Scruma.

Działanie po omacku

O ile dłuższa powinna być iteracja, jeśli już zdecydujemy się na jej wydłużenie? Możemy jedynie oszacować, jak długo potrwa wykonanie wszystkich prac. Co stanie się, jeśli prognozy się nie sprawdzą i znów braknie czasu? Będziemy przedłużać Sprint w nieskończoność? Czy też, na wszelki wypadek, od razu z przytupem przedłużymy go o połowę?

Ktoś powie, że niczym się to nie różni od Planowania Sprintu, w którego trakcie również dokonuje się oszacowania czasochłonności developmentu. To prawda, Planowanie Sprintu opiera się o szacunki i prognozy. Tyle tylko, że Planowanie to polega na poszukiwaniu odpowiedzi na pytanie, co da się zrobić w iteracji o znanej długości – można powiedzieć, że Zespół rozwiązuje równanie z jedną niewiadomą. Natomiast przy dyskusji o tym, o ile przedłużyć iterację, Zespół oszacować musi zarówno to, jak wiele pracy pozostało do wykonania, jak i to, ile czasu na nią potrzebuje – ma więc dwie niewiadome.

Gdyby Sprint zakończył się o czasie, odbyłaby się dyskusja o tym, czy, jak i kiedy rozpoczęte prace dokończyć. Nic nie stoi na przeszkodzie, by kontynuacja taka nastąpiła od razu w kolejnym Sprincie po niezbędnym dostosowaniu planów działania.

Odejście od inkrementalnego rozwoju produktu

Empiryzm pomaga nam w okiełznaniu złożoności. Nie pozwoli jej zmniejszyć (bo jest ona inherentną częścią tego, czym się zajmujemy), ale pozwoli pokroić ją na plasterki, dzięki czemu możemy z problemami radzić sobie jeden po drugim.

Jeśli na wykonanie zaplanowanych prac zaczyna brakować czasu, to być może zmiana w produkcie, jaką chce zrealizować Zespół, jest po prostu za duża, by dokonać jej za jednym zamachem. Jej złożoność, czasochłonność, stopień skomplikowania itd. przerasta możliwości Developerów i powinni oni dokonać dekompozycji dużego problemu na kilka mniejszych.

Czy wolno dokonać podziału dużego elementu Backlogu Produktu na kilka mniejszych już w trakcie realizacji? Jasne, że tak. Dlaczego więc w sytuacji, gdy Developerom robota spuchła w rękach, nie próbują takiej dekompozycji dokonać, tylko zapada karkołomna decyzja o przedłużaniu Sprintu i kontynuowaniu prac zgodnie z pierwotnymi planami, raz-a-dobrze?

Wzrost złożoności

Jaki będzie wpływ zmiany długości rozpoczętego już Sprintu na złożoność środowiska, w jakim działa Zespół?

Skutek oczywisty (bo natychmiastowy) to konieczność przestawiania terminu Przegląd Sprintu i Retrospekcji. Trzeba poinformować uczestników o tej zmianie. A wtedy może okazać się, że interesariusze, o których potrzeby tak się przecież troszczymy, nie będą w stanie pojawić się na Przeglądzie Sprintu – czyniąc go mało efektywnym.

Drugi skutek to skrócenie kolejnego Sprintu, bo przecież Zespół nie będzie chciał od tego momentu poprzestawiać dat rozpoczęcia i zakończenia wszystkich przyszłych iteracji. Skoro aktualny Sprint był dłuższy, kolejny będzie ciut krótszy i „wszystko wróci na swoje miejsce” w kalendarzu. Czyż to nie „genialne” w swej prostocie? No, nie.

Bo tu pojawiają się skutki mniej oczywiste. Zespół pokaże interesariuszom, że w racie potrzeb można żonglować długością Sprintu. Upadnie argument, że należy się trzymać stałej długości iteracji po to, by regularnie dokonywać sprawdzenia produktu i adaptacji planów dalszego jego rozwoju. Skoro raz zdarzył się Sprint zmiennej długości, to w sumie czemu nie zrobić takiego kolejny raz? Zawsze będzie jakiś „bardzo ważny powód”, czyniący sytuację „wyjątkową”.

A to wiedzie do problemu jeszcze mniej oczywistego, za to bardzo dotkliwego. W jaki sposób Zespół miałby zaplanować Sprint w sytuacji, gdy właściwie nie wiadomo, ile on ostatecznie będzie trwał? Planowanie Sprintu polega przecież w znacznym stopniu na ocenie czasochłonności planu realizacji poszczególnych elementów Backlogu Produktu. Jeśli długość Sprintu może być zmieniana, zniknie punkt odniesienia do sporządzania takich ocen.

Zamiatanie problemów pod dywan

Istnieje nikłe prawdopodobieństwo, że w czasie Retrospekcji przedłużonego Sprintu Zespół na serio pochyli się nad tym, co się stało. Bo przecież to „wyjątkowa sytuacja”, prawda? A wyjątki się zdarzają, tak to już jest. Tym bardziej że w sumie „Sprint się udał”: dzięki wydłużeniu iteracji udało się wszystko „dowieźć”. Co więcej, Zespół wykazał się zaangażowaniem, zamiast dogmatycznie trzymać się definicji Scruma i na siłę dzielić robotę na kawałki ze względu na jakieś tam granice Sprintów. To po co drążyć ten temat?

Mogą więc nie paść kluczowe pytania: „dlaczego brakło nam czasu?”, „czemu tak późno odkrywamy, co tak naprawdę jest do zrobienia?” oraz będące ich konsekwencją „jak uniknąć powtórki?”. A jeśli padną, zbyte zostaną deklaracjami o wyjątkowości sytuacji.

Gdy Sprint kończy się o czasie, Zespół wręcz odruchowo pochyli się nad przyczynami, które doprowadziły do nieukończenia części zaplanowanych prac. I nawet wtedy, gdy nastąpiło to z powodów zupełnie od Zespołu niezależnych, będzie szukał środków zaradczych, które zmniejszą ryzyko powtórzenia się tej sytuacji w przyszłości.

Powód 3: zła organizacja pracy developerskiej

Jedną z częstych przyczyn, dla których zaczyna brakować czasu w Sprincie na wykonanie zaplanowanych prac, jest mało efektywny development. Przykładem takiego braku efektywności jest realizowanie wielu zmian w produkcie równocześnie i późne ich integrowanie w jedną całość tuż przed końcem Sprintu. Ponieważ taka integracja jest skomplikowana, pojawia się sporo problemów, na których rozwiązanie zostaje bardzo mało czasu. I dochodzi do dziwacznej sytuacji, że albo uda się ukończyć wszystko, albo nie powstanie żaden Przyrost. Wtedy też pojawia się „wspaniały pomysł”, by Sprint wydłużyć.

Innym przykładem braku efektywności jest wąska specjalizacja Developerów, którzy przerzucają się poszczególnymi problemami do rozwiązania. Wtedy nie dość, że Zespół pracuje nad wieloma zmianami w produkcie naraz (czyli pojawia się efekt opisany powyżej), to jeszcze Developerzy muszą poświęcić czas i wysiłek na koordynację prac, jakie wykonują. A jeśli jedną z takich wąskich specjalizacji jest testowanie, to pod koniec Sprintu wszyscy czekają na jedną lub dwie osoby, które próbują dokonać cudu i przetestować wszystko na czas. Jeśli znajdą błędy, nie będzie już przestrzeni, by je naprawić, więc czasami testują tak, by tych błędów za wiele nie znaleźć. Choć w razie czego przedłuży się Sprint, czyż nie?

Żonglowanie długością iteracji w Scrumie to wyjątkowo marny sposób na radzenie sobie ze skutkami niskiej efektywności Zespołu. Co więcej, może dawać złudne poczucie, że „Zespół dostarcza przecież wartość, więc wszystko jest w porządku”. Nie jest, bo nie potrafi tego robić regularnie, często i w sposób wystarczająco przewidywalny. Gdyby, zamiast przedłużać Sprinty, Developerzy zmienili organizację swojej pracy, np. sięgając po praktyki kanbanowe, efektywność i tym samym skuteczność Zespołu byłaby o wiele wyższa.

Powód 4: brak rozumienia Scruma

W wielu Zespołach pokutuje przekonanie, że produkt może zostać przekazany użytkownikom tylko na koniec Sprintu. Jeśli więc „niewiele brakuje”, by prace ukończyć, pojawia się presja, by bieżącą iterację przedłużyć. W przeciwnym razie użytkownicy musieliby czekać długo na nowe funkcjonalności produktu – aż do końca kolejnego Sprintu.

Tymczasem w Scrumie nie ma żadnego związku między Sprintami a decyzją o przekazaniu produktu do użycia. Można to zrobić za każdym razem, gdy powstanie Przyrost (nowa, ukończona wersja produktu, która spełnia kryteria zawarte w Definicji Ukończenia) o wartości wystarczającej dla użytkowników.

Powód 5: wszystko już zostało zrobione

Czasami zdarza się, że Zespół osiągnie Cel Sprintu i zrealizuje wszystkie zaplanowane prace na długo przed zakończeniem iteracji. Po co więc czekać do końca zaplanowanego czasu, skoro można zacząć kolejny Sprint wcześniej? Co złego może się stać?

W praktyce stać się może dokładnie to samo, co w przypadku przedłużania Sprintu. Zaburzony zostanie rytm empirycznej kontroli procesu, wzrośnie złożoność. W czasie Retrospekcji Sprintu nikt raczej nie pochyli się wtedy nad przyczynami, dla których udało się prace ukończyć tak szybko – to raczej będzie powód do dumy (zapewne słusznie) niż analiz i wyciągania wniosków (zupełnie niesłusznie).

Bardzo często pomysł, by skrócić w tej sytuacji Sprint, wynika z niewiedzy, że o ile Cel Sprintu jest stały i nie można go zmieniać, to zakres prac może zmieniać się dowolnie decyzją Zespołu Scrum. Tym samym nic nie stoi na przeszkodzie, by do Sprintu wciągnąć dodatkowe elementy z Backlogu Produktu. Oczywiście takie elementy muszą zostać w pełni zrealizowane jeszcze w bieżącym Sprincie.

A jeśli brak dostatecznie małych elementów w Backlogu Produktu? Cóż, można dokonać dekompozycji (podziału) jednego z dużych na kilka mniejszych, a jeśli i to niemożliwe – zająć się czymś innym. Taki slack time wykorzystać można przecież na pielęgnację Backlogu Produktu, rozwiązywanie błędów, dokonywanie usprawnień infrastruktury i narzędzi, naukę nowych praktyk lub technologii itd., czyli wszystkiego, co nie jest rozwojem produktu (czyli nie polega na dodawaniu do niego nowych cech i funkcjonalności).

Po co są Sprinty w Scrumie?

Praca w stałych cyklach porządkuje działania, ułatwia planowanie, organizację zdarzeń procesowych, wychwytywanie trendów itd. Sprzyja też ujawnianiu problemów. Jeśli mamy stałą długość Sprintu i widzimy, że permanentnie co Sprint brakuje nam czasu, to możemy poszukać przyczyny. Jeśli długość Sprintu będzie zmienna, dużo później zauważymy, że jest jakiś problem (a może wcale tego nie dostrzeżemy).

Sprinty w Scrumie mają co do zasady stałą długość. Powinna ona być dobrana tak, by zapewnić, że Zespół Scrum reagował będzie wystarczająco szybko na zmienność domeny, w której pracuje. Scrum określa maksymalną długość Sprintu na miesiąc, ale nie w każdym środowisku zastosowanie miesięcznych Sprintów byłoby racjonalne. Tam, gdzie przez miesiąc może zawalić się cały biznes, na pewno potrzebujemy krótszych Sprintów.

Żonglowanie długością iteracji grozi tym, że zaczniemy w końcu robić Sprinty po prostu za długie (choć wciąż zgodne z wymogami Scruma). I biznes się zawali. Jak? Na przykład w taki sposób, że wydamy fundusze i stracimy czas na robienie czegoś, co jest nieopłacalne lub niemożliwe do ukończenia, a potem już braknie nam czasu, by się z tego wycofać lub funduszy na zrobienie czegokolwiek innego.

Stała długość Sprintu nie oznacza oczywiście, że nigdy nie wolno jej zmienić. Sprint musi być na tyle krótki, by czas reagowania na zmiany (jak opisałem powyżej) był akceptowalny. Inaczej mówiąc, by nie było często sytuacji, w której w połowie Sprintu pojawia się konieczność zrobienia czegoś ekstremalnie ważniejszego od tego, co zaplanowaliśmy na tę iterację i co nie może czekać na jej zakończenie. Jeśli zdarza się to często, wtedy powinniśmy skrócić Sprinty, znów na stałe (a dokładniej: z intencją pracowania w nich długo, chyba że empirycznie odkryjemy, że trzeba zmienić ją ponownie).

Sprint musi jednocześnie być na tyle długi, by dało się w nim cokolwiek wartościowego wytworzyć. I tu nie chodzi tylko o to, czy Developerzy zdążą wyprodukować choć jeden Przyrost – bo nawet w przypadku trzydniowego Sprintu i nieogarniętego Zespołu możemy taki stan osiągnąć przez szatkowanie problemów na bardzo małe kawałeczki. Niestety to szatkowanie samo w sobie będzie bardzo czasochłonne, więc trzeba poszukać kompromisu. I w ten sposób będziemy wiedzieć, jakie jest rozsądne minimum czasu trwania iteracji dla konkretnego Zespołu.

Może przy tym okazać się, że owo rozsądne minimum to wciąż za mało dla Developerów. Jeśli Zespół, z powodów dających się dobrze uzasadnić, nie będzie się wyrabiał w krótkich Sprintach, trzeba rozważyć ich wydłużenie – począwszy od kolejnej iteracji, a nie w trakcie.

Oczywiście to ostateczność, dlatego mówię o uzasadnionych powodach. Jest nim np. obiektywna czasochłonność niektórych działań, których Zespół nie jest w stanie skrócić (bo nie od niego zależą) – np. przetwarzanie danych tak, by przygotować je na potrzeby testu.

Natomiast nie jest dobrym powodem sytuacja, w której nieefektywny development, zła organizacja pracy, niski poziom praktyk itd. powodują, że praca idzie wolno. Zamiast wydłużać Sprint, trzeba zacząć pracować lepiej – uczyć się nowych praktyk, narzędzi itd.

Nie jest też dobrym powodem do wydłużenia Sprintu chęć pokazania, że my „dużo możemy” i tworzenie bardzo rozbudowanych prognoz tego, co zostanie zrobione w Sprincie, a czego ostatecznie nie udaje się osiągnąć. Zespół musi planować racjonalnie – czasami lepiej podjąć mniej elementów Backlogu Produktu do Sprintu i je zrealizować, zamiast brać ich do Sprintu dużo i potem krzyczeć, że brakuje czasu.

Efekty żonglowania długością Sprintów

Najbardziej dotkliwe będzie powolne rugowanie empiryzmu z procesu, który na tym empiryzmie ma się przecież opierać. O ile bez stałej długości Sprintów wciąż możemy działać na podstawie faktów i empirycznych danych, o tyle sprawdzeń takich zaczniemy dokonywać w sposób nieregularny. I wiele w ten sposób stracimy:

  • Nie będzie się można wychwycić trendów, które widoczne są wtedy, gdy coś sprawdzamy (albo mierzymy) regularnie.
  • Pojawi się poczucie niepewności w czasie Planowania Sprintu odnośnie do tego, jaka będzie ostatecznie jego długość. A trudno prognozować, co jest możliwe do realizacji w tak nieprecyzyjnie zdefiniowanym Sprincie.
  • Może wręcz dojść do zacierania się granic Sprintów, gdy Zespół uzna za mało ważne trzymanie się stałej długości iteracji. Stwierdzi, że Sprint powoduje arbitralne i niepotrzebne zatrzymywanie prac w toku i że lepiej byłoby coś skończyć, a dopiero potem się temu przyglądać. Pozornie to prawda, tyle że to zachęta do robienia rzeczy tak długo, aż je się skończy, bez sprawdzania, czy jest sens je w ogóle kontynuować. Brak bowiem presji wynikającej z istnienia granic iteracji, by jednak regularnie coś kończyć.
  • Spadnie przejrzystość procesu, który stanie się w znacznym stopniu uznaniowy. Stąd już tylko krok do postępującej dekompozycji Scruma. A przecież wszystkie jego elementy są niezbędne, jeśli chce się na serio używać empiryzmu.
  • Może dojść do naruszenia umowy między interesariuszami i Zespołem, w ramach której interesariusze otrzymują elastyczność (możliwość zmiany kierunku rozwoju produktu co Sprint) w zamian za stabilność dla Zespołu w czasie iteracji. Choć początkowo to z inicjatywy Zespołu Sprinty będą np. wydłużane, potem przede wszystkim Zespół ucierpi, gdy pojawi się u interesariuszy przekonanie, że właściwie w każdym Sprincie wszystko można w dowolnym momencie pozmieniać.
  • Dużo łatwiej będzie o sytuację, w której prowadzi się długo działania zmierzające donikąd, bo nie będzie regularnego sprawdzenia (w ramach Przeglądu Sprintu) i bezwzględnej oceny, czy warto jakieś prace kontynuować.
  • Developerzy mogą stracić imperatyw do lepszego organizowania sobie pracy i uczenia się nowych praktyk usprawniających ich działanie. Po co uczyć się nowych rzeczy albo rezygnować z przyzwyczajeń, skoro w razie czego Sprint można sobie wydłużyć…

Sprinty są generatorem stabilizacji w procesie wytwarzania produktu, dlatego odejście od nich lub ciągłe zmienianie czasu trwania iteracji zawsze spowoduje problemy.

Jest również jeszcze jedna, ważna funkcja Sprintów, o której należy pamiętać. Stała długość Sprintu powoduje, że Zespół nie ma możliwości podjęcia do realizacji dużej liczby zmian w produkcie naraz. Trzeba je wykonywać małymi partiami, co daje dwie korzyści: można często sprawdzać aktualną wartość produktu (który rozwijany jest przyrostowo), a prace nad poszczególnymi zmianami nie trwają dłużej niż Sprint.

„A przecież Kanban radzi sobie bez iteracji”

Bardzo często w dyskusji o tym, czy Sprinty można przedłużać albo skracać, pada argument, że Kanban nie ma iteracji w ogóle, a mimo to da się go użyć do rozwoju produktu i wiele Zespołów to robi. Tak, to prawda, tyle że tylko częściowo.

Po pierwsze, Kanban dopuszcza stosowanie iteracji, a zatem fakt posługiwania się nim nie oznacza automatycznie, że praca nie odbywa się w interwałach o stałej długości. W przypadku pracy nad rozwojem produktu konieczne jest regularne potwierdzanie z interesariuszami, czy wytworzone rozwiązania są właściwe, a plany dalszego developmentu odpowiadają ich potrzebom. Nie da się tego robić skutecznie, organizując spotkania ad hoc.

Po drugie, w Kanbanie obowiązkowe jest kontrolowanie ilości pracy w toku (ang. work in progress, w skrócie WIP), co zabezpiecza Zespół przed wciągnięciem do procesu nadmiernej ilości pracy. Iteracje o stałej długości, w których uczestniczy określona grupa osób, to jeden ze sposobów na kontrolowanie WIP-u.

Po trzecie, Kanban wymaga aktywnego zarządzania przepływem (ang. flow), co w praktyce oznacza dążenie do jak najszybszego kończenia rozpoczętych prac, a także dokonywania usprawnień, jeśli prace zaczynają się przeciągać. Inaczej mówiąc, z faktu braku iteracji nie wynika bynajmniej, że można prace nad jakąś zmianą w produkcie prowadzić w nieskończoność.

Jeśli Zespół faktycznie trzyma w ryzach ilość pracy w toku (czyli dokonuje niewielkiej liczby zmian w produkcie naraz), ale nie pracuje efektywnie i ma problemy z szybkim kończeniem prac, kolejka na wejściu do procesu zacznie się szybko rozrastać. Jeśli natomiast zdecyduje się podjąć do realizacji kolejne zmiany w produkcie mimo braku ukończenia prac rozpoczętych wcześniej, to w końcu pogrąży się w chaosie i w ogóle przestanie cokolwiek dostarczać.

Mówiąc wprost, nie da się uciec od problemu nieefektywności Zespołu, porzucając Scrum na rzecz Kanbana, chyba że nie będzie to prawdziwy Kanban, a jedynie jakaś jego imitacja.

Poza tym Kanban nie jest metodą, tylko strategią optymalizacji przepływu wartości przez jakiś proces. Jeśli posługujemy się Kanbanem, to albo sami zdefiniować musimy proces, z jakiego korzystamy, albo sięgnąć musimy po gotową metodę, którą uzupełnimy praktykami kanbanowymi. W szczególności może to być Scrum.

Więcej: jeśli faktycznie działamy w domenie pełnej niestabilnej złożoności i zajmujemy się rozwojem produktu, to jeśli będziemy szukać sposobu na skuteczne działanie, nieuchronnie nasz proces stanie się iteracyjny, a zmiany w produkcie wprowadzać będziemy inkrementalnie. Czyli z czasem taki proces będzie coraz bardziej upodabniał się do Scruma.

Dlatego, zamiast wymyślać ciężkim wysiłkiem chłopa i robotnika empiryzm na nowo, po prostu posłużmy się Scrumem i zastosujmy w nim praktyki kanbanowe. Scrum zapewni nam mechanikę niezbędną do dbania o wartość produktu i zręby procesu empirycznego, a Kanban ułatwi zarządzanie pracą tak, by zmaksymalizować szansę na zrealizowanie zaplanowanych zmian w produkcie bez przedłużania Sprintów.