Jak się ma ryzyko w Scrum? 

Ryzyko w Scrum to temat, który bardzo często bywa przemilczany. Przecież mamy krótkie Sprinty, ryzykiem zarządzamy na bieżąco. Ale czy tak jest naprawdę?

Ryzyko – szansa czy zagrożenie

Scrum nie został stworzony do zarządzania projektem. Na próżno szukać w Scrum Guide choćby opisu planowania wykorzystania zasobów ludzkich czy jakości projektów. Podobnie, choć nie tak samo rzecz ma się z ryzykiem. Chociaż nie zaadresowano go wprost, Scrum je mityguje. Dziś zastanowimy się nad tym, czy ryzyko w Scrum zostało potraktowane z należytym pietyzmem.

Ryzyko z punktu widzenia projektu należy i trzeba rozpatrywać z punktu widzenia zagrożenia lub… szansy. Podobnie jak w codziennym, prywatnym życiu również i w projekcie możemy podjąć ryzyko, które przyniesie nam nieoczekiwaną korzyść.

Mówiąc o ryzyku, zarówno tym pozytywnym jak i negatywnym, zawsze powinniśmy zdawać sobie sprawę z faktu, iż może się ono zmaterializować. Aby być na to przygotowanym oszacujmy skutki wystąpienia ryzyka, a następnie podejmijmy decyzję, czy jesteśmy na nie przygotowani.

Jeśli prowadząc nasz projekt decydujemy się na zastosowanie rzadko używanej biblioteki, podejmujemy ryzyko. Jego materializacja może doprowadzić do przyśpieszenia prac (ryzyko pozytywne) lub do „straty” czasu w przypadku, gdy okaże się, że biblioteka nie spełnia pokładanych w niej nadziei. Celowo ująłem słowo „strata” w cudzysłowie. Każda porażka może nas czegoś nauczyć, jeśli tylko będziemy chcieli wyciągnąć z niej wnioski!

Ryzyko prowadzenia projektu

Jak mówiliśmy podczas naszego wystąpienia na Agile Warsaw, ryzyko nieukończenia dużego przedsięwzięcia, niezależnie od przyjętej metodyki jest bardzo wysokie. Odsetek projektów, które już na starcie są niejako skazane na porażkę jest bardzo duży. Na pewno im większy projekt, tym większa szansa, że się nie powiedzie.

Jakie są przyczyny takiego stanu rzeczy? Dużo by o tym pisać. Na pewno jedną z ważnych kwestii jest horyzont czasowy trwania projektu oraz zmienność i niepewność wymagań. Mam wrażenie, że wymienienie wszystkich przyczyn wypełniłoby cały ten wpis, a może i krótką książkę.

Dlaczego wiedząc, że tak dużo projektów już na starcie moglibyśmy przypisać do grupy ryzykownych, pchamy się w tę grę? Jedną z odpowiedzi jest to, że zamawiający chce od nas realizacji tego projektu i już. Nawet jeśli klient się myli, czasami „musimy” w to pójść.

Innym powodem jest ślepe zaufanie w umiejętności przewidywania i zaplanowania reakcji na ryzyka. Wydaje nam się, że jesteśmy na nie przygotowani. Jak jednak pokazuje casus Black Swan istnieje wiele niewiadomych, o których wystąpieniu nawet nie myślimy, a których wystąpienie będzie dla nas bardzo bolesne.

Nie możemy przewidzieć wystąpienia tych najgorszych ryzyk, ale za to możemy spróbować się na nie przygotować. W jaki sposób to zrobić?

Ryzyko w Scrum

„Ryzyko w Scrum nie istnieje!” – to oczywista nieprawda. Ryzyko nie tylko istnieje, ale jest dokładnie takie samo jak w projektach prowadzonych metodą klasyczną. Przecież jedne i drugie projekty są dokładnie takie same, prowadzą do osiągnięcia dokładnie tych samych rezultatów. Czy więc się różnią? Podejściem, sposobem myślenia, organizacją pracy.

