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, na zmianę zakresu realizowanych prac. W ciągu miesiąca, mogą pojawić się potrzeby wielokroć ważniejsze niż te, nad którymi obecnie pracuje zespół developerski. Bywa tak, że ani developerzy, ani nawet Product Owner nie są w stanie przeciwstawić się skutecznie tej presji i zaczyna się bałagan. W takiej sytuacji najlepszym wyjściem jest skrócić sprinty, żeby biznes był 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ą jest większe niż dla krótkich sprintów, ryzyko pójścia w złą stronę. Można powiedzieć, że koszt pojedynczej iteracji to maksymalny koszt 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 kierunek rozwoju produktu jest dobry czy  wymaga korekty.

Planowanie czy wróżenie z fusów?

Długie sprinty mają wadę również z punktu widzenia zespołu developerskiego. Bo choć niezaprzeczalnie dysponuje on wtedy większą ilością czasu na realizację podjętych do sprintu elementów backlogu produktu, to z drugiej strony zmuszony jest do planowania (a więc przewidywania) co może podziać się w perspektywie na przykład miesiąca, a nie tygodnia lub dwóch. Takie plany w oczywisty sposób będą mniej precyzyjne, a przebieg sprintów mniej przewidywalny.

Waterfallu, witaj ponownie!

Pojawi się też okazja, by powróciło stare, ale niekoniecznie dobre podejście kaskadowe. Mając do dyspozycji miesiąc, jeśli wciąż uczymy się pracy zespołowej, możemy łatwo ulec pokusie podzielenia sobie pracy w sprincie na fazy: analizy, developmentu i testów. Gdy mamy w sprincie tylko kilka dni, taki podział właściwie skazuje nas na niepowodzenie, bo te fazy stałyby się koszmarnie krótkie, więc zespół nie próbuje (z niechlubnymi wyjątkami) organizować sobie pracy w ten sposób.

Spadek przejrzystości

Mniej oczywistą konsekwencją długich iteracji jest obniżenie przejrzystości, przy czym ma to aż dwa wymiary. Pierwszy, związany z samym zespołem developerskim: na przestrzeni wielu dni dużo trudniej zauważyć, że „płyniemy”, że narzędzia i praktyki jakie stosujemy są mało efektywne. Wszak na koniec, jakoś się „udaje” zdążyć. W krótkim sprincie nieefektywność i zła organizacja pracy zaczynają być dużo szybciej zauważalne.

Drugi aspekt spadku przejrzystości dotyczy interesariuszy, którzy mogą zostać „zgubieni” po drodze, skoro stykają się ze Scrumem tylko raz na miesiąc. Oczywiście działania Product Ownera mogą temu zapobiec, ale zdecydowanie trudniej o zaangażowanie, jak czeka się na działający produkt kilka tygodni niż wtedy, gdy nowe rzeczy ma okazję się zobaczyć i wypróbować co kilkanaście dni. A spadek zainteresowania interesariuszy przełoży się wcześniej czy później na mniej efektywne przeglądy sprintów.

Świat nie jest czarno-biały

Oczywiście nie jest tak, że długie sprinty są inherentnie złe. Są sytuacje, gdy nie da się ich uniknąć.

Bez wątpienia dają szansę na zrobienie większej ilości elementów backlogu produktu niż sprinty krótkie. Dzięki temu biznes, jak już otrzymuje nową wersję produktu, nie ma poczucia niedosytu (a przynajmniej nie powinien mieć, jeśli zespół developerski działa efektywnie).

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ę „ziarno od plew”, rzeczy naprawdę potrzebne od tych zbędnych. Sama dyskusja o sposobie podziału wymagań często 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, 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 raczej nie będzie taki produkt realizowany w tygodniowych iteracjach.

Zdecydowanie nie jest dobrym powodem do zdefiniowania długich sprintów niewydolność zespołu developerskiego. Jeśli kiepsko organizuje swą pracę i jest słaby technologicznie, wydłużenie iteracji może wyrugować element presji, dzięki której pojawiać zaczęłyby się usprawnienia. Nie oznacza to, że całkowicie bez znaczenia są możliwości 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 sprintach.

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.

W kilkudniowej iteracji mało damy radę zrobić, 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 biznes nie jest gotowy do ciągłego 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 aspekt – poczucie, że zmiany dokonywane w kolejnych sprintach są mało znaczące i tak naprawdę warto porozmawiać o produkcie tylko co dwie-trzy iteracje.

Jeśli więc pojawia się feedback „czemu tak małe są te zmiany, czy opłaca się dzielić pracę na takie kawałeczki?”, warto rozważyć wydłużenie sprintów.