Krótkie czy długie?

Niemal każdego dnia obserwuję jakie znaczenie ma długość. Niekoniecznie w takim sensie jak pewnie teraz myślisz, śmieszku/śmieszko 😉 Chodzi mi o czas trwania Sprintu scrumowego. 

Większość zespołów, które znam, pracuje w cyklach dwutygodniowych. Jednak te, z którymi pracowałem i które zdecydowały się tę długość skrócić, zaczęła: skuteczniej realizować cele sprintu, zwiększyła swoją efektywność i jednocześnie miała poczucie większej kontroli nad tym jak idzie im praca – w porównaniu z pracą w cyklach dwutygodniowych. Czemuż tak było? Oto jest pytanie

Krótsze sprinty ułatwiały skupienie. Liczba rzeczy do ogarnięcia musiała być bardziej ograniczona, ze względu na długość trwania cyklu właśnie. Innymi słowy, na planowaniu “braliśmy mniej”, bo na jeden tydzień, a nie dwa. Liczba potencjalnych problemów do ogarnięcia była mniejsza. Mniej zależności. I tak dalej, i tak dalej. Takie skupienie bardzo sprzyja efektywności. 

Niektórzy powiedzą, że jednotygodniowe sprinty “to za szybko” i “więcej spotkań”. Fakt, Przegląd, Planowanie lub Retro , zdarzają się częściej (bo co tydzień), ale… ich timebox jest też krótszy! Ostatecznie zatem spędzamy na nich podobną ilość czasu. A jeśli się nie wyrabiamy z pracą, to może coś źle zorganizowaliśmy? Nie lepiej jest działać szybciej? Może damy radę wyeliminować jakieś marnotrawstwo?

Przejdźmy jeszcze na chwilę do tematu tablicy, którą wiele zespołów wyświetla na Daily. Przy krótkich Sprintach jest ona łatwiejsza do “czytania”, bardziej zrozumiała. Pewien zespół, z którym pracowałem, liczył 4 deweloperów i pracował w tygodniowych cyklach. Na Daily z jednego obrazka wiedzieliśmy “wszystko”! Ta tablica była po prostu tak mała, że nie musieliśmy niczego filtrować (praca w Jirze 🤢) itp. – jeden widok, na którym widać było cały Sprint Backlog (rzeczy zrobione, w trakcie, testowane itd.). Ponadto mieliśmy dobre tytuły historyjek, odpowiednie kolory i etykiety – wszystko to sprawiało, że tablica “czytała się sama”. Przez to minimalizował się syndrom “raportowania” – nikt nie wyjaśniał tego co znajdowało się na tablicy, bo wszyscy to doskonale widzieli. Deweloperzy skupiali się na układaniu planu i następnie na rozwiązywaniu problemów. A zadanie mieli ułatwione, bo elementów do ogarnięcia było mało… I tak dalej, i tak dalej. Rzecz trudniejsza do osiągnięcia przy większej skali. Mniej procesu – większa zwinność 🤠

Nie każdemu zespołowi będzie pasowała praca w jednotygodniowych Sprintach. Dużo będzie zależało od charakteru rozwijanego produktu, możliwości w ogóle dostarczania przyrostu w krótszych cyklach, kondycji repozytorium/projektu, procesu wdrażania zmian na produkcję, zależności na zewnątrz i wielu innych czynników. Niekiedy okazać się może, że jednotygodniowe Sprinty uwypuklą te problemy – ale to dobrze, wiesz jakie procesy trzeba poprawiać 🤓 Nie każdy będzie też mógł skrócić Sprinty, bo np. organizacja narzuca pewne rozwiązania w tej kwestii (“każdy zespół musi pracować w Sprintach dwutygodniowych”).

Korzyści z krótkich Sprintów są bardzo duże i miałem okazję się o tym przekonać wiele razy. Jeśli jeszcze tego nie zrobiliście, to zachęcam Was do eksperymentowania i skrócenia sprintu ze swoim zespołem, chociaż na okres próbny :) Jeśli już macie doświadczenia z pracą w sprintach jednotygodniowych lub generalnie skracaniem Sprintów, to koniecznie podzielcie się nimi w komentarzach!

Here you will find an English version 🇬🇧