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?
6 odpowiedzi
A czy w praktyce nie wyjdzie z tego kanban?
@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.
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.
Teraz zauważyłem, że to napisałeś…
@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ć?
Jestem za jak największą autonomią zespołu. Zebranie wszystkich kompetencji jest jak najbardziej dobrze, ale niestety nie zawsze możliwe…