Czy zastanawialiście się kiedykolwiek nad tym, co to właściwie znaczy, że Sprint zakończył się sukcesem? Każdy Scrum Master wcześniej czy później musi zmierzyć się z tym pytaniem. Wydawać by się mogło, że w metodzie opierającej się na prostych regułach łączących precyzyjne zdefiniowane odpowiedzialności, zdarzenia i artefakty (wraz ze zobowiązaniami), nie będzie wątpliwości, co jest miarą sukcesu. A jednak, wątpliwości te się pojawiają.

Może jednak powinienem napisać to nieco inaczej: pojawiają się tak krańcowo różne interpretacje tego, czym jest udany Sprint, że rodzi to wątpliwości, czy wszyscy korzystający z metody Scrum rozumieją jej podstawowe zasady.

Najprościej: udany Sprint = Cel Sprintu został osiągnięty

Cóż, to najprostsza i zarazem najczęściej stosowana definicja sukcesu w Scrum. Nie jest zła, przy założeniu – nie zawsze spełnionym – że ten Cel Sprintu jest rzeczywiście czymś wartym osiągania i daje wymierne korzyści interesariuszom produktu.

Taka definicja udanego Sprintu ma jednakże pewną słabość: nieosiągnięcie Celu Sprintu należałoby potraktować jako porażkę, a przecież powody, dla których to się stało, mogą być krańcowo różne. Czasami jest to rzeczywiście porażka Zespołu, który nie zdołał zarządzić swoimi działaniami na tyle skutecznie, by Cel osiągnąć. Bywa jednak i tak, że przebieg Sprintu ujawnia nieznany wcześniej powód, dla którego Cel wybrany przez Zespół nie jest osiągalny, lub jego osiągnięcie byłoby nieopłacalne. Uzyskanie tej wiedzy jest wartościowe, bo stanowi empiryczną podstawę do podjęcia decyzji, co dalej.

A zatem, choć można nieosiągnięcie Celu Sprintu uznać obiektywnie za niepowodzenie, nie należy takiego Sprintu automatycznie traktować jako nieudany, zanim Zespół Scrum nie przeanalizuje przyczyn tego stanu spraw i nie wyciągnie z nich wniosków.

Głupio: udany Sprint = Product Owner zaaprobował produkt

Ten sposób dokonywania oceny, czy Sprint jest udany, świadczy o głębokim niezrozumieniu Scruma. Nie ma w tej metodzie mowy o żadnej formie akceptowania prac przez Product Ownera, nie ma on do tego ani żadnego narzędzia, ani de facto umocowania. Dlaczego?

Jeśli coś zostało przez Developerów ukończone, czyli jeśli powstał produkt spełniający wymogi Definicji Ukończenia (ang. Definition of Done), to oznacza, że istnieje rozwiązanie nadające się do użycia. Inaczej mówiąc, istnieje produkt, który działa, choć nie ma pewności, że jest to taki produkt, jakiego potrzebują w tym momencie interesariusze.

Product Owner może dokonać oceny adekwatności rozwiązań, jakie zbudowali w Sprincie Developerzy. Należy jednak pamiętać, że nie robili oni tego, co przyszło im do głowy, ale realizowali elementy Backlogu Produktu zdefiniowane wcześniej przez Product Ownera i z nim doprecyzowane w ramach pielęgnacji tego Backlogu, a potem Planowania Sprintu. Dlaczego teraz Product Owner miałby nie aprobować czegoś, czego powstania wcześniej oczekiwał?

Każda zmiana, jaką Developerzy zrealizowali w trakcie Sprintu w produkcie, opisana mogła być dodatkowo kryteriami akceptacyjnymi. Ich tworzenie jest nieobowiązkową, ale popularną i przydatną praktyką w Scrumie, dzięki której redukowane jest ryzyko rozbieżności w rozumieniu elementów Backlogu pomiędzy członkami Zespołu Scrum. A jeśli takie kryteria akceptacji zostały spełnione i Product Owner wie o tym, co jeszcze miałby aprobować lub odrzucać?

Tak naprawdę niezależnie od ewentualnych wątpliwości Product Ownera konieczne jest zapytanie o opinię interesariuszy, którzy równie dobrze mogą ucieszyć się z produktu niezgodnego ze wcześniej deklarowanymi potrzebami, jak i zażądać przerobienia rozwiązań, które są idealnym odwzorowaniem zebranych wymagań. To przecież jeden z możliwych efektów istnienia niestabilnej złożoności, przez którą Zespoły sięgają po metody takie jak Scrum z jego Sprintami.

A jeśli to, co Developerzy zrealizowali w Sprincie, odpowiada zarówno wymogom Definicji Ukończenia, jak i oczekiwaniom interesariuszy, to znaczy, że bezprzedmiotowa jest dyskusja o aprobowaniu produktu. Niezbędna jest natomiast dyskusja o tym, czy produkt może zostać wydany (przekazany do użycia), czy konieczne jest wcześniejsze dokonanie w nim kolejnych zmian. Przy czym również decyzji o wydaniu produktu nie należy traktować jako jakiejś formy aprobaty, tak jak brak wydania nie oznacza jej braku.

Ambitnie: udany Sprint = zapadła decyzja o wydaniu produktu

Takie definiowanie sukcesu jest echem pokutującego tu i ówdzie przekonania, że w Scrumie wydania produktów można robić tylko na przełomie Sprintów i że jest to obowiązkowe po każdej iteracji. Cóż, oba stwierdzenia rozmijają się z prawdą.

Po pierwsze, w dowolnym momencie Sprintu, gdy tylko Developerzy zbudują działający produkt spełniający wymogi Definition of Done, można podjąć decyzję o jego wydaniu (przekazaniu do użycia). Ba, można to nawet robić to za każdym razem, gdy tylko coś zostanie ukończone (czyli posłużyć się praktyką continuous delivery), jeśli organizacja jest w stanie podołać tak częstym wydaniom.

Z drugiej strony, jeśli na koniec Sprintu produkt nie zawiera dość funkcjonalności, by był wartościowy dla interesariuszy (a przede wszystkim użytkowników), wtedy nie ma żadnego przymusu wydania takich niedojrzałych rozwiązań.

Tu z kronikarskiego obowiązku dodam, że jest od tej zasady wyjątek: może być tak, że Definicja Ukończenia, uzgodniona również z Product Ownerem, obejmuje jako jeden z warunków faktyczne wydanie produktu (wbrew pozorom nie jest wcale takie rzadkie). Wydanie staje się wtedy obowiązkowe, ale obowiązek ten nie wynika z zasad Scruma, ale z przyjętej w tym konkretnym Zespole Definicji Ukończenia.

Przy okazji: decyzja o wydaniu produktu tylko z pozoru należy wyłącznie do Product Ownera. Owszem, może on chcieć przekazać produkt użytkownikom, by z niego korzystali, natomiast Developerzy potrafią często wskazać na istotne powody, dla których takiego wydania nie należy robić.

I nie chodzi tu wcale o świadomość istnienia jakichś niedoróbek, bo ich nie powinno być, jeśli kryteria zawarte w Definicji Ukończenia są spełnione. Chodzi o ewentualne konsekwencje użycia produktu z jego aktualnie istniejącym zestawem funkcji i możliwości, które w różnych okolicznościach mogą prowadzić do niepożądanych skutków, np. utraty ważnych danych, problemów z bezpieczeństwem itd.

Ocena ryzyka, jakie wnosi wydanie produktu, który być może nie jest dostatecznie dojrzały od strony funkcjonalnej (aczkolwiek jest dopracowany pod względem jakości technicznej), wymaga wiedzy zarówno biznesowej, jak i technicznej – dlatego decyzja o użyciu produktu jest decyzją de facto całego Zespołu Scrum.

Każdy Sprint to eksperyment

Scrum korzysta z empirycznej kontroli procesu, a istotą działania w nim jest eksperymentowanie. Może to przerazić, bo czyż nie można oczekiwać, że doświadczeni Developerzy doskonale wiedzą, jak coś zrobić, a interesariusze, na których potrzeby pracują, wiedzą dokąd zmierzają? Cóż, niestety nie można tego oczekiwać. Właśnie dlatego niezbędne jest eksperymentowanie.

Przed zbudowaniem złożonego produktu (np. oprogramowania) i próbą jego użycia, możemy jedynie zakładać, że odpowie ono skutecznie na nasze potrzeby. A przed wytworzeniem produktu możemy jedynie przewidywać, jaką metodą uda się to zrobić najefektywniej i czy jest to w ogóle możliwe. Inaczej mówiąc, stawiamy hipotezy, które staramy się potwierdzić jak najszybciej – działaniami w Sprincie. Takie działanie oznacza, że eksperymentujemy.

Istotą metody Scrum jest zredukowanie złożoności, która nierozerwalnie wiąże się z domeną wytwarzania złożonych produktów, właśnie poprzez wykorzystanie empiryzmu. Zamiast próbować przewidzieć z góry wszystko, dzielimy ogromny i złożone zagadnienie na serię mniejszych problemów, dających się dużo łatwiej rozwiązywać w serii krótkich iteracji (eksperymentów, zwanych w Scrumie Sprintami). Po każdej z nich dokonujemy oceny tego, co udało się zrealizować lub dowiedzieć (a więc dokonujemy oceny rezultatów eksperymentu), po czym planujemy kolejną iterację, w której już więcej wiemy, bo znamy rezultaty iteracji poprzednich.

Rozwój produktu w Scrum (ale też innych metodach Agile) jest iteracyjny i inkrementalny: Sprint po Sprincie dodajemy lub zmieniamy w produkcie funkcjonalności, a gdy stanie się on na tyle użyteczny, że warto go wydać – czynimy to. I zbieramy feedback od rzeczywistych użytkowników, aby na jego podstawie dokonać dalszych zmian w produkcie.

Prawdziwy Sprint nie może być nieudany

Celem każdego Sprintu jest wytworzenie produktu, który przynosi wartość (korzyść) interesariuszom. Nie wolno przy tym zapominać, że nie może się to dziać za wszelką cenę. Produkt musi być wytworzony tak, by spełniał wymogi Definition of Done (bo dopiero wtedy w ogóle można go użyć) i by dało się go rozwijać dalej.

Sprint, w którym nie udało się zrealizować żadnego wymagania, bo z różnych względów – technicznych lub organizacyjnych – nie udało się spełnić wszystkich zapisów Definicji Ukończenia, również może być sukcesem. Pamiętajmy, że eksperyment, którego rezultat odbiega od postawionej na początku hipotezy, jest udany – możemy być co najwyżej nieusatysfakcjonowani tym rezultatem. Rozpoczynamy Sprint w przekonaniu, że uda się w nim zrealizować ściśle określony zbiór wymagań, a jeśli się to nie uda, zyskujemy wiedzę niezbędną do decydowania o dalszych krokach. Możemy zmienić sposób działania (proces, narzędzia) i spróbować ponownie; możemy odłożyć realizację na później (jeśli konieczne jest usunięcie przeszkody utrudniającej realizację wymagania); możemy zmienić samo wymaganie lub… zrezygnować z dalszych prac nad nim (jeśli to nie jest już opłacalne).

Z kolei Sprint, w którym wszystko udało się zrealizować, ale po którym Product Owner decyduje o dalszych pracach nad produktem lub zmianach w dopiero co ukończonych funkcjonalnościach, również jest sukcesem. Brak wydania nie jest porażką, ale świadomą decyzją Zespołu opartą na ocenie tego, co udało się wytworzyć. Nie musimy posługiwać się projektami i makietami produktu ani spekulować, w jaki sposób coś „będzie działać”, bo Sprint-eksperyment dostarczył nam działające rozwiązanie. Dzięki temu odkrywamy, że niekoniecznie dobrze rozumieliśmy, jak zbudować wartościowy produkt. Teraz – dzięki zakończonemu Sprintowi – wiemy więcej. Dokonujemy adaptacji, czyli pojawiają się nowe wymagania i cykl się powtarza.

Zwinnie: udany Sprint = Zespół wie, jak udoskonalić produkt i sposób jego wytwarzania

W Agile miarą sukcesu jest umiejętność wykorzystania podejścia empirycznego do poszukiwania najlepszych rozwiązań. Jeśli czegoś się nie uda wytworzyć, usuńmy to, co stoi nam na drodze – zmieniając podejście. Jeśli pierwszy pomysł staje się zbyt kosztowny – zróbmy coś alternatywnego. Jeśli proces okazał się nieefektywny, nie umiemy korzystać z narzędzi, brak nam praktyk wspierających pracę Developerów – poprawmy proces, poznajmy nowe narzędzia, nauczmy się używać niezbędnych praktyk. Jeśli nie umiemy się dogadać – usprawnijmy komunikację.

Dowiedzenie się o tym, co można zrobić lepiej, a następnie dokonanie usprawnień, jest sukcesem. Porażką byłoby zignorowanie wiedzy, którą udało się pozyskać w ciągu Sprintu i bezrefleksyjne kontynuowanie pierwotnych zamierzeń niezależnie od rzeczywistych skutków działań, jakie już podjęliśmy. Sprint należałoby uznać za porażkę również wtedy, gdyby uczestnicy procesu za jedyną miarę sukcesu uznali osiągnięcie Celu Sprintu (lub wydanie produktu) i dążyli do osiągnięcia tak definiowanego sukcesu za wszelką cenę.

Wracając do kwestii oceny Sprintu: czy można iterację uznać za udaną, jeśli nie osiągniemy Celu Sprintu ustalonego w czasie Planowania? Jeżeli, postępując profesjonalnie i etycznie zrobimy wszystko, co racjonalne i możliwe, by ów Cel osiągnąć, ale nam się to nie uda, Sprint należy uznać za udany. Oczywiście pod warunkiem, że potraktujemy ten Sprint jako lekcję, wyciągniemy z niej wnioski i posłużymy się nimi do planowania kolejnej iteracji.