Jednodniowe Sprinty w Scrumie

1-dniowe sprinty w Scrumie

1-dniowe 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?

Fotografia użyta na licencji Creative Commons od użytkownika andrechinn.

Share on Facebook0Tweet about this on TwitterShare on LinkedIn5Share on Google+0

6 myśli nt. „Jednodniowe Sprinty w Scrumie

  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.

Dodaj komentarz

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