Kiedy na szkoleniu ze Scrum pojawia się uczestnik związany z zarządzaniem projektami, pojawia się pytanie “Gdzie w Scrum jest rejestr ryzyk?”. Odpowiedź w prost na to pytanie brzmi “Nie ma”. Ale o nie oznacza, że w Scrum nie zarządzamy ryzykiem. Mamy kilka mechanizmów, które nam w tym pomagają.

Zarządzanie Ryzykiem przez Product Backlog

Ryzyko powinno być jednym z parametrów, które Product Owner bierze pod uwagę w układaniu porządku na Backlogu Produktu. Jeśli element reprezentuje duże ryzyko produktowe — związane z produktem bądź projektowe — związane z wykonaniem pracy, taki element powinien być wysoko na liście. Przykłady: nie wiemy czy technologia pozwoli na zbudowanie produktu; musimy dostarczyć tą funkcjonalność, żeby uniknąć kary albo zdążyć na ważną datę; nie wiemy jak tą funkcjonalność zbudować; musimy sprawdzić jak użytkownicy zareagują, żeby podjąć decyzję co do dalszych planów. W ten sposób jak najszybciej zweryfikujemy ryzyko i podejmiemy decyzje na podstawie doświadczeń empirycznych.

Zarządzanie ryzykiem przez Definition of Done

Przy budowaniu produktów mamy ryzyko późnej integracji — okazuje się, że elementy nie działają razem i to odracza wdrożenie. Jest też ryzyko późnej informacji zwrotnej z późno wykonanych testów i albo odkrywamy dużo błędów blokujących wdrożenie albo zmienia się zakres ze względu na wynik testów UAT. Dobra, silna Definition of Done powoduje, że testy mieszczą się w Sprintach i zwiększamy pewność wdrożenia stabilnego, dopasowanego produktu. Jeśli nawet nasza Definition of Done jest słabsza niż gotowy do potencjalnego wdrożenia przyrost, to zwiększamy transparencję co dostarczamy w Sprintach i jaką pracę jeszcze musimy wykonać przed wdrożeniem.

Zarządzanie ryzykiem przez długość Sprintów

Długość Sprintów pomoże nam zapanować nad kilkoma ryzykami.

Pierwsze ryzyko to takie, że Zespół Scrumowy może nic nie dostarczyć, bo na przykład dopiero uczy się nowego sposobu pracy, albo nie zdaje sobie sprawy z przeszkód na swojej drodze. Krótsze Sprinty powodują, że koszt nauki i wyciągnięcia wniosków jest stosunkowo mały i mamy jeszcze dużo czasu na dostosowanie planu, czy wprowadzenie usprawnień.

Drugie ryzyko polega na tym, że zakres może się zmienić. Metody i frameworki Agile zakładają, że zakres będzie się zmieniał. Im mamy większą niepewność co do zrozumienia zakresu lub większą zmienność priorytetów, tym krótsze powinny być Sprinty. W ten sposób szybciej zakres “rozpoznamy bojem” i jesteśmy w stanie zamrozić chociaż mały kawałek Backlogu Produktu, dostarczyć Przyrost i zebrać feedback.

Trzecie ryzyko wiąże się dostarczeniem zakresu (lepiej z osiągnięciem celów biznesowych) na konkretną datę. Każdy Sprint to możliwość do zastosowania mechanizmu Inspect & Adapt. Po każdym Sprincie możemy wyciągnąć wnioski i zweryfikować plan. Przykład: planuje wydanie za trzy miesiące. Jeśli będę miał miesięczne Sprinty, to mam dwie możliwości na Inspect & Adapt, a nawet jedną jeśli w ostatnim Sprincie mam prace związane z wydaniem produktu na rynek. Przy dwutygodniowych Sprintach takich możliwości jest już sześć (pięć nie licząc ostatniego Sprintu). Z tygodniowymi Sprintami jeszcze więcej.

Zarządzanie ryzykiem przez szybkie wdrożenia

Mamy ryzyka związane z produktem i rynkiem. Nie wiemy jak klienci zareagują. Konkurencja nie śpi i może nas wyprzedzić. Mamy unikalne okno możliwości wprowadzenia produktu na rynek. Jeśli będziemy w stanie wdrażać się szybko i wcześnie, to możemy zniwelować te ryzyka. Posiadanie gotowego do potencjalnego wdrożenia Produktu przynajmniej na koniec każdego Sprintu i odpowiednie podzielanie wdrożeń na Przyrosty dostarczające wartość biznesową dają możliwość wczesnych i szybkich wdrożeń.

Zarządzanie ryzykiem przez Sprint Review

Mamy ryzyko związane z tym, że Produkt nie spełni oczekiwań interesariuszy. Może też się zdarzyć, że sytuacja na rynku ulegnie zmianie i trzeba będzie zmienić plany na rozwój Produktu. Dobrze przeprowadzone Sprint Review (pl. Przegląd Sprintu) spowoduje, że otrzymamy informację zwrotną i inne ważne informacje od interesariuszy, podejmiemy wspólnie decyzje i natychmiast odzwierciedlimy je w zmianach w Backlogu Produktu. Aktualny Backlog pozwoli z kolei na korektę planów.

Podsumowanie

W Scrum mamy wbudowane mechanizmy pozwalające na zarządzanie różnymi ryzykami poprzez odpowiednie pętle zwrotne i artefakty. Zarządzanie ryzykiem w Scrum polega głównie na szybkiej eliminacji ryzyka i empirycznego sprawdzania poziomu ryzyka.