Zarządzanie ryzykiem w projekcie IT – ryzyko w Scrumie

Zarządzanie ryzykiem w Scrumie

W Scrum Guide – głównym źródle wiedzy o podstawach tej metodyki – słowo “ryzyko” pojawia się tylko trzykrotnie.

Po raz pierwszy, gdy autorzy podkreślają, że iteracyjne podejście do realizacji projektu, czyli praca w sprintach, pomaga optymalizować ryzyko. Po raz drugi, gdy nawiązują do długości sprintu: jeśli trwa powyżej miesiąca, wówczas ryzyko wzrasta, ponieważ długoterminowe planowanie nie pozwala wystarczająco elastycznie reagować na zmiany. Po raz ostatni ryzyko jest wspomniane w kontekście artefaktów Scruma – brak transparentności stanowi zagrożenie dla realizacji projektu.

W pełni zgadzam się z takim ujęciem ryzyka. Nie tylko Scrum Guide, lecz także inne publikacje związane z tą metodyką, wskazują na zarządzanie ryzykiem jako na istotny element trybu pracy w podejściu iteracyjnym. Oznacza to, że potencjalne ryzyka są monitorowane na bieżąco – w trakcie planowania sprintu, daily stand-up, sprint review oraz retro – w momencie pojawienia się, są włączane do rejestru sprintu lub rejestru prodktu.

Czego Scrum nie obejmuje?

Czy możemy zatem uznać, że wystarczy przestrzegać reguł?

Moim zdaniem, nie do końca. Scrum – co nie dla wszystkich jest tak oczywiste – to nie metodyka zarządzania projektami, lecz styl pracy z zespołem w środowisku zwinnym. Rolą Scruma nie jest nazwanie wszystkiego, co wiąże się z projektem i co może się w nim wydarzyć. Wystarczy wymienić obszary nie uwzględnione w Scrum Guide, np. procurement czy zarządzanie budżetem (pisaliśmy o tym w tekście Klocki zamiast linii, czyli o szybkim osiąganiu ROI w projektach IT) W przypadku ryzyka, fakt, że zostało ono opisane zarówno w Scrum Guide, jak i wielu innych publikacjach, może prowadzić do błędnego wniosku, że wyczerpują one temat.

Oczywiście, stosując się do prostych reguł Scruma, można uniknąć wielu zagrożeń, ale nie wszystkich. Istnieją rodzaje ryzyka oraz okoliczności związane z prowadzeniem projektu, które są nie tylko niezidentyfikowane przez zespół, ale także niebędące dodatkiem do rejestru produktu.

W trakcie spotkań w procesie scrumowym zespół deweloperski oraz interesariusze zajmują się  identyfikacją ryzyk, lecz jak potwierdza praktyka, zazwyczaj dotyczą one technologii, zależności między wymaganiami, czasu, kosztów utrzymania czy doprecyzowania wymagań.

To są absolutnie krytyczne aspekty projektu, jednak czy w trakcie tych spotkań zastanawiamy się nad ryzykami wyższego poziomu? Finansowanie projektu w następnym roku, legalność rozwiązań, ogólne reguły zarządzania firmą, zagrożenia płynącę z rynku pod postacią konkurencji czy też nowe regulacje to zaledwie kilka z nich.

Nawet jeśli uwzględnimy powyższe ryzyka, to co realnie możemy zrobić, aby im zapobiec? Nie możemy po prostu wrzucić do rejestru produktu ryzyka o treści  “Za 3 miesiące może nam się skończyć budżet”.

Z drugiej strony, co z na pozór drobnymi czynnikami, takimi jak licencje na oprogramowanie, planowane urlopy, nastawienie poszczególnych osób decyzyjnych do konkretnego rozwiązania? W tych obszarach również może wydarzyć się coś, co postawi pod znakiem zapytania końcowy sukces produktu.

Część osób być może powie: “Tak, za każdym razem bierzemy to wszystko pod uwagę”.  Jeśli tak jest – gratuluję. Przyznaję, że mi nie zawsze się to udaje. Również Scrum Guide, w części poświęconej sprint review, zaleca skupienie się nad szerszym aspektem produktu, niż tylko sprawach ściśle związanych z pracą bieżącą.

Traktuję to jako jeden z wielu obszarów pozostawionych zespołom scrumowym: aby we własnym zakresie zaplanowały sposób radzenia sobie z tymi czynnikami.

Moim zdaniem, szeroka analiza ryzyk, które, jak wynika  z powyższych przykładów, mogą mieć ogromny wpływ na projekt, jest bardzo istotna. Jednak w trakcie spotkań scrumowych często bywa ona nieefektywna, ponieważ ich uczestnicy skupiają się na skali mikro, tj. obecnym oraz najbliższym sprincie.  Tracą wtedy z pola widzenia inne zagrożenia i nie są w stanie w pełni ocenić rozmiaru ryzyka.

Obawiam się też, że zespół deweloperski będzie umiarkowanie zainteresowany omawianiem wielu wymienionych przypadków, a czasem wręcz nie będzie posiadał wystarczających kompetencji. Natomiast, zapraszanie na spotkania coraz to nowych zewnętrznych ekspertów, może doprowadzić do utraty skupienia na rozwoju produktu, zbyt szerokiej dyskusji i ogólnego zniechęcenia do tego typu spotkań.

Podsumowanie

Jak widać, nawet projekt zwinny wymaga dodatkowych działań w zakresie zarządzania ryzykiem. I choć iteracyjne podejście jest tu bardzo pomocne, pewien automatyzm i naturalne następowanie po sobie czynności w cyklu dostarczania produktu mogą uśpić naszą uwagę na wiele kategorii ryzyk i doprowadzić do fałszywego poczucia kontroli nad projektem.

W następnym artykule z serii omówię kilka prostych sposobów na uchwycenie zagrożeń w projekcie. Skupię się zarówno na rozwiązaniach przydatnych w mniej skomplikowanych projektach, kiedy nie chcemy spędzać zbyt wiele czasu na rozważaniach o ryzyku, jak i tych, które sprawdzą się w bardziej złożonym projekcie, prowadzonym w środowisku korporacyjnym – gdzie musimy wziąć pod uwagę znacznie więcej czynników niż tylko te, wynikające bezpośrednio z  projektu.