Sprint 0 – dlaczego to zło?

Do worka o nazwie „Sprint 0” przyjęło się wrzucać bardzo wiele. Od zbudowania zalążka zespołu przez przygotowanie kompletnego (sic!) Product Backloga aż po działającą infrastrukturę i architekturę systemu.

Przeciwnicy tego podejścia stawiają sprawę jasno mówiąc, że czymkolwiek „Sprint 0” jest (najczęściej antywzorcem) to na pewno nie jest Sprintem. Koniec. Kropka. Zwolennicy natomiast często przyznają, że wprawdzie nie jest on pełnoprawnym Sprintem (w innym wypadku nie upieraliby się przy nazwie, prawda?) ale wciąż jest Sprintem. Więc jak to jest? Skoro nie jest pełnoprawnym Sprintem to czy obowiązują go zasady opisane w Scrum Guidzie? Jeśli nie obowiązują, to jak bardzo można je modyfikować?

W tym artykule postaram się udowodnić, że „Sprintu 0” raczej nie warto stosować i pokażę, że są konkretne powody, dla których Scrum nic o nim wspomina ani w żaden sposób nie wyróżnia jednego Sprintu na tle innych. Skupię się przede wszystkim nie tyle na minusach tych kilku tygodni (miesięcy?) nazywanych „Sprintem 0”, co na zjawisku bardziej niewidocznym i niebezpiecznym, jakim są precedensy powstałe w wyniku naginania reguł Scruma w trakcie trwania tego okresu.

Precedensy te mają najczęściej postać „ale przecież robiliśmy [tu wstaw jakąś złą praktykę] w Sprincie 0 i nic się nie stało”.

Podejście „ale przecież robiliśmy tak w Sprincie 0” w praktyce

Co gdy nie mamy jeszcze zespołu?

Zdrowy rozsądek podpowiada, że ciężko zacząć sprintowanie bez chociaż zalążka Scrum Teamu (PO, SM, 3-4 Developerów). Jeśli w organizacji nie ma istniejącego zespołu, który mógłby od razy rozpocząć pracę nad nowym produktem, to nie wyczarujemy go z kapelusza, musimy zacząć go formować albo rekrutując na zewnątrz firmy albo reorganizując istniejące zespoły (a najlepiej tworząc zespołom warunki do samoorganizacji… ale to temat na osobny art).

Czy zatem jest coś złego w zarezerwowaniu tego czasu na rekrutację, skoro zgodziliśmy się, że nie ma sensu sprintować w tak niekompletnym składzie? Nie ma, ale pod warunkiem, że nie będziemy redefiniować tego czym jest Sprint i skorzystamy z jakiejś innej nazwy. Na przykład

  • Kick off
  • Preparation
  • Setup
  • Inception
  • Initialization

Przyjrzyjmy się zatem jakie precedensy mogą pojawić się gdy użyjemy nazwy Sprint w odniesieniu do okresu, w którym zespół Scrumowy jeszcze nie istnieje.

Sytuacja w „Sprincie 0” Przykładowy precedens w przyszłości
Nie ma Product Ownera. PO: „Nie będę miał dla was czasu przez następne 3 Sprinty. Daliście radę w Sprincie 0, dacie radę teraz.”
 

Nie ma Scrum Mastera.

Manager lub CEO: „Nie potrzebujecie Scrum Mastera, Monika od dziś będzie zarówno Product Ownerem jak i Scrum Masterem, tak jak na początku.”
Zespół Developerski nie ma wszystkich potrzebnych kompetencji do stworzenia potencjalnie releasowalnego inkrementu. Manager lub CEO: „Poradzicie sobie bez Marka, Adama i Magdy, przez najbliższe 5 Sprintów będą potrzebni w innym projekcie.”
„Sprint 0” trwa 3 miesiące, odbyła się tylko jedna Retrospekcja, na koniec tego okresu. Zespół: „Odpuśćmy sobie Retrospekcję w tym Sprincie, trzeba naparzać kod a nie gadać!” 

Co gdy nie mamy jeszcze backloga?

Innym hamulcem przed rozpoczęciem sprintowania jest brak Product Backloga lub (co gorsza) brak kompletnego Backloga Produktu (cokolwiek ta kompletność miałaby oznaczać).

Obie sytuacje nie powinny blokować zespołu przed rozpoczęciem sprintowania, choć nie da się ukryć, że ta druga jest w dużo większym stopniu konsekwencją waterfallowego bagażu i przeświadczenia, że jeśli dostatecznie dużo czasu poświęcimy na planowanie i analizę, to wystarczy potem trzymać się tego planu, żeby wszystko było okej. W rzeczywistości jest tak, że w przypadku złożonych zagadnień nie jesteśmy w stanie znaleźć odpowiedzi na wszystkie pytania wyłącznie analizując problem. Co więcej, często nie jesteśmy nawet w stanie zadawać właściwych pytań. Stąd odwlekanie rozpoczęcia sprintów i empirycznego weryfikowania założeń prowadzi do akumulacji ryzyka (a konieczność planowania i analizy jest słabą wymówką).

Żeby rozpocząć sprintowanie nie potrzebujemy kompletnego ani nawet wstępnego Product Backloga. Wystarczy, że Product Owner pojawi się na Sprint Planningu z pewną wizją lub hipotezą na najbliższe kilka tygodni, którą wspólnie z zespołem uda się przekuć w Sprint Goal. Przygotowanie Backloga na kolejne Sprinty może wtedy spokojnie odbyć się w ramach refinementu (~10 % capacity zespołu developerskiego) rozpoczętego właśnie Sprintu.

Przechodząc do precedensów, zobaczmy co tym razem może się stać.

Sytuacja w „Sprincie 0” Przykładowy precedens w przyszłości
Wszyscy czekają ze sprintowaniem na kompletny Product Backlog. PO: „Zanim zaczniemy Sprint 16, potrzebuję do Road Mapy szczegółowy plan na najbliższe 3 miesiące. Przygotujemy kompletny Backlog i możemy wrócić do sprintowania.”
Zespół przeciąga „Sprint 0” tak długo aż Product Backlog zawiera dość pracy na 2-3 Sprinty. Zespół: „Nie damy rady zrobić Sprint Goala i przygotować user stories na kolejne Sprinty. Wydłużmy ten Sprint.”
„Sprint 0” kończy się wraz z time boxem, ale w jego wyniku nie powstaje nawet linijka kodu. Zespół: „Anulujmy Sprint Review w tym Sprincie, nic nie mamy bo sporo czasu zeszło na wymagania. W następnym na pewno będzie okej.”

Co gdy nie mamy jeszcze architektury?

Analogiczna sytuacja do poprzedniej ma miejsce gdy zamiast planowania i analizy, w „Sprincie 0” poświęcamy czas na projekt czy wręcz pełną implementację infrastruktury i architektury systemu.

Gdy „Sprint 0” przeciąga się niebezpiecznie długo, możemy mówić o tzw. BDUF (Big Design Up Front) czyli sytuacji kiedy rozwijane oprogramowanie nie dostarcza wartości biznesowej ani nie pozwala weryfikować z klientem/użytkownikiem żadnych założeń. Problem dotyczy również założeń czysto technicznych, bo jeśli na bazie architektury nie przetestowaliśmy żadnej funkcjonalności, to tylko odwlekamy w czasie moment, w którym może się okazać, że cała architektura jest do wyrzucenia lub poziom jej złożoności jest absurdalnie wysoki i drogi w stosunku do tego czego oczekiwał klient.

Kończąc znęcanie się nad samym „Sprintem 0”, zobaczmy jakie precedensy w obszarze projektu i architektury mogą na nas nawiedzić w przyszłości.

Sytuacja w „Sprincie 0” Przykładowy precedens w przyszłości
Zespół przeciąga „Sprint 0” pracując nad projektem systemu. Nie powstaje żaden kawałek kodu za to dużo diagramów UML. Zespół: „Musimy poczekać z kodowaniem i skupić się na dobrym projekcie. Sprint 14 to będzie Design Sprint”.
„Sprint 0” przedłuża się podczas gdy architekci i seniorzy przygotowują działającą infrastrukturę i architekturę systemu. Nie powstaje żadna funkcjonalność. Zespół: „Albo architektura albo ficzery. Musimy wydłużyć Sprint 25.”
 

„Sprint 0” kończy się wraz z time boxem, ale w jego wyniku nie powstaje żadna funkcjonalność/wartość dla klienta.

Zespół: „Nie mamy żadnych ficzerów na najbliższe Sprint Review, pokażmy jak wysyłają się message w RabbitMQ albo dynamiczne ładowanie DLL-ek.”

„Design Sprint”

Do poczytania:

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *