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 korzystającej z prostych reguł łączących precyzyjne zdefiniowane odpowiedzialności, zdarzenia, artefakty i powiązane z nimi zobowiązania, 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 ujawni 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.

Formalnie: udany Sprint = Product Owner zaaprobował produkt

Ten sposób dokonywania oceny, czy Sprint jest udany, świadczy o głębokim niezrozumieniu Scruma. Od strony formalnej 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. 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. Tę decyzję faktycznie podejmuje Product Owner, ale tak, jak wydanie nie oznacza aprobaty dla produktu, tak brak wydania nie oznacza jej braku.

Ambitnie: udany Sprint = Product Owner zdecydował 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, Product Owner może podjąć decyzję o wydaniu (użyciu) produktu. 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), to nie ma żadnego przymusu wydania takich niedojrzałych rozwiązań. To wciąż Product Owner podejmuje decyzję o wydaniu, oczywiście tylko takiego produktu, który zbudowany został zgodnie z wymogami Definicji Ukończenia.

Tu z kronikarskiego obowiązku dodam, że jest od tej zasady wyjątek, jeśli Definicja Ukończenia, uzgodniona również z Product Ownerem, obejmuje również wydanie produktu – co nie jest wcale takie rzadkie. W takim przypadku Product Owner niejako ceduje swoje prawo do decydowania o użyciu nowych rozwiązań na Developerów, aczkolwiek to wciąż Product Owner ponosi odpowiedzialność (ang. accountability) za skutki.

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 zmierzać? 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 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. 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żony problem na serię mniejszych, 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 Sprintu jest wytworzenie produktu, ale nie wolno zapominać, że nie może się to dziać za wszelką cenę. Produkt musi być wytworzony tak, by spełniał wymogi Definition of Done, konieczne jest też dostarczenie rozwiązania dla problemów biznesowych opisanych wymaganiami (i spełnienie kryteriów akceptacyjnych dla tychże wymagań, o ile zostały zdefiniowane).

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 Definition of Done, 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ą opartą na ocenie tego, co udało się wytworzyć. Nie musimy posługiwać się projektami i makietami produktu ani spekulować, jak 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 narzędzia, nauczmy się nowych 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 początku tego wpisu: czy można Sprint uznać za udany, 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.