Czy jest sens zastanawiać się nad tym, czy ryzyko X wystąpi? Czy będąc w pierwszym miesiącu realizacji projektu mogę przewidzieć, że Kowalski w czwartym miesiącu otrzyma lukratywną ofertę pracy, z której skorzysta? Jasne, że nie. Nie jesteśmy w stanie tego przewidzieć, ale jesteśmy w stanie w jakiś sposób się na to przygotować.

Oczywiście, jest grupa ryzyk, które bardzo łatwo przewidzieć i zaplanować banalnie proste akcje. Najprostszy z możliwych przykładów – ryzyko kursowe. Akcja, która będzie nas zabezpieczała przed jego wystąpieniem? Derywaty. W przypadku tego typu ryzyka możliwość jego wystąpienia należy ocenić jako wysoką. Istnieją jednak narzędzia, które nas przed nim zabezpieczą.

Scrumowe pomysły

Pomysłem, który w kontekście Scruma przychodzi mi do głowy jako pierwszy, to maksymalne skrócenie długości iteracji. Jaki jest sens planowania np. 6-miesięcznej kadencji, kiedy po drodze może się zmienić praktycznie wszystko. Od składu Zespołu Deweloperskiego po wymagania. Skróćmy ten czas do rozsądnego minimum i planujmy jedynie najbliższą przyszłość. Będziemy w ten sposób w stanie szybko odpowiedzieć na pojawiające się niekorzystne uwarunkowania naszej pracy.

Inną kwestią jest ścisła współpraca z klientem. Współpraca, a nie ślepe wykonywanie jego poleceń czy narzucanie swojej wizji implementacji rozwiązania. Mówi o tym zresztą jasno Agile Manifesto:

Współpraca z klientem > negocjacja umów

Współpraca z klientem mityguje ryzyko. Nawet, jeśli interesariuszowi naszego projektu nie przypadnie do gustu przygotowane rozwiązanie, to jest ono na tyle małe i poświęciliśmy mu na tyle mało czasu, że zmiana nie powinna pociągnąć za sobą dużych konsekwencji. Musimy zmienić tylko to, co wytworzyliśmy w ostatniej iteracji. A ponieważ jest ona rozsądnie krótka, nie będziemy musieli zmieniać całego systemu.

„W zespole siła.” Zespół, który współpracuje, zna swój Backlog Produktu i aktywnie uczestniczy w jego doskonaleniu sam znajdzie ryzykowne obszary i wymagania. Odpowiedzialny i silny zespół przygotuje się na wystąpienie  ryzyka, które sam znalazł. Przecież jak mówi jedna z 12 zasad zwinnego tworzenia oprogramowania:

Najlepsze rozwiązania architektoniczne, wymagania i projekty pochodzą od samoorganizujących się zespołów

Jeśli Kowalski będzie chciał opuścić projekt, zespół będzie o tym wiedział. I przygotuje się na to wydarzenia najlepiej jak będzie potrafił. Samoorganizacja jest kluczem do sukcesu.

Czy to wszystko?

Powyższe to zaledwie wierzchołek góry lodowej. Nie odkryliśmy Ameryki, ale przyglądając się paru prostym zasadom po raz kolejny do wniosku, że już dziś posiadamy narzędzia pozwalające nam zarządzać ryzykiem. I to również, a może nawet – tym bardziej – w Scrum. Nawet nie myślimy o tym, że wszystkie mechanizmy scrumowe, które wykorzystujemy bez zastanowienia, pomagają nam ograniczyć ryzyko.

Dlaczego więc nie skorzystać z nich jawnie do ograniczania ryzyka? Zawsze ciekawie mnie, jak patrzą na ryzyko Project Managerowie. Być może, przyzwyczajeni do trochę innego stylu pracy, mogą uważać „nasze” podejście za lekkomyślne. Ale może się mylę?

Zachęcam Was do dyskusji. Jest to temat, który w jakiś sposób dotyka nas wszystkich. Przecież wszyscy pracujemy na powodzenie naszych projektów i jesteśmy za nie w jednakowy sposób odpowiedzialni.