SCRUM: ostatnia granica. Oto wędrówki zespołu AnythingButEnterprise kontynuującego misję odkrywania nowych, nieznanych światów, poszukiwania form efektywnej i przyjemnej pracy, śmiałego podążania tam, gdzie nikt z firmy jeszcze nie dotarł.
Tematem tego posta będzie planowanie zdarzeń (eventów) SCRUMowych. Dzisiejszy odcinek sponsorują hasła: timeboxing, zrozumienie ponad ortodoksję oraz chwila oddechu.
Timeboxing
Timeboxing, obok teorii empirycznej kontroli procesu oraz „empowerment’u”, jest wg. mnie jednym z filarów, na których stoi SCRUM. Potrzeba ścisłego trzymania się ram czasowych wręcz emanuje z kart SCRUM Guide, opisujących zdarzenia SCRUM’owe. Zauważyłem jednak, że większość zespołów rozpoczynających przygodę ze SCRUMem najczęściej ignoruje zasady związane z trzymaniem ustalonych ram czasowych. Muszę szczerze przyznać, że było tak też w przypadku mojego pierwszego „zwinnego” zespołu. Początkujące team’y najczęściej starają się utrzymać stałą długość sprintu, lecz zapominają, że rygor czasowy obowiązuje również w innych zdarzeniach, takich jak Sprint Planning, Daily Scrum czy Retrospekcja.
Okazuje się często, że utrzymanie ram czasowych spotkań jest znacznie trudniejsze niż w przypadku Sprintów. Poniżej znajdziecie kilka porad, które mam nadzieję, pomogą wam opanować trudną sztukę timeboxingu:
- Rób agendę na dłuższe spotkania, uwzględniając maksymalny czas trwania każdego z punktów agendy – tutaj korzystasz z dobrodziejstw strategii dziel i zwyciężaj, (jeśli utrzymasz ramy czasowe każdego punktu agendy - utrzymasz ramy czasowe całego spotkania bez pomijania żadnego z jego punktów). Jest to szczególnie przydatne podczas przeprowadzania retrospekcji;
- Zwróć uwagę na punktualność, zaczynaj spotkania zawsze o czasie, jeśli kogoś jeszcze nie ma to trudno. Nie czekajcie na niego, lecz wyjaśnijcie sprawę z „delikwentem” po spotkaniu. Szkoda waszego czasu;
- Na każdym spotkaniu ustaw jakiś „czasomierz” w widocznym miejscu. Może to być zegar, lecz znacznie lepszy jest minutnik albo stoper. Ja, jako wielbiciel urządzeń z jabłuszkiem, używam aplikacji 30/30. Pozwala ona na odmierzanie ile czasu pozostało na dany punkt agendy. Wydaje mi się, że jak chwilkę poszukacie znajdziecie analogiczną aplikację na inne platformy (android, windows, linux);
- Co w przypadku, gdy nie udało wam się „wyrobić” ze spotkaniem w wyznaczonym czasie? Wówczas proponuję poświęcić ostatnie 15 minut spotkania na:
- Podsumowanie, co wam się udało osiągnąć na spotkaniu,
- Dokładne ustalenie (najlepiej w postaci listy), czego nie udało się ustalić na spotkaniu,
- Podjęcie decyzji czy warto kontynuować dyskusję o nierozstrzygniętych zagadnieniach. Jeśli tak, to:
- Wybrać dokładnie co należy jeszcze ustalić (określić cel dodatkowego spotkania),
- Ustalić ramy czasowe dodatkowego spotkania,
- Ustalić, kiedy ma się ono odbyć (oczywiście może zacząć się ono zaraz po zakończeniu bieżącego spotkania – w praktyce będzie pewnego rodzaju jego przedłużeniem).
Jeśli na przykład potrzebujecie dodatkowych 2 godzin na Sprint Planning oznacza to, że
będziecie mieli 2 godziny mniej na właściwe prace w Sprincie. Upewnijcie się, że wzięliście
to pod uwagę przy planowaniu ilości pracy, którą chcecie wykonać podczas sprintu.
Zwinny SCRUM
Teraz chciałem zwrócić uwagę na nadgorliwość, którą wykazują się co poniektórzy SCRUM puryści. SCRUM guide nie definiuje ścisłych ram czasowych zdarzeń. Przykładowo przyjrzyjmy się kwestii Sprint Planningu. Zacytujmy tutaj fragment SCRUM guide w tłumaczeniu Tomka Włodarka: „Planowanie Sprintu jest zdarzeniem ograniczonym do ośmiu godzin dla miesięcznego Sprintu. Dla krótszych Sprintów jest ono zwykle krótsze”. Co z tego wynika? SCRUM guide określa maksymalny czas trwania spotkania. Nie narzuca, lecz sugeruje, że w przypadku sprintów krótszych niż miesiąc sprint planning powinien trwać mniej niż maksymalne 8 godzin. Często słyszałem lub czytałem, że np. zespół, który ma dwutygodniowe sprinty i poświęca na sprint planning 3 godziny z tego powodu uprawia „SCRUM-but’a” (bo powinien poświęcać 4 godziny). Jest to oczywiście bzdura. Bądźcie „zwinni”. Dostosujcie długość zdarzeń SCRUM’owych do waszych potrzeb.
Dla „świeżych” i niedoświadczonych (w SCRUM’ie) zespołów proponuję zastosować zasadę przeliczania, 1: 1, czyli:
- dla sprintu miesięcznego 8 godzinny sprint planning,
- dla sprintu 2 tygodniowego 4 godzinny sprint planning,
- dla sprintu tygodniowego 2 godzinny sprint planning.
Co sprint na retrospekcji omawiajcie efektywność sprint planningu. Jeśli nie wyrabiacie się w określonych ramach czasowych szukajcie rozwiązań, które zwiększą efektywność spotkania. Decyzję o wydłużeniu sprint planningu (jeśli będzie taka potrzeba) podejmijcie dopiero po kilku sprintach, gdy okaże się, że mimo wprowadzonych po retrospekcji zmian, ciągle jest problem z zakończeniem spring planningu na czas. Chodzi o to, że zespoły często „idą na łatwiznę” zwiększając limit czasowy, podczas gdy prawdziwy problem leży w niskiej efektywności spotkań.
Daj ludziom odpocząć
Dlatego:
- Zaplanuj pół godzinną przerwę na każde 1,5 – 2 godziny spotkań,
- Ustal konkretną godzinę przerwy na obiad, szczególnie, jeśli ludzi zamawiają katering. W przeciwnym razie spotkania notorycznie będą przerywane w trakcie, „bo jedzienie dotarło”,
- Dobrą praktyką jest rozłożenie zdarzeń kończących i zaczynających sprint (Sprint Review, Sprint Planning, Retrospekcja) na dwa dni,
- Dni planningu powinny trwać maksymalnie 8 godzin, choć osobiście zalecam, aby były krótsze. W naszej pracy są znacznie istotniejsze rzeczy niż „wyrobienie dniówki”.
Nasz (typowy) harmonogram
W naszym zespole typowy harmonogram wygląda
następująco:
Wtorek
9:00 – 10:30
Sprint Review
11:00 – 13:00
Grooming I
13:00 – 13:40
Lunch break
13:40 – 13:50
Kudos meeting
13:50 – 14:00
Doomsday clock meeting
14:00 – 15:30
Retrospective
Środa
09:00 – 11:00
Grooming II
11:30 – 12:00 Sprint
Planning I
12:00 – 12:40
Lunch break
12:40 – 15:45
Sprint planning II
15:45 – 16:00
Sprint Planning - Summary
Kilka komentarzy na jego
temat:
- Z uwagi na rozmiar zespołu tak zwane (u nas) planningi trwają dwa dni,
- Zespół zdecydował, że chce włączyć grooming w ramy dni planingów, aby w trakcie „właściwego” sprintu móc skoncentrować się na właściwych pracach wykonawczych (development, testy, deployment),
- Między spotkaniami (które trwają do 2 godzin) zespół ma pół godzinne przerwy,
- Przerwa na obiad trwa 40 minut. Jest z góry ustalona, aby było wiadomo, na którą godzinę zamówić obiadki. Bez tego spotkania często były nagle przerywane, bo dostarczono (o losowej godzinie) obiad i trzeba go zjeść póki jest ciepły,
- Podczas sprint planningu II zespół dzieli się na podzespoły i każdy podzespół sam określa, kiedy chce zrobić przerwę,
- Sprint Planning I jest bardzo krótki (pół godziny) – na nim zespół z Product Owner’em ogólnie omawia, które User Story powinny być wykonane w trakcie Sprintu. Zespół developerski również wykorzystuje ten czas do dopytania o interesujące ich rzeczy,
- Sprint Planning – Summary jest tak naprawdę fragmentem części drugiej Sprint Planningu. Został wydzielony, ponieważ Product Owner często uczestniczy w zdarzeniach scrumowych zdalnie (realizujemy produkt dla klienta zagranicznego). Podczas podsumowania zespół developerski zdzwania się z Product Ownerem w celu ustalenia ostatecznego kształtu sprintu,
- Harmonogram rozpisany jest na 7 (a nie standardowe 8) godzin. Spowodowane jest tym, że:
- We wtorek członkowie zespołu przychodzą wcześniej, aby przygotować środowiska (serwery, aplikacje) do Sprint Review,
- W środę jest duże natężenie spotkań planistycznych i pod koniec ludziom „mózgi przez uszy wypływają”.
P.S. Tytuł zainspirowany
jest pewnym wymaganiem, które widziałem (dzięki Darku J) w jednym z dokumentów SiWS do przetargu
publicznego. Brzmiało ono następująco:
„System powinien zarządzać czasoprzestrzenią”.
Umocniło mnie to w
przekonaniu, że jedynie „metodyki” zwinne są w stanie uratować obszar
informatycznych przetargów publicznych. Przeraża mnie ile naszych ciężko
zarobionych pieniędzy idzie w błoto.
Categories:
SCRUM,
SCRUM events,
timeboxing
Heh, pamiętam jak przerabiałem tego SiWSa, to było dla Pałacu Kultury... Wymagania z kosmosu, to i odpowiedni komentarz jako 'Solution' :D