W naszym poniedziałkowym filmie poruszyliśmy jedną ważną kwestię – wyjścia z projektu. Jest taki moment, w którym staje się oczywiste, że „z tej mąki chleba nie będzie”. Z drugiej jednak strony, musimy uważać, żeby nie wylać dziecka z kąpielą. Kiedy zerwać projekt?
Przerwanie Sprintu
W tekście omawiającym Sprint powiedzieliśmy o bardzo rzadkim i traumatycznym wydarzeniu, jakim jest przerwanie (anulowanie) Sprintu. Product Owner może podjąć taką decyzję w przypadku, gdy zdezaktualizuje się nam Cel Sprintu. A co z celem bądź sensem projektu?
Przede wszystkim, Scrum nie wspomina o projektach. Po drugie, zwykle chcemy zerwać projekt, bo nie powstaje żaden sensowny rezultat prac. Natomiast nie jest to akceptowalne uzasadnienie nawet do przerwania Sprintu.
Żeby właśnie nie wylewać dziecka z kąpielą, niewypowiedzianą sugestią w Scrum Guide jest kończenie każdego Sprintu, niezależnie od tego jak bardzo źle nam idzie. Następnie zróbmy retrospekcję i spróbujmy naprawić sytuację w następnym Sprincie. Tylko tak możemy się nauczyć pracować lepiej.
Jeżeli zaś chcemy przerwać cały projekt bądź po prostu rozwiązać umowę, tym bardziej powinniśmy najpierw dać sobie szanse na poprawę sytuacji. Gdy pracujemy iteracyjnie, okazje powinny pojawiać się regularnie. Jeśli zaś nie działa fundamentalne zwinne narzędzie pod tytułem Inspect and Adapt, to faktycznie mamy problem.
Pamiętajmy też, że samo przerwanie Sprintu jest dla Zespołu Scrumowego naprawdę traumatycznym przeżyciem. Zastanówmy się więc, jakie konsekwencje dla morale miałoby zerwanie projektu.
Utopione koszty i nie tylko
Pochopne zerwanie projektu nie jest sytuacją, którą powinniśmy się przejmować. W przyrodzie występuje ono bardzo rzadko. O wiele częściej zdarzają się sytuacje odwrotne, gdzie na siłę próbujemy dokończyć coś, co jest z góry skazane na klęskę.
Pomagają/przeszkadzają nam w tym rozmaite błędy poznawcze. O jednym z nich rozpisaliśmy się już w szczegółach. Mowa oczywiście o sunk-cost fallacy, czyli utopionych kosztach. Objawia się on argumentacją pod tytułem „Skoro już tyle utopiliśmy na tym projekcie, to nie możemy zostać z niczym.” Tylko będziemy sobie pluć w brodę, gdy próby „osiągnięcia jakiegokolwiek efektu” będą kosztowały dwa razy więcej, a produkt i tak nie powstanie.
Jakby tego było mało, to w sytuacji, w której już mamy jakiś fragment funkcjonalności bądź rozwijamy już istniejący system, przeszkadzał nam będzie efekt posiadania (ang. endowment effect). Polega on na tym, że dużo wyżej oceniamy wartość rzeczy, które już mamy w stosunku do rzeczy, które planujemy nabyć. A to sprawia, że każdy zrealizowany element backlogu wydaje nam się dużo cenniejszy, niż ten leżący w poczekalni.
Idąc o krok dalej – każda „obiecana” funkcjonalność (np. poprzez priorytetyzację MoSCoW) automatycznie staje się o wiele cenniejsza. Podobnie zadziała zaplanowanie czegoś do realizacji w Sprincie. Większość osób potraktuje to jak obietnicę. A wtedy powiedzenie, że jednak czegoś nie zrobimy zabrzmi dla interesariuszy jak pozbawienie ich czegoś, co już było „ich”.
Dlatego tak ważne jest, by dobrze zarządzać oczekiwaniami i uświadamiać klienta, że backlog to nie załącznik do umowy i wcale nie mamy gwarancji, że wszystkie jego elementy zostaną zrealizowane.
Kiedy zerwać projekt?
Wróćmy więc do podstawionego na wstępie pytania – kiedy zerwać projekt? Ogólna odpowiedź jest dość prosta i zdroworozsądkowa. Przerwijmy prace wtedy, kiedy jesteśmy pewni, że nie uda się wytworzyć wartości biznesowej korespondującej z poniesionymi kosztami.
W przypadku iteracyjnego wytwarzania oprogramowania, taką szansę teoretycznie mamy co Sprint. W praktyce jednak, nie chcemy dokonywać pochopnych decyzji na podstawie jednej czy dwóch kiepskich iteracji. Trudno też nam jest szacować długoterminowo, jeżeli nie posiadamy danych historycznych, bo np. dopiero startujemy. Musimy dać sobie czas.
Z drugiej zaś strony, przeciąganie projektu w nieskończoność „bo w końcu musi się udać” to narażanie się na jeszcze większe koszty i wzmożone ryzyko katastrofy. Trzeba więc znaleźć złoty środek.
W przypadku realiów „projektowych”, takim rozsądnym rozwiązaniem wydaje się umożliwienie przerwania prac po każdym wydaniu (release). Takie fazy możemy oczywiście planować, odbierać i omawiać na retro (patrz też: Release Planning) i wcale nie musimy mieć ich wszystkich określonych z góry na kilka lat. Wystarczy, że będziemy robić to iteracyjnie.
Nie jest to idealne rozwiązanie, ale z jednej strony powstrzymuje nas przed pochopnymi decyzjami (jeden słaby Sprint nie spowoduje odwrotu), a z drugiej nie musimy czekać aż do „końca projektu”, żeby powiedzieć, że nie o to nam chodziło. Musimy jedynie zadbać, żeby w iteracjach faktycznie powstawał używalny Przyrost i żebyśmy mogli go przejąć do dokończenia lub używania w przypadku wyjścia.
Praca ciągła czy projekt?
Na poniedziałkowym Agile Warsaw opowiadaliśmy o tym, że bolączką dzisiejszego „agile’a” jest skupienie się na projektach, a nie na potrzebach biznesowych. Nie rozwiązujemy już problemów, tylko „robimy zwinne projekty”. A jak uczyli mnie na studiach, projekt ma zdefiniowany początek i koniec.
Tymczasem praca zwinna albo skupia się wokół rozwoju jakiegoś produktu albo wręcz na zaspokajaniu rozmaitych potrzeb biznesowych w kreatywny sposób. W tym drugim przypadku trudno jest nam nawet mówić o produkcie, bo nie możemy z góry zakładać, jakie jest optymalne rozwiązanie.
Wciskając się na siłę w ramy określonego rozwiązania tracimy jedną z największych zalet zwinności. Zamiast wymyślać, w jaki sposób można najbardziej efektywnie zaspokoić potrzeby biznesowe, zastanawiamy się li tylko jak ułożyć naszą pracę. I wtedy zwykle ograniczamy się jeszcze bardziej – do ograniczonego czasowo projektu, najczęściej ze z góry zdefiniowaną listą wymagań.
„Procesy zwinne umożliwiają zrównoważony rozwój. Sponsorzy, deweloperzy oraz użytkownicy powinni być w stanie utrzymywać równe tempo pracy w nieskończoność.” – Agile Manifesto
Słowa „w nieskończoność” nie pojawiają się w Agile Manifesto przypadkiem. W podejściu zwinnym pracujemy tak długo, jak to ma sens. Jeżeli korzyści z naszej pracy przekraczają koszty, działajmy dalej. Jeżeli nie – poszukajmy dla tego zespołu innych wyzwań.
Tylko takie postawienie sprawy oczywiście wymaga kompletnej zmiany koncepcji działania naszych „zespołów projektowych”. Ale o tym może innym razem…
