Dzień 10 – Jak zajrzeć w przyszłość?

Ten post jest częścią cyklu Pierwsze Dni Scrum.

W rozmowach z osobami zainteresowanymi Scrum’em często przewija się kilka mitów, np.:

1. “W Scrum nie da się planować dłużej niż na sprint.”
2. “Nie możemy zastosować Scrum, bo potrzebujemy przewidywalności jaką daje nam precyzyjny harmonogram.”
3. “Nie stać nas na częstą integrację i testowanie przez cały projekt – wszystko sprawdzimy na końcu.“
4. “Scrum nie nadaje się do projektów fixed-price.“

Dzisiaj zajmiemy się naprostowaniem tych nieporozumień odpowiadając na trzy pytania:

1. Jak zwiększyć przewidywalność i ograniczyć ryzyko w naszych projektach?
2. Co jeśli musimy zobowiązać się do konkretnej daty, zakresu i ceny projektu?
3. Jak dostarczyć więcej wartości mniejszym kosztem?

Jak zwiększyć przewidywalność i ograniczyć ryzyko?

Zacznijmy od innego pytania: Jak bardzo szczegółowy harmonogram projektu z jednym dużym wdrożeniem na końcu pomaga nam zabezpieczyć się przed ryzykiem opóźnienia?

Nie za bardzo!

Harmonogramy tego typu wpadają w pułapkę iluzorycznej precyzji. Dokładne rozpisanie poszczególnych faz nie chroni nas przed opóźnieniami. Większość problemów w projektach informatycznych wykrywana jest podczas integracji i szczegółowego testowania (problemy techniczne) i testów akceptacyjnych z użytkownikami (problemy biznesowe). Czy możemy sobie zatem pozwolić na zostawienie tych prac na sam koniec projektu? Scrum mówi, że nie: chcemy jak najszybciej integrować, testować i pokazywać Klientom kolejne fragmenty projektu, żeby jak najszybciej wykryć problemy i móc je rozwiązać zanim urosną do przytłaczających rozmiarów.

A jak Scrum pomaga planować na wiele sprintów do przodu?

Po pierwsze potrzebujemy oszacowanego (w jednostkach względnych) backlogu. Przed rozpoczęciem prac szacujemy tempo naszego zespołu w oparciu o nasze najlepsze przewidywania. Na tym etapie pewność nadal może być niska. Sytuacja diametralnie zmienia się już po kilku sprintach, w których uda nam się dostarczyć domknięte (zintegrowane, przetestowane, zrefaktorowane, udokumentowane, itd.) funkcjonalności.

Mając przed oczami jedyną realną miarę postępu w postaci dostarczonego oprogramowania możemy znacznie odważniej spojrzeć w przyszłość. Ekstrapolując dalsze postępy na podstawie średniego tempa z poprzednich trzech sprintów lub na oko wydłużając pesymistyczny i optymistyczny wariant możemy odpowiedzieć na pytania: Na kiedy dostarczymy cały backlog? albo Ile dostarczymy do świąt? Odpowiedzią będą przedziały: “prawdopodobnie między … a …” oraz “co najmniej … i raczej nie więcej niż …“.

Co jeśli musimy zobowiązać się do konkretnej daty, zakresu i ceny projektu?

Powyżej zobaczyliśmy jak Scrum pozwala wyraźniej ocenić sytuację w projekcie. Z drugiej strony wiedza ta nadal nie przekłada się na gwarancję i nadal Właściciel Produktu nie może narzucić zespołowi realizacji konkretnego zakresu w kolejnych sprintach (może jedynie dbać o to, żeby na szczycie backlogu były najbardziej wartościowe elementy i monitorować dalsze postępy w ich dostarczaniu). Co więc, jeśli chcemy starać się o kontrakt fixed-everything, czyli z ustaloną ceną, datą dostarczenia i wymaganym zakresem? Czy Scrum uniemożliwia nam realizację takich projektów?

Oczywiście, że umożliwia! Tradycyjny harmonogram również nie gwarantuje powodzenia, a kwestia czy dostawca powinien wziąć na siebie ryzyko związane z takim projektem to decyzja biznesowa całkowicie niezależna od sposobu realizacji projektu. Jedyne co zmienia Scrum to to, że szybciej nastąpi konfrontacja z rzeczywistością, dzięki czemu będziemy mogli szybciej podjąć działania naprawcze.

Jak dostarczyć więcej wartości mniejszym kosztem?

Jak już niejednokrotnie widzieliśmy, iteracyjne i inkrementalne dostarczanie produktu sprint po sprincie pozwala nam szybciej dostarczać wartość Klientom (funkcja dostarczona teraz jest warta więcej niż ta sama funkcja dostarczona za kilka miesięcy) oraz szybciej porzucić ślepe zaułki technologiczne i biznesowe (w efekcie tworząc produkt lepszej jakości i lepiej dopasowany do realnych potrzeb).

Oprócz tego dostajemy jeszcze jedną korzyść: W Scrum najbardziej wartościowe funkcje dostarczane są blisko początku projektu. Oznacza to, że po pewnym czasie kolejne porcje funkcji mają coraz mniejszą wartość.

Daje nam to większą elastyczność w podejmowaniu decyzji o zakończeniu projektu i postawieniu przed zespołem bardziej wartościowych wyzwań. Jeśli projekt zajął nam dłużej niż przewidywaliśmy możemy zrezygnować z przedłużania go bez dużej utraty wartości (to duża różnica, bo projekt waterfall w takiej sytuacji nie byłby w stanie dostarczyć nic!) albo jeśli wszystko idzie zgodnie z planem możemy wspólnie z Klientem zdecydować by wcześniej zakończyć projekt i podzielić się oszczędnościami.

Uzupełniając tą ostatnią możliwość o opcję wymiany niezrealizowanych wymagań (z zachowaniem pracochłonności) w trakcie trwania projektu otrzymyjemy model kontraktu znanego “money for nothing and your change for free“, który jest dla obu stron nie-gorszy niż kontrakt fixed-everything i pozwala skorzystać z zalet zwinności bez utraty (złudnego?) poczucia bezpieczeństwa jakie dają takie kontrakty.

 Pytania dla Was:

1. Jak często dostarczacie projekty zgodnie z uzgodnionymi terminami?
2. Czy regularny rytm dostarczania pozwoliłby Wam zwiększyć zaufanie i satysfakcję Waszych odbiorców do tego stopnia, żeby nie czuli potrzeby wymuszania długoterminowych zobowiązań?
3. Czy jesteście przekonani, że tradycyjne kontrakty wykluczają zwinność?
4. Jak często pod koniec projektu wykrywacie problemy, które wykryte wcześniej kosztowałyby Was dużo mniej?
5. Czy na bieżąco odpowiadacie na pytanie o wartość kolejnych przyrostów i porzucacie projekty, w których jest ona zbyt niska (bez widoku na poprawę)?