Sprint 0 – dobry, czy zły pomysł?

Cykl: Menedżer Plus
12 grudnia 2014

8

Dzisiaj na tapetę biorę kolejną listę pytań – tym razem, dotyczą organizowania tzw. „Sprintu 0”.

Czy zalecane jest organizowanie Sprintu 0, jako wstępu do zarządzania według metod zwinnych? Jakie korzyści/ straty niesie za sobą wprowadzenie Sprintu 0? Czy w Scrumie zaleca się praktykowanie Sprintu 0?

Damian J. 

W ostatnim wpisie, pisałem o tym, że w samym Scrumie, oprócz „twardych” reguł, które tworzą jego szkielet (ang. framework), istnieje też całkiem spora grupa praktyk, które oficjalną częścią Scruma nie są, ale przez wiele zespołów są powszechnie stosowane. Jedną z takich praktyk jest właśnie organizowanie tzw. „Sprint 0”, zanim jeszcze z czymkolwiek wystartujemy.

Czym jest Sprint 0?

Sprint 0 to, najkrócej, poczynienie wszystkich niezbędnych przygotowań, żeby móc w końcu wystartować ze Sprintem 1 w firmie. W każdym przypadku lista takich „zerowych” aktywności wygląda inaczej. Poniżej zamieszczam krótki katalog zadań, które najczęściej pojawiają się w prowadzonych przeze mnie projektach u klienta.

Lista „produktów”, które powstają w Sprincie 0

  • Stworzenie zespołu. Czasem zespół jest, a czasem go nie ma. I wtedy musimy wszystko budować od początku. Wtedy, najlepiej zorganizować jest oddzielne warsztaty, w ramach których wypracujecie sobie skład takiego zespołu, oraz ustalicie kto i jaką rolę pełni. Ja zazwyczaj robię tak, że na początku takiego spotkania wyjaśniam wszystkim podstawowe zasady, związane z budowaniem Zespołów Scrumowych, a także dzielę się dobrymi praktykami, które przećwiczyłem w projektach, prowadzonych u innych klientów. W trakcie takich warsztatów, oprócz składu zespołu, wybieramy Scrum Mastera, chociaż na początku nie zawsze się to udaje. Są zespoły, które potrzebują na taką decyzję trochę więcej czasu. Czasem też, w niektórych organizacjach, Scrum Mastera wybiera menedżer liniowy zespołu, chociaż zawsze wszystkich zachęcam, żeby taką decyzję pozostawić zespołowi. Jeśli chodzi o Właściciela Produktu, w przypadku prowadzonych przez mnie projektów, na tym etapie jest on już najczęściej znany. Prowadząc wdrożenie Scruma w dużej organizacji, nad zaangażowaniem Biznesu trzeba zacząć pracować wcześniej, najczęściej podczas odrębnych warsztatów, których jednym z punktów jest obsadzenie ról w tym zakresie.
    • Czas trwania: 2-4 godzin
  • Spotkanie „otwierające”. Głównym celem takiego spotkania jest oczywiście formalne zainicjowanie projektu. Przedstawienie wizji, celów biznesowych, które chcemy osiągnąć, możliwych korzyść, a także zaprezentowanie zespołowi, w jaki sposób będzie pracował, jakich narzędzi będzie używał, jakich metod i praktyk. To właśnie na tym spotkaniu, nowo uformowany Zespół Scrumowy powinien usłyszeć o planowanej zmianie – wdrożeniu metod agile w organizacji: dlaczego to robimy? Jakie są korzyści z takiego podejścia? Jakie są oczekiwania firmy w tym zakresie? Doskonale zdaję sobie sprawę, że może wam się to wydawać aż nadto oczywiste, jednak, jeżeli menedżer zespołu dobrze przeprowadzi takie spotkanie, będzie wam dużo łatwiej „zapanować” nad zmianą w waszej organizacji. Najgorzej jest wtedy, a ciągle zdarzają mi się takie sytuacje, gdy menedżer zespołu liczy, że w tym temacie wyręczy go konsultant zewnętrzny.
    • Czas trwania: 1-2 godzin
  • Przeprowadzenie niezbędnych szkoleń. Tutaj mogą się znaleźć szkolenia, dotyczące samego projektu, ktoś na przykład kupił rozwiązanie lub narzędzie od zewnętrznego dostawcy i zespołowi trzeba przekazać odpowiednią wiedzę na ten temat. Jeżeli zdecydowaliście, że zamiast tablic fizycznych będziecie używać narzędzi elektronicznych do zarządzania pracą w Scrumie, również powinniście pokazać ludziom jak to robić. Oprócz tego, bardzo ważne jest, żeby zespół poznał podstawowe założenia Scruma, praktyki, artefakty. Jeżeli zespół jest totalnie nowy, podczas takich szkoleń dobrze jest także dołożyć jakieś ćwiczenia, które zintegrują ludzi w nowo powstałym zespole i dadzą solidnego kopa do jego dalszego budowania.
    • Czas trwania: 4-7 dni
  • Przygotowanie „wsadu” do Sprintu 1. Zanim wystartujecie z pierwszym sprintem, Właściciel Produktu powinien usiąść z zespołem i przygotować się do pracy w sprincie 1. Przede wszystkim należy ustalić, jakie kryteria powinny spełniać historyjki użytkownika, zanim trafią na sesję planistyczną w sprincie (tzw. Definition or Ready), a także na jakiej podstawie będzie odbierana praca w sprincie (tzw. Definition of Done). Ja zwykle od tego zaczynam. Potem, jak już mamy zdefiniowane kryteria, możemy zabrać się za przygotowanie „materiału”, nad którym będziemy pracować w sprincie 1. Podczas wspólnych warsztatów Właściciel Produktu, wspólnie z Zespołem Deweloperskim przygotowują „paczkę” historyjek, od których rozpoczną pracę w najbliższym sprincie. Najczęściej wystarcza 10-12 historyjek, żeby ruszyć. Historyjki należy później oszacować (punkty, idealne dni).
    • Czas trwania: 1-3 dni
  • Opracowanie wstępnego planu wydania. W zależności od tego, jakiego typu wydań używacie w firmie (zorientowane na datę lub określony zakres), w ramach sprintu zero może zaistnieć potrzeba ustalenia, ile będziecie w stanie zrobić do określonej daty (planowanie zorientowane na datę) lub na kiedy (planowanie, na podstawie określonego zakresu). Niektórzy Właściciele Produktu, chcą znać takie informacje, zanim zespół ruszy z robotą w pierwszym sprincie.
    • Czas trwania: 1-3 dni
  • Logistyka. O tym punkcie się często zapomina. Później okazuje się, że zespół startuje ze sprintem i nie ma tablicy, na której mógłby rozwiesić swoje zadania, brakuje karteczek samoprzylepnych, nie ma flipcharta do narysowania wykresu, nie ma czym rysować, bo nie ma pisaków. Poniżej lista rzeczy, które najczęściej pojawiają się w moich projektach:
    • Zakup tablic do wizualizacji pracy w Scrumie, zorganizowanie samoprzylepnych karteczek, markerów, kartek do flipa (wykres spalania).
    • Przygotowanie wspólnego pokoju do pracy. Czasem ludzie siedzą na różnych piętrach lub są rozmieszczeni w różnych lokalizacjach (np. Poznań i Warszawa). Kiedyś, pracowałem z klientem, w którym prac logistycznych było tak dużo, że musieliśmy uruchomić specjalny projekt na tego typu działania. Bo na przykład trzeba było zorganizować przeprowadzkę kilku działów, kupić nowe meble, przebudować niektóre ścianki w budynku firmy. Oj, działo się.   
    • Zorganizowanie niezbędnego sprzętu do pracy (komputery, dostępy do narzędzi, zakup licencji).
    • Konfiguracja narzędzi do zarządzania pracą w Scrumie. W małych organizacjach to nie jest żaden problem. Możecie wystartować ze sprintem 1 i wszystko powoli sobie dokręcać. Ale jak w firmie pracuje kilka tysięcy osób; i każdemu nowo powstałemu zespołowi dacie uprawnienia administratora, na przykład do takiego narzędzia jak JIRA; i każdy taki nowo powstały zespół sam sobie będzie wszystko konfigurował (zakładał projekt, określał jego strukturę, definiował własne pola, ekrany, przepływy) – to później z kolei, będziecie musieli powołać oddzielny projekt, żeby to wszystko odkręcić. Nie wyolbrzymiam teraz, to „najprawdziwszy autentyk”.
    • Czas trwania: od kilku dni do jednego miesiąca

Jak widzicie, zadań, które są do zrobienia w sprincie 0 jest całkiem sporo. Przy każdym elemencie podałem wam orientacyjnie, jaki jest czas trwania każdego działania. W każdej organizacji Sprint 0 wygląda trochę inaczej. Lista, którą wam przedstawiłem zawiera wszystkie najbardziej typowe aktywności, które trzeba zrobić, jeżeli wdrażacie Scruma w dużej organizacji (od kilkuset do kilku tysięcy osób). W mniejszych firmach zarówno czas trwania Sprintu 0, jak i sama lista aktywności może się znacząco skrócić. Zwykle jednak taki „sprint” trwa od jednego do trzech miesięcy – oczywiście w przypadku, kiedy wdrażacie Scruma w całej organizacji. W pozostałych przypadkach od dwóch do czterech tygodni. Nie dłużej. 

Dobry, czy zły pomysł?

Sprint 0 to bardzo dobry pomysł. Serio! Nie wyobrażam sobie wdrożenia Scruma w jakiejkolwiek firmie bez uprzedniego przygotowania odpowiednich warunków, które umożliwią jego bezproblemowy przebieg. Oczywiście możecie olać Sprint 0 i próbować robić wszystko „po drodze” –  w sprincie 1, 2… Ale nie polecam. Co będziecie produktem takich sprintów?

Ale przejdźmy może do małej krytyki Sprintu 0. Rzeczą, która mi się absolutnie nie podoba w tej praktyce, jest jej nazwa. Posługiwanie się „Sprintem 0”, zwłaszcza, kiedy startujecie z wdrożeniem Scruma w firmie, prowadzi do całkiem sporego zamieszania. Ludzie będą pytać: – A co to za sprint, w którym nic nie powstaje? – A dlaczego „zero”? – A ile powinien trwać taki sprint? Egh… Był to głównym powód dla którego zrezygnowałem z nazywanie tej praktyki „Sprintem 0”. 

Poza tym, musimy pamiętać o tym, że choćbyśmy nie wiem jak bardzo fikuśnie numerowali sobie sprinty, na koniec każdego z nich powinien powstać potencjalnie gotowy do wdrożenia kawałek produkt (inkrement). Takie są w końcu reguły Scruma, prawda? A w Sprincie 0 taki produkt, rzecz jasna, nie powstaje. No dobra, możemy się spierać, czy aby na pewno nie powstaje. Bo przecież „stworzenie zespołu”, czy „opracowanie DoD” jakimś tam „produktem” jest, prawda? No tak. Ale nie o taki produkt nam w Scrumie chodzi.

Skoro nie „Sprint 0”, to jak w takim razie się powinna ta praktyka nazywać? I tu jest problem. Próbowałem naprawdę różnych sposobów: „incepcja”, „przed-projektem”, „zaczątek”. Póki, co najlepiej sprawdzało się „przedsprincie”. Jedynie w ofertach do klientów jej nie używam, bo jest zbyt kolokwialne. Tam piszę zwyczjnie: „Przygotowanie do Sprintu 1”. I już. 

Podsumowując

Szczerze polecam praktykowanie „Sprintu 0” w waszej organizacji, jeżeli tylko inaczej go nazwiecie. Podstawową korzyścią z wprowadzenia „przedsprincia” jest stworzenie niezbędnych warunków do tego, żeby zacząć. Żadnych strat, ze stosowania tej praktyki nie zauważyłem.