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 zrealizowane zostały wszystkie podjęte do Sprintu elementy Backlogu Produktu.
Ktoś może uznać to za zbędne ograniczenie, dowodzące braku pragmatyzmu metody. Tymczasem stała długość Sprintu ma głęboki sens, jeśli dobrze rozumiemy, w jaki sposób działa empiryczna kontrola procesu. Ale zostawmy na razie empiryzm na boku i pochylmy się nad powodami, dla których ktokolwiek chciałby zmienić długość trwającego Sprintu.
Gdy Sprint okazuje się za krótki
Wyobraźmy sobie Zespół, któremu zaczyna brakować czasu na osiągnięcie Celu Sprintu albo na zrealizowanie wszystkich wymagań. To nie jest nietypowa sytuacja i zdarzy się nawet najlepszym, doświadczonym Zespołom. Z wielu powodów:
- Nie wszystko da się przewidzieć podczas Planowania, a każda prognoza obarczona jest błędem. Część pracy, jaką trzeba będzie wykonać, ujawni się dopiero w czasie Sprintu.
- W ciągu Sprintu może wydarzyć się coś, co wpłynie negatywnie na przebieg iteracji.
- Być może ujawni się brak wiedzy lub kompetencji Developerów, spowalniając postęp prac.
- Nierzadko odkryty zostanie dług techniczny w produkcie, a jego usunięcie zajmie sporo czasu.
- Może też dojść do niespodziewanej awarii, która musi zostać pilnie usunięta, co na długo odciągnie Zespół od pracy nad Celem Sprintu i nowymi funkcjonalnościami.
Większość Zespołów pozostawia sobie bufor bezpieczeństwa (nie zaalokowany czas w Sprincie), ale czasami okaże się on niewystarczający. I wtedy stają one przed pozorną alternatywą: dołożenie do Sprintu dnia, może dwóch, pozwoli dostarczyć działający produkt, a jeśli iteracja skończy się w zaplanowanym momencie, nic nie będzie gotowe. Pokusa jest silna i często podbudowana autentyczną troską o to, by na koniec każdego Sprintu dostarczyć coś interesariuszom.
Rozważmy inny scenariusz: w czasie Sprintu, który przebiega modelowo – według planów – Product Owner prosi Developerów o realizację dodatkowego, nowego wymagania. Nie na tyle ważnego, by anulować z niego powodu Sprint, ale wciąż bardzo, bardzo pilnego. Niestety, wymaganie to wiąże się z dużą ilością pracy, na którą nie ma wystarczającej przestrzeni w Sprincie. Chyba, żeby go – w dobrych intencjach, a jakże! – wydłużyć. I znów pojawi się ta silna pokusa, by zignorować „formalne wymogi Scruma” i zadbać o istotne potrzeby interesariuszy…
Pozorny pragmatyzm
„Przedłużenie Sprintu pozwoli nam pragmatycznie poradzić sobie z problemem, który spowodowała złożoność, z jaką się zmagamy” – mówią często Zespoły. I owszem, to złożoność i wynikająca z niej nieprzewidywalność doprowadziła do sytuacji, że Zespołowi brakło czasu, albo że o pilnych potrzebach dowiedział się on w ostatniej chwili. Ale przedłużenie Sprintu nie jest wcale pragmatycznym działaniem. Z kilku powodów.
1. Wzrost ryzyka
Scrum stosowany jest do tego, by radzić sobie z niestabilną złożonością (w tym nieprzewidywalnością) za pomocą empirycznej kontroli procesu. Stałe długości Sprintów mają zmusić nas do twardego sprawdzenia stanu spraw nie wtedy, gdy jest to dla nas wygodne ani nie wtedy, kiedy akurat mamy co sprawdzić – ale regularnie. Ta regularność pozwoli uniknąć długiego brnięcia w ślepe zaułki w przekonaniu, że „jeszcze momencik i skończymy”.
Mówiąc obrazowo, być może to, że czegoś nie udało się zrealizować w Sprincie, jest pierwszym sygnałem, że jest to w ogóle niemożliwe do zrobienia. Albo tak kosztowne, że nie będzie opłacalne. Im wcześniej sobie zdamy z tego sprawę, tym mniej stracimy.
2. Założenia zamiast empiryzmu
Zakładamy wyjątkowość sytuacji, która jest na tyle nietypowa, że decydujemy się na łamanie podstawowych zasad stosowanej metody. No, właśnie: zakładamy, a mieliśmy stosować empiryzm (działać w oparciu o fakty). Tymczasem właściwie nie wiemy, czy sytuacja jest jakkolwiek wyjątkowa, czy raczej jest pierwszym symptomem jakiegoś problemu, z którym przyjdzie nam się zaraz zmierzyć. Problemu niekoniecznie wynikającego z zaniedbań lub złego sposobu pracy kogokolwiek w Zespole.
Tym samym na bazie założenia (a nie empirycznej wiedzy) podejmujemy daleko idącą decyzję o wydłużeniu Sprintu.
3. Działanie po omacku
O ile dłuższa powinna być iteracja? Nigdy nie wiemy tego na pewno, 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 przecież w czasie Planowania Sprintu również dokonujemy oszacowania czasochłonności prac, więc nie ma w tym niczego niezwykłego. Cóż, jest istotna różnica. Planując Sprint wiemy, jak długo będzie on trwał i w odniesieniu do tego szacujemy, co jest możliwe do zrobienia w tym czasie. Przy dyskusji o tym, o ile przedłużyć iterację, takiego punktu odniesienia brak.
4. Wzrost złożoności
Empiryzm ma nam pomóc 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 (a nie ze wszystkimi na raz). A jaki będzie wpływ zmiany długości Sprintu na złożoność środowiska, w jakim działamy?
Trzeba będzie poprzestawiać spotkania, poinformować uczestników, gdzie i kiedy będą się odbywać itd. Może też okazać się, że interesariusze, o których potrzeby tak się troszczymy, nie będą w stanie pojawić się na Przeglądzie Sprintu – czyniąc go mało efektywnym. Złożoność, tu widoczna w formie trudności w organizacji wartościowych Sprintów – wzrośnie.
Oczywiście zawsze można po takim przedłużonym Sprincie zrobić iterację odpowiednio krótszą tak, by „wszystko wróciło na swoje miejsce” w kalendarzu. Czyż to nie „genialne” w swej prostocie? No, nie.
W praktyce otwieramy w ten sposób drogę do nieustannego żonglowania długością Sprintu. Upadnie argument, że trzymamy się stałej długości po to, by regularnie dokonywać sprawdzenia i adaptacji planów działania, Backlogu Produktu, Przyrostu czy samego Zespołu. Skoro raz zrobimy wyjątek, to w sumie czemu nie kolejny raz? Zawsze będzie jakiś „bardzo ważny powód”, czyniący sytuację „wyjątkową”.
5. Zamiatanie problemów pod dywan
Istnieje nikłe prawdopodobieństwo, że w czasie Retrospekcji przedłużonego Sprintu na serio pochylimy 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ł”, a my wykazaliśmy się zaangażowaniem, zamiast dogmatycznie trzymać się definicji Scruma. To po co drążyć ten temat?
Mogą więc nie paść kluczowe pytania: „dlaczego brakło nam czasu?”, „czemu tak późno dowiadujemy się o pilnych wymaganiach?” oraz będące ich konsekwencją „jak uniknąć powtórki?”. A jeśli padną, zbyte zostaną deklaracjami o wyjątkowości sytuacji.
Gdyby Sprint zakończył się o czasie, Zespół musiałby się zmierzyć ze stanem faktycznym, spowodowanym wolniejszym niż spodziewane tempem prac lub podjęciem nieplanowego wymagania do realizacji.
6. Brak wiedzy o Scrumie
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) o wartości wystarczającej, by z produktu dało się korzystać.
A może by tak zrobić krótszy Sprint…
Czasami zdarza się, że Zespół ukończy pracę nad Celem Sprintu i zrealizuje wszystkie wymagania na długo przed zakończeniem iteracji. Po co więc czekać do końca zaplanowanego czasu, skoro można by zacząć kolejny Sprint wcześniej? Co złego może się stać?
W praktyce 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 wymaganie lub wymagania z Backlogu Produktu. Oczywiście takie wymagania muszą zostać w pełni zrealizowane jeszcze w bieżącym Sprincie.
A jeśli brak dostatecznie małych wymagań? Cóż, można dokonać dekompozycji (podziału) jednego z dużych wymagań 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ń, naukę nowych narzędzi itd., czyli wszystkiego, co nie jest rozwojem produktu (dodawaniem 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. Ale też sprzyja ujawnieniu problemów. Jeśli mamy stałą długość Sprintu i widzimy, że permanentnie co Sprint brakuje nam czasu, to możemy poszukać przyczyny. Jak długość Sprintu będzie zmienna, dużo później zauważymy, że w ogóle 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ć, iż 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 robienie 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 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ć Przyrost – bo nawet w przypadku trzydniowego Sprintu i nieogarniętego Zespołu możemy taki stan osiągnąć przez „szatkowanie” problemu 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 trwania iteracji dla konkretnego Zespołu.
Może przy tym okazać się, że owo rozsądne minimum to wciąż za mało. Jeśli Zespół, z powodów dających się dobrze uzasadnić, nie będzie się „wyrabiał” w Sprintach, trzeba rozważyć ich wydłużenie.
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 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 wziąć mniej do Sprintu i to skończyć, zamiast brać do Sprintu dużo i krzyczeć, że są one za krótkie.
Efekty żonglowania długością Sprintów
Najbardziej dotkliwe będzie powolne rugowanie empiryzmu z procesu, który przecież na tym empiryzmie ma się opierać. O ile bez stałej długości Sprintów wciąż możemy działać w oparciu o to, co wiadomo na pewno, sprawdzeń takich zaczniemy dokonywać w sposób nieregularny. I wiele w ten sposób stracimy:
- Nie będzie się dało 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 tego jaka będzie ostatecznie jego długość. Poza tym 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. Powie, że Sprint jest „arbitralnym i niepotrzebnym zatrzymywaniem prac w toku, lepiej byłoby coś skończyć i 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, 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 potrzeb 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 to przede wszystkim Zespół ucierpi, gdy pojawi się 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 kontynuować.
- Developerzy mogą stracić imperatyw do lepszego organizowania sobie pracy i uczenia się nowych praktyk, usprawniających ich działanie. Bo 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. Ale jest 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 ilości zmian w produkcie na raz. 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”
Są metody zwinne, które nie wymagają stosowania iteracji, na przykład Kanban. 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 przecież dobrze działa. Tak, to prawda, tyle że tylko częściowo.
Po pierwsze, Kanban dopuszcza stosowanie iteracji, a nawet definiuje kilka tak zwanych kadencji (opcjonalnych, bo nie trzeba z nich korzystać). Po drugie, w Kanbanie obowiązkowe jest ograniczenie ilości pracy w toku (Work in Progress limit), co zabezpiecza Zespół przed „wciągnięciem” do procesu nadmiernej ilości pracy. Po trzecie, Kanban wymaga aktywnego zarządzania przepływem (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ć.
Dlatego niezależnie od tego, czy posłużymy się Scrumem, czy Kanbanem, nie będziemy mogli pracować nad zbyt wieloma wymaganiami na raz ani realizować ich zbyt długo. W Scrumie dopadną nas granice Sprintów, w Kanbanie wysycenie limitów pracy w toku. Oczywiście, możemy złamać zasady, i przedłażyć Sprinty (w Scrumie), albo ignorować lub po prostu podnosić bezrefleksyjnie limity (w Kanbanie) – tyle, że odbędzie się to w obu przypadkach kosztem empiryzmu i doprowadzi do dramatycznego wzrostu złożoności.
Zdjęcie: Free To Use Sounds