Blog

Jakiś czas temu pisałem o czynnikach, jakie należy brać pod uwagę przy określaniu długości Sprintu (artykuł tutaj). Jakie mogą być skutki złego wyboru?

Nie możemy tak długo czekać…

Nieuchronną konsekwencją długich Sprintów jest wzrost presji w czasie ich trwania, by podjąć do realizacji kolejne pilne wymagania. W ciągu miesiąca, jeśli tak długo trwa Sprint, mogą pojawić się potrzeby wielokroć ważniejsze niż te, nad którymi obecnie pracuje Zespół. Bywa tak, że ani Developerzy nie zdołają się przeciwstawić się skutecznie tej presji i zaczyna się bałagan. W takiej sytuacji najlepszym wyjściem jest skrócić Sprinty, żeby interesariusze byli w stanie zaakceptować konieczność oczekiwania tydzień, może dwa – to zdecydowanie łatwiejsze niż miesiąc albo i dłużej.

Niewłaściwy produkt

Inną konsekwencją długich Sprintów jest podwyższone ryzyko pójścia w złą stronę. Można powiedzieć, że koszt pojedynczej iteracji to maksymalny wymiar strat,  jakie poniesie organizacja, jeśli realizowane prace okażą się niepotrzebne. Jeśli niepewność co do kierunku rozwoju produktu jest duża, długie Sprinty nie są dobrym pomysłem; ich skrócenie spowoduje, że dużo szybciej będzie można ocenić, czy podjęte przez Product Ownera decyzje były słuszne, a produkt został zrobiony dobrze.

Planowanie czy wróżenie z fusów?

Długie Sprinty mają wadę również z punktu widzenia Developerów. Bo choć niezaprzeczalnie dysponują oni wtedy większą ilością czasu na realizację elementów Backlogu Produktu, to z drugiej strony zmuszeni są do zaplanowania działań np. na miesiąc do przodu, a nie na tydzień lub dwa. Takie plany w oczywisty sposób obłożone są większym błędem, przez co przebieg Sprintów staje się mniej przewidywalny.

Waterfallu, witaj ponownie!

Pojawi się też okazja, by powróciło stare, ale niekoniecznie dobre podejście kaskadowe. Mając do dyspozycji cały miesiąc na osiągnięcie Celu Sprintu, Zespół może potraktować iterację jako projekt i podzielić pracę na fazy: analizy, developmentu i testów. To podnosi ryzyko, że większości realizowanych elementów Backlogu Produktu nie uda się ukończyć, bo kluczowe działania (integracja produktu w całość i przetestowanie go) odbywać się będzie na końcu, gdy brakować zaczyna czasu na radzenie sobie z nieprzewidzianymi trudnościami.

Gdy Sprinty trwają tylko kilka albo kilkanaście dni, dzielenie pracy na etapy nie ma żadnego sensu, bo każdy z nich trwałby za krótko. Różne typy czynności developerskich muszą się odbywać w tym samym czasie, więc co mądrzejsze Zespoły decydują się wtedy na praktyki typu swarming albo mob programming. Polegają one na skupieniu się Developerów nad jednym wymaganiem na raz, by jak najszybciej doprowadzić do jego realizacji i dopiero wtedy przejść do kolejnego.

Spadek przejrzystości

Mniej oczywistą konsekwencją długich iteracji jest obniżenie przejrzystości jednocześnie w dwóch wymiarach. Pierwszy związany jest z Developerami: jeśli praca rozkładana jest na wiele tygodni, dużo trudniej zauważyć zjawisko tzw. płynięcia, czyli braku realnych postępów mimo wytężonych działań. Wydaje się, że niewiele brakuje do końca, że „już prawie wszystko działa” itd.

Nieefektywność stosowanych praktyk i narzędzi też przestaje być widoczna, bo zazwyczaj udaje się jakoś większość wymagań zrealizować, nie ma więc bolesnego bodźca, by dokonywać usprawnień. W krótkim Sprincie nieefektywność i zła organizacja pracy zaczynają być dużo szybciej zauważalne, bo czasu i możliwości do zmarnowania nie jest w nim za wiele.

Drugi aspekt spadku przejrzystości dotyczy interesariuszy. Mogą zostać zgubieni po drodze, skoro stykają się ze Scrumem tylko raz na miesiąc: przestają rozumieć, co dzieje się z produktem, a z drugiej strony Zespół traci zrozumienie ich bieżących potrzeb, które przecież mogą się dynamicznie zmieniać. To owocuje spektakularnymi porażkami, gdy np. przez miesiąc budowane ciężkim wysiłkiem chłopa i robotnika jest coś, co okazuje się całkowicie zbędne.

Oczywiście działania Product Ownera mogą temu zapobiec, ale zdecydowanie trudniej o utrzymanie zaangażowania interesariuszy, gdy czekają oni na zmiany w produkcie wiele tygodni, niż gdy nowe rzeczy mają okazję się zobaczyć i wypróbować co kilkanaście dni.

Świat nie jest czarno-biały

Oczywiście nie jest tak, że długie Sprinty są z definicji złe. Bez wątpienia dają szansę na dokonanie większej liczby zmian w produkcie, niż Sprinty krótkie, dzięki czemu interesariusze nie mają na koniec iteracji poczucia niedosytu (a przynajmniej nie powinien mieć, jeśli Developerzy potrafią dobrze wykonywać swoją pracę). Jeśli środowisko, w jakim budowany jest produkt, jest bardzo stabilne, a potrzeby interesariuszy nie zmieniają się szybko, długie Sprinty mogą być dobrym wyborem.

Innym pozytywnym aspektem długich Sprintów jest możliwość realizacji dużych elementów Backlogu Produktu bez konieczności ich dekompozycji na kilka mniejszych. Przy czym tu należy mieć świadomość pułapki: poprzez taką dekompozycję oddziela się często ziarno od plew – rzeczy naprawdę potrzebne od tych zbędnych. A i sama dyskusja o sposobie podziału wymagań ujawnia, że nie wszystko jest w nim zrozumiałe albo że różnie jest ono interpretowane – a to daje szanse na doprecyzowanie i uniknięcie pomyłek.

Kiedy długi Sprint ma sens?

Właściwie tylko wtedy, gdy zmienność jest umiarkowana, a charakter produktu (technologia, uwarunkowania prawne, standardy) wymagają realizowania czynności, które są czasochłonne. Przy czym czasochłonność ta nie może wynikać ze złej organizacji pracy Zespołu lub braku kompetencji u Developerów, ale z obiektywnych przesłanek. Na przykład, jeśli warunkiem uznania produktu za ukończony jest poddanie go testom wytrzymałościowym, które – z powodów technologicznych – trwają tydzień, to nie jest możliwe budowanie tego produktu w tygodniowych iteracjach.

Zdecydowanie nie jest dobrym powodem stosowania długich Sprintów marny poziom developmentu. Jeśli Developerzy kiepsko organizują swoją pracę i są niewystarczająco wykwalifikowani, wydłużenie iteracji może wyrugować element presji, dzięki której pojawiać zaczęłyby się usprawnienia. Nie oznacza to, że przy doborze czasu trwania Sprintu całkowicie bez znaczenia są możliwości Developerów (i całego Zespołu) – oczywiście trzeba je brać pod uwagę – ale warto unikać zakonserwowania mało optymalnego status quo poprzez przyzwolenie na pracę w miesięcznych iteracjach.

Zbyt krótkie Sprinty…

Bardzo krótkie Sprinty pozwalają szybko reagować na potrzebę zmian za cenę tego, że niewiele się w nich udaje zrealizować. To może mieć sens w niektórych organizacjach, ale należy przy tym kierować się zdrowym rozsądkiem.

Do tego pojawi się konieczność podziału elementów Backlogu Produktu na wiele mniejszych tylko po to, by dało je się upchnąć w Sprincie. W skrajnym przypadku może to spowodować, że dyskusja o dekompozycji potrwa dłużej niż sama realizacja takich wymagań.

Jeśli interesariusze nie jest gotowi do częstego uczestnictwa w Przeglądach Sprintów, a te będą się odbywać co kilka dni, pojawi się zmęczenie tym procesem i spadek zaangażowania. Niekoniecznie się to opłaci, tym bardziej że może pojawić się jeszcze jeden problem – poczucie, że zmiany dokonywane w kolejnych Sprintach są mało znaczące i tak naprawdę warto porozmawiać o produkcie tylko co dwie-trzy iteracje.

Złota zasada

Zasada, która nie została zapisana w definicji Scruma, ale jest oczywistym wnioskiem z jego lektury, jest taka: Sprinty powinny być jak najkrótsze, by ograniczać ryzyko inwestycyjne, ale wystarczająco długie, by przynosić wartość interesariuszom.