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”.

Wyobraź sobie, że Sprint, w którym właśnie bierzesz udział, jest Twoim ostatnim Sprintem. Twój szef to CEO całej firmy i właśnie podjął taką decyzję. Nie chce bowiem inwestować już więcej pieniędzy w produkt X, ponieważ aktualnie większy zwrot z inwestycji da firmie praca nad produktem Y. Brzmi całkiem sensownie. Pierwsze wrażenie – szok. Jak to możliwe? Przecież miało być tak pięknie! Jednak chwilę później przypominasz sobie, że sam przekonywałeś go, że agile znaczy szybciej. Że agile to większa elastyczność. Mówiłeś o reagowaniu na zmiany ponad podążanie za planem. Masz pecha – Twoje buzzwordy właśnie zamieniły się w rzeczywistość. No cóż, czar

Wyobraźmy sobie nowoczesną łódź podwodna, wyruszającą na misję bojową. Świetnie przygotowana załoga doskonale radzi sobie z obsługą okrętu. Wszystkie systemy są naszpikowane elektroniką, a całość spina wysokiej jakości oprogramowanie. Okręt zbliża się w strefę walki. Pomimo sugestii doradcy, że warto by było ocenić, co znajduje się na horyzoncie, oficer dowodzący jest zdania, że łódź jest tak nowoczesna, iż nie ma sensu użyć peryskopu. Uważa, że wszystko co ważne, wskazuje nam aparatura pokładowa, a załoga nie raz już płynęła na misję, więc wiedzą doskonale, co mają robić. 10 minut później łódź zostaje trafiona torpedą wystrzeloną z wrogiego okrętu. Łączność z naszym