Blog

Czasami w pracy zespołów zwinnych spotykam się z pojęciem Sprintu Zerowego. Jak rozumiem, jest to iteracja mająca na celu m.in. przygotowanie środowiska pracy dla Zespołu Scrumowego przed „właściwym” Sprintem i osobiście uważam to za niepotrzebną, a czasami groźną praktykę. Nie chodzi mi jednak o scrumowy puryzm (bo Sprint Zero częścią Scruma nie jest i raczej nigdy nie będzie), ale o wyjaśnienie, dlaczego nie ma sensu tworzyć takiej koncepcji i czemu może ona niebezpiecznie wypaczać późniejsze rozumienie pracy w Sprintach.

Co to jest Sprint?

Skoro mówimy o Sprintach, odnieśmy się najpierw do samych podstaw Scruma. Co mówi Scrum Guide? „Sercem Scruma jest Sprint – ograniczony czasowo do maksymalnie jednego miesiąca, podczas którego wytwarzany jest „Ukończony”, gotowy do użycia i potencjalnego wydania Przyrost produktu. Sprinty zachowują możliwie stały czas trwania przez cały okres realizowania prac”. Mamy tu więc określony czas przeznaczony na pracę, en tej pracy (uzasadnienie konieczności wprowadzenia iteracji o stałej długości) i zestaw reguł:

1. Przynajmniej raz na miesiąc chcemy dokonać inspekcji i adaptacji tworzonego produktu i sposobu jego wytwarzania.
2. Żeby było to możliwe, przynajmniej raz na miesiąc coś zbudujemy, i to „coś” (potencjalnie „wydawalny” Przyrost Produktu) będzie możliwe do użycia (spełnia Definicję Ukończenia). Będziemy mogli się do tego odnieść, przeglądać produkt i zmieniać (bo to, co już mamy, będzie działać).
3. Chcemy utrzymać stały rytm, bo pozwala ograniczyć złożoność i umożliwia empiryczne sprawdzenie, czy idziemy w dobrą stronę również poprzez analizę trendów. Trendy trudno byłoby obserwować, jeśliby próbkowanie było robione dowolnie – czyli gdybyśmy manipulowali długością Sprintów.

Ten miesiąc to swoista miara ryzyka – pozwolimy sobie na działanie bez informacji zwrotnej z rynku co najwyżej przez miesiąc. Innymi słowy im dłuższa iteracja, tym większe niesie zagrożenie stracenia łączności z potrzebami biznesu, i miesiąc to najwięcej na ile możemy sobie pozwolić. Większość zespołów, które spotykam ma Sprinty dwutygodniowe, a niektóre branże wymagające bardzo częstego synchronizowania się z klientem nawet jednotygodniowe lub krótsze. Sprint to ustalone „pudełko na pracę” – w ramach tego pudełka robimy mini-projekt, taki biznesowy eksperyment. Pracujemy zespołowo, planujemy pracę, angażujemy się w dostarczenie wartościowej i działającej wersji produktu. Na koniec iteracji możemy podjąć decyzję o wydaniu tej wersji albo kontynuowaniu prac w oparciu o informację zebraną od klientów i interesariuszy.

Co to jest Sprint Zero?

Chociaż nie występuje w Scrumie, niekiedy spotyka się to pojęcie w pracy zespołów, które rozpoczynają przygodę z Agile. Sprint zerowy to w zależności od wyjaśnień zespołu, czas na:

• przygotowanie środowisk,
• narysowanie wstępnej architektury,
• przygotowanie backlogu,
• zrekrutowanie zespołu,
• szkolenia/warsztaty,
• inną pracę, która nie tworzy Przyrostu itp.

Czas ten bywa równy „normalnemu” Sprintowi (czyli trwa np. dwa tygodnie), ale częściej jest dłuższy, nawet więcej niż miesiąc. Zasadnicza różnica leży też w celu, dla którego realizowany jest ten Sprint – nie jest w nim bowiem budowany żaden potencjalnie „wydawalny”, ukończony Przyrost Produktu, co ze scrumowego punktu widzenia w ogóle neguje użycie nazwy „Sprint”. Niekiedy wszystko, co wydarzyło się przed rozpoczęciem prac rozwojowych wrzucane jest do „Sprintu zerowego” – to po prostu zbiorcza nazwa na start projektu, kick-off czy inną fazę rozbiegową.

W czasie Sprintu Zero tradycyjne zdarzenia scrumowe mogą nie być realizowane albo są obecne w ograniczonej formie (i z dużą dozą prawdopodobieństwa pozbawione są swojego scrumowego sensu). W praktyce taki Sprint Zero jest udawaniem, że już w Scrumie pracujemy, podczas gdy na razie naszą intencją jest jedynie się do tego przygotować. Nie ma niczego złego w powiedzeniu, że jeszcze produktu nie budujemy, bo nie jesteśmy gotowi; problem pojawia się wtedy, gdy bez intencji wytworzenia czegoś, co działa i jest „Done” zaczynamy działać „w Scrumie”, bo pojawi się ryzyko, że „przygotujemy kawałki” różnych rzeczy i w efekcie od początku zaciągamy znaczny dług techniczny.

Dlaczego uważam, że Sprint Zero jest niepotrzebny?

Istnieją dwa powody, dla których walczę z nazwą Sprintu Zero. Pierwszy dotyczy samego „Sprintu” i został wyjaśniony powyżej w (mam nadzieję) dokładny i przyswajalny sposób – nie powstaje Przyrost Produktu, więc to nie jest Sprint. To nic, że nawet zmieściliśmy się w dwa tygodnie, skoro wytworu tej pracy nie da się użyć. Drugi powód związany jest z konsekwencjami działań zespołu, niezdrowych z punktu widzenia empiryzmu, a których może dopuszczać się on w Sprincie Zero, i które rzutuje na dalszą pracę w iteracjach. Wśród takich anty-wzorcowych zachowań można wymienić:

1. Potrzebę zbudowania „pełnego” backlogu, narysowania „kompletnej” architektury.
   • Backlog Produktu nigdy nie jest „kompletny” lub „skończony”. Odzwierciedla aktualne potrzeby w produkcie, więc cały czas żyje – niektóre elementy są uszczegóławiane, inne dopisywane, jeszcze inne – już nieaktualne – po prostu z niego usuwane.
   • W organizacjach zazwyczaj jest potrzebny czas na przedyskutowanie jakichś wstępnych wymagań. Bardzo dobrze, warto poświęcić czas na takie rozmowy, ale pierwszy Sprint można zacząć i bez wcześniej przygotowanego Backlogu – po prostu przychodzi Product Owner i mówi „Hej, potrzebujemy zbudować to lub tamto, zaplanujmy się na dwa tygodnie”. Wtedy de facto mamy Backlog – cóż, że na razie jednoelementowy, składający się z tego jednego życzenia Product Ownera.
2. Nietrzymanie się timeboxów „bo się dopiero uczymy”.
   • To właśnie timebox pozwala nauczyć się pod presją czasu osiągać cele, skupiać się na nich, eliminować rzeczy niepotrzebne.
   • Im wcześniej zaczniemy stosować się do rytmu iteracji, tym lepiej będziemy umieli dekomponować pracę, uchwycimy rytm działania, będziemy lepiej prognozować.
3. Budowanie nawyku, że Sprint może się skończyć bez Przyrostu Produktu.
   • Zbudowanie potencjalnie „wydawalnego” produktu w każdej iteracji to sedno i sens Scruma. Jeśli nie mamy nic takiego przynajmniej na koniec Sprintu, to po co nam w ogóle takie podejście?
   • Budujemy produkt często, żeby można było regularnie zbierać prawdziwy feedback, nie odnoszący się do planów, makiet czy dokumentów, ale coraz to nowszych wersji realnego produktu.
   • Jeśli koczy się iteracja, a my nie posiadamy wartościowego produktu, to oznaka, że powinniśmy lepiej dekomponować pracę i mocniej zastanowić się nad tym skąd płynie wartość w budowanym rozwiązaniu.
4. Brak Definition of Done.
   • Dla pracy w Sprincie Zero trudno jest ustalić DoD, bo ono jest właściwością Przyrostu. Skoro nie mamy intencji zbudowania działającego produktu, DoD przestaje być potrzebne.
   • Dobrze jest jednak poświęcić czas przed startem pracy nad produktem, by Zespół stworzył swoje pierwsze DoD (najpewniej w oparciu o już istniejące standardy wytwórcze w organizacji).
   • Bez DoD nie istnieje Przyrost (bo jest definiowany jako nowa wersja produktu spełniająca wymogi DoD), dlatego jeśli w dalszych Sprintach nie będziemy mieli spisanej definicji, to nie będziemy mogli jednoznacznie stwierdzić co zostało ukończone, a co nie.
   • Brak DoD to brak podstawowej przejrzystości pracy Zespołu.

Czym zastąpić Sprint Zero?

Jakkolwiek banalnie to zabrzmi – normalnym Sprintem, w którym dostarczymy choćby mały Przyrost Produktu zgodny z Definition of Done. Wraz z upływem czasu Zespół będzie coraz bardziej dojrzały, będzie miał bardziej wyśrubowane Definition of Done, będzie tworzyć lepsze Przyrosty Produktu. Ale teraz, na początek wystarczy proste rozwiązanie dające się użyć, dostarczające wartość naszym interesariuszom i możliwe do dalszej rozbudowy w oparciu o rynkowe potrzeby.

A jeśli Twoja organizacja dopiero się zastanawia nad zwinną pracą, przymierza się do budowy jakiegoś produktu w taki sposób, czy też szkoli się by zdobyć podstawowe kompetencje – nie nazywaj tego Sprintem Zero. Opatrz to w oficjalny sposób etykietką „Tu zmieniamy naszą kulturę pracy” i wspólnie pracujemy nad przygotowaniem do tego. I kiedy uznacie, że czas na nowy sposób rozwijania produktu, po prostu wystartujcie z klasycznym scrumowym Sprintem.