Jednodniowe Sprinty w Scrumie

Od zawsze byłem fanem krótkich sprintów. Dostrzegam dużą wartość w skracaniu pętli feedbacku przy jednoczesnym minimalizowaniu niepewności związanej z wytwarzaniem oprogramowania.

Myślałem ostatnio o prostym eksperymencie – przez tydzień lub dwa chciałbym pracować z zespołem używając 1-dniowych sprintów.

Zakładając 8h dzień pracy, na właściwą pracę – po odjęciu czasu potrzebnego na zdarzenia scrumowe – pozostaje 378 minut, tj. 6h 18 minut.

Oto jak wyglądał by szkielet zdarzeń scrumowych:

  • Planning – 24 minuty
  • Refinement – 42 minuty
  • Review – 12 minut
  • Retrospektywa – 9 minut
  • Daily – 15 min

Patrząc na powyższe liczby, pierwsze co przyszło mi do głowy, to stwierdzenie „wymagające te timeboxy”. Po dłuższym zastanowieniu jednak, kiedy ponownie uzmysłowiłem sobie, że mówimy po prostu o organizacji jednego dnia pracy, wartości te przestały mnie zadziwiać.

Zakładam, że pewne założenia muszą zostać spełnione, aby takie podejście miało szansę powodzenia, do głowy przychodzą mi następujące punkty:

  • zespół realizuje w sprincie 1-2 naprawdę małe funkcjonalności
  • członkowie zespołu bardzo dobrze potrafią ze sobą współpracować i dzielić się pracą (wykorzystują np. swarming)
  • elementy Product Backlogu są bardzo małe, nie zależą od siebie, a jednocześnie przynoszą wartość
  • wykorzystywane jest podejście walking skeleton, tak aby na koniec sprintu pokazać coś potencjalnie zbywalnego, operując mocno głębią odwzorowania szczegółów
  • brak znaczących zależności zewnętrznych (np. oczekiwanie kilka godzin na jakiekolwiek zasoby odpada)
  • sprawny Scrum Master potrafiący moderować tak ekstremalne podejście do dewelopmentu

Co sądzicie? A może ktoś z Was pracował już z 1-dniowymi sprintami?

 

Share on facebook
Facebook
Share on twitter
Twitter
Share on linkedin
LinkedIn
Jacek Wieczorek

Jacek Wieczorek

Jestem konsultantem zwinności i praktykiem podejścia agile. Napisałem książkę "Labirynty Scruma" o sprawdzonych sposobach na najczęstsze pułapki w Scrumie. Pomagam przekształcać organizacje w miejsca, w których efektywnie tworzone są wartościowe produkty. Prowadzę bloga jacekwieczorek.pl, współtworzę podcast Porządny Agile oraz portal Agile247. Na co dzień pomagam klientom działając jako konsultant w firmie 202 Procent, którą współtworzę z pasjonatami zwinności.

6 Responses

  1. @LUkasz – ciekawa obserwacja. Generalnie widzę miejsce na implementację praktyk Kanbana wewnątrz Scruma, jednak samo skrócenie Sprintu do jednego dnia nie daje mi pewności, że zasady oraz praktyki Kanbana będą respektowane i stosowane. Wizualizacja procesu, limitowanie WIP czy zarządzanie flow procesu może w tym przypadku pomóc, musi jednak wystąpić w wyniku świadomej decyzji zespołu.

  2. Wszystkie, ale to dokładnie WSZYSTKIE kompetencje musiałbyć mieć w zespole. Nic nie mogłoby zależeć od zewnątrz. Jeśli coś zależałoby od zewnątrz, to przy takim reżimie pracy najmniejsze opóźnienie zewnętrzne powodowałyby po prostu niedowiezionie stories.

      1. @Tafla – zgadzam się z tym ograniczeniem. Jeśli chodzi o zależności, to może to jest słoń w pokoju, którego czas wyprosić, aby nieco przyspieszyć?

        1. Jestem za jak największą autonomią zespołu. Zebranie wszystkich kompetencji jest jak najbardziej dobrze, ale niestety nie zawsze możliwe…

Dodaj komentarz

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

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.