No i znów nam się nie udało… Co zrobić, jeśli się nie udało? Jak mamy sobie poradzić w sytuacji, w której nie zrealizowaliśmy całego zakresu Sprintu?
Continuous Improvement
Niby zespół jest samozarządzający, niby prawie wszystko zależy od nas, ale gdzieś na końcu jest Cel Produktu. Niezrealizowany zakres Sprintu mocno na niego wpływa. Co z tym począć?
Mamy cały czas się uczyć. Tak mówią założenia zwinnych metodyk i jak najbardziej są prawdziwe. Ten kto się nie uczy, ten nie robi postępów. A my przecież chcemy realizować więcej i lepiej. Nauka i ciągły postęp wiążą się nieuchronnie z popełnianiem błędów. Wszystko dobrze do momentu, aż błędy nie przeradzają się w rutynę.
Często jest tak, że zanim odkryjemy nasze Velocity musi minąć trochę czasu. Ile to jest trochę? Dla jednych będą to dwa Sprinty, dla drugich dziesięć. Nie ma tutaj reguły. Jest za to to jedna dobra zasada. Ciągłe doskonalenie powinno powodować, że w naszych przypuszczeniach będziemy coraz lepsi. Raz przeszacujemy, raz niedoszacujemy, ale będziemy się planować coraz lepiej. Z biegiem czasu będzie coraz mniej elementów, które nie zostaną zrealizowane.
Oczywiście, że dążymy do wartości 0 (zero). Nic nie spada ze Sprintu, wszystko jest realizowane do końca. Taka sytuacja będzie jednak należała do rzadkości. Jest przecież tyle zmiennych, które wpływają na powodzenie naszej Iteracji. Jak dobrze wiemy, wielu rzeczy po prostu nie przewidzimy.
Niezrealizowany zakres Sprintu
Nie będę pisał o tym, co powinno zadziać się z niezrealizowanym zakresem Sprintu. Tomek zawarł to w tekście, który szczegółowo opisał, jak powinniśmy postępować ze spadami w takiej sytuacji. Znajdziecie tam informacje także o tym, jak podejść do re-wyceny wymagań. Skupmy się zatem nad konsekwencjami.
Część z Was może pomyśleć, „co może stać się wielkiego, jesteśmy z winni, mamy jeszcze tyle Sprintów przed nami?„. Niby jest to prawda. Pracując zwinnie, pracujemy w sposób ciągły i zasadniczo jak nie teraz, to zaraz. Ale jak to w życiu bywa, prawda jest o wiele bardziej skomplikowana.
Niezrealizowany zakres wpływa bardzo na plany rozwoju naszego Produktu. Dość powiedzieć, że Product Owner po zakończeniu Sprintu, którego nie udało się w całości zrealizować, musi podjąć trudną decyzję o tym co zrobić z niedokończonymi elementami. Realizować je w kolejnej iteracji, czy może wstrzymać się, bo Backlog najeżony jest wieloma ważnymi funkcjonalnościami dla naszego Klienta?
Co więc zrobić ze spadami?
Dług technologiczny
Warto tutaj zwrócić uwaga na pewną rzecz. Niektórzy błędnie sądzą, że ta niezrealizowana część Backlogu, którą rolujemy między Sprintami, albo która powoduje opóźnienia w realizacji poszczególnych części naszego Produktu to dług technologiczny. Jak już pisaliśmy, wcale tak nie jest. Możemy to nazwać po prostu „spadami”, konsekwencjami braku Refinementu Backlogu lub po prostu złego Planowania Sprintu. Nazywajmy rzeczy po imieniu, a długiem nazywajmy faktyczny dług!
Dług technologiczny to świadome odroczenie realizacji części funkcjonalności w czasie. „Świadome” oznacza, że musieliśmy to przewidzieć, że nie może być to konsekwencja braku spełnienia kryteriów akceptacji czy kryteriów Definition of Done. W przypadku spadów nie mamy do czynienia z takim zjawiskiem, nie mówmy więc o długu technologicznym.
Zresztą, jeśli jakaś część naszej funkcjonalności nie została zrealizowana to nie tylko nie mamy żadnej wartości biznesowej. Nie możemy także zaakceptować (ani pokazać na Sprint Review) całego wymagania. Nie może być więc tu mowy o żadnym długu.
Poważne konsekwencje
Konsekwencje niezrealizowanego Sprintu to nie tylko kłopot dla Product Ownera, praca dla Scrum Mastera czy utrudnienie dla Zespołu. Trzeba będzie poświęcić trochę czasu na ustaleniu przyczyny, a w kolejnym Sprincie trzeba będzie „się sprężyć”. Nie możemy udawać, że zwinny projekt to wyłącznie Deweloperzy, którzy dostarczają produkt dla interesariusza i konsekwencje zamykają się wśród tej grupy ludzi.
Często Zespołów jest więcej niż jeden, a prócz nich występują również Project Manager, PO i inne osoby wspierające zarządczo nasze przedsięwzięcie. Można więc powiedzieć, że konsekwencje nieudanych Sprintów rozleją się po całym projekcie/produkcie. A to może stać się już problematyczne.
Aby uniknąć tej sytuacji w przyszłości, musimy zastanowić się, jaki jest powód tego stanu rzeczy. Dwa z nich podałem powyżej. Wydaje mi się, że są na tyle znaczące, że możemy od nich zacząć.
Niezależnie od powodów, rozwiązanie leży po stronie Zespołu. Jako oczyszczenie, krok wstecz, można potraktować działanie polegające na bezpiecznym zaplanowaniu się. Weźmy mniej, np. 75% naszego Velocity z ostatnich 3-5 Sprintów i tym razem zrealizujmy cały zakres. Będzie to miało dwie konsekwencje. Ta ważniejsza to czynnik motywacyjny – w końcu zrobimy 100%. Ta druga związana jest ze świeżymi danymi na temat naszych możliwości. Kto wie czy te nie są istotniejsze. Będą przecież punktem odniesienia do kolejnego Sprintu, który – jak już pokażemy, że potrafimy dowieźć 100% – możemy zaplanować ambitniej. Ale dopiero wtedy, nie wcześniej.
