Kategorie
Praktyka

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?

To oczywiście uproszczenie, ale oddaje sens tego co chcę przekazać :)

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 🇬🇧

4 odpowiedzi na “Krótkie czy długie?”

Ja mam akurat dość mieszane uczucia.
1. Jednostka pracy – zadania muszą być takie by w te 5 dni dało je się kończyć. Osobiście mi to akurat pasuje, ale …
2. Zespół musi być bardzo skupiony na pracy, na rozbijaniu wszelkich problemów, które się pojawią. Jeden słabszy dzień i dostarczenie celu sprintu może okazać się już niemożliwe.
3. Tydzień w tydzień te spotkania to akurat wg. mnie może być plus. One muszą wtedy być konkretne, rzeczowe. Bez wodolejstwa, targowania się o 2 story pointy itp.

Przemawia do mnie mniejszy board. A jak ze wszystkim spotkaniami które odbywały się co 2 tygodnie, teraz będą tydzień-w-tydzień, czy jakoś inaczej zostało rozwiązane?

Cześć, co do zasady wszystkie spotkania powinny odbywać się co tydzień. Jednak dla niektórych to zbyt często – pracowałem z zespołem, z którym tylko Planowanie robiliśmy co tydzień, a resztę spotkań jakbyśmy pracowali w cyklach dwutygodniowych (Retro itd.). Nie jest to oczywiście zgodne z Przewodnikiem po Scrumie, ale u nas bardzo fajnie działało :)

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *