Czy możemy stosować Scruma bez spotkań?

Developerzy nie znoszą spotkań. Wydają się taką stratą czasu. Jednak w Scrumie spotkań jest sporo. Jak dla niektórych, o wiele za dużo.

Całkowita rezygnacja ze Scrumowych ceremonii nie wchodzi w grę. Są one głównym mechanizmem komunikacji i feedbacku, które umożliwiają empiryzm – czołową przewagę Agile. Czy jednak rzeczywiście dla wszystkich tych ceremonii potrzebujemy spotkań? Nie moglibyśmy zbierać feedbacku w sposób ciągły?

• Czy potrzebujemy organizować daily? Siedzimy przecież razem w tym samym pokoju. Możemy koordynować się na bieżąco, w razie potrzeby, a nie tylko raz dziennie z rana.
• Czemu dokonujemy przeglądu naszej pracy z interesariuszami tylko raz na sprint, jedną dużą paczką? Pracujemy w tym samym biurze. Moglibyśmy dokonywać przeglądu funkcjonalność po funkcjonalności, zaraz gdy tylko jakąś ukończymy.
• Czy nie byłoby lepiej omawiać pomysły ulepszeń natychmiast gdy tylko jakiś wpadnie nam do głowy, zamiast czekać do końca sprintu by zrobić z tego formalne spotkanie?
• Stosujemy ciągłą integrację. Po co w ogóle potrzebne nam są sprinty? Jaką korzyść daje nam wpychanie naszej pracy w arbitralnie przyjęte ramy czasowe?

Spotykam się z wieloma podobnymi argumentami. Co więcej, wydają się brzmieć rozsądnie. W końcu, czy sensem Agile nie jest zbieranie feedbacku tak często, jak to tylko możliwe? Czyż nie jest w duchu XP by podkręcać dobre praktyki na maksa? Dlaczego w takim razie Scrumowe ceremonie są tak sztywno rozplanowane? Czy nie da się wyzwolić spod tej tyranii meetingów? Jakie mogą być zagrożenia?

Dlaczego Scrumowe ceremonie wiążą się z narzuconymi odgórnie spotkaniami?

W skrócie: bo tak jest prościej.

Jawne rezerwowanie określonych bloków czasu na poszczególne ceremonie ma wiele zalet:

• Łatwiej być konsekwentnym; trudniej jest pominąć daną ceremonię, jeżeli mamy na nią zaplanowany z góry blok czasu.
• Łatwiej jest rozplanować pozostałą pracę “wokół” danej ceremonii, jeśli zaplanowaliśmy ją z wyprzedzeniem – dzięki czemu mamy mniej przerwań.
• Łatwiej jest znaleźć (i obronić) czas na daną ceremonię w przypadku presji, jeżeli ta ceremonia jest częścią sztywnego harmonogramu sprintu.
• Łatwiej jest w pełni skupić się na danej ceremonii – i w efekcie wynieść z niej większe korzyści – jeżeli jest ona jawnym, oficjalnym meetingiem (przy wyłączonych komputerach).

Scrum z pełną premedytacją zaleca sztywne, wolne od “przeszkadzajek” bloki czasu dla wszystkich swoich kluczowych ceremonii, by zmaksymalizować szansę iż będą one przeprowadzane dostatecznie często i skutecznie.

Czy w takim razie przeprowadzanie Scrumowych ceremonii w trybie ciągłym jest złe?

Nie, oczywiście że nie. Scrum to tylko pewne rozsądne minimum, punkt startowy od którego możesz – i powinieneś – sięgać dalej. Nie możesz, bez uszczerbku na swojej zwinności, porzucić żadnej ze Scrumowych ceremonii. Zostały one zaprojektowane by się wzajemnie wspierać i nie będą działały nawet w przybliżeniu tak dobrze, jeśli którejkolwiek z nich zabraknie. Jednak więcej dobrego z pewnością nie zaszkodzi.

Niestety, nie jest to takie proste i nie działa na zasadzie “porzućmy sformalizowaną ceremonię a zacznie się dziać w trybie ciągłym sama z siebie, tak po prostu, bo siedzimy razem w tym samym pokoju”. By ceremonie Scrumowe działały w trybie ciągłym, potrzebna jest masa świadomego wysiłku i dyscypliny. I łatwo przy tym wpaść w jedną z wielu pułapek, czychających na niedoszłych “ciągłych” Agile-owców.

Potencjalne pułapki ceremonii Scrumowych w trybie ciągłym.

Odrzucenie narzuconej przez Scrum praktyki nie dlatego, że osiągnęliśmy jeszcze wyższy poziom, ale dlatego, że jest trudna.

Czemu rozważasz przejście na Kanbano-podobne, oparte na płynnym przepływie pracy podejście?

Czy dlatego, że:

• Potrafisz skutecznie kroić Historyjki Użytkownika na nieduże, pionowe wycinki i wdrażać je w trybie ciągłym?
• Ramy sprintu wydają Ci się sztucznym limitem, o wiele dłuższym niż cykl build-release do którego jesteś zdolny?
• Jesteś tak dobry w skutecznej realizacji prac w trybie Just-In-Time, że planowanie historyjek na cały sprint na przód wydaje Ci się marnotrawstwem?

Czy raczej dlatego, że:

• Masz problemy z “upchaniem” jakiejkolwiek wartości biznesowej w tak krótki przedział czasu, jakim jest sprint?
• W efekcie, Twoje Historyjki Użytkownika często “przelewają się” do kolejnego sprintu?
• Czujesz, że ramy sprintu sztucznie ograniczają rozmiar historyjek, nad którymi wolno Ci pracować?

Czy jesteś pewien, że chcesz przejść na Scrumowe ceremonie w trybie ciągłym dlatego, że potrafisz konsekwentnie pracować lepiej niż zalecane minimum, a nie dlatego, że nie umiesz sobie z tym co Scrum zaleca poradzić?

Rozwodnienie ceremonii w takim stopniu, że przestaje przynosić korzyści.

Jeśli zrezygnujesz z daily, czy faktycznie będziesz mieć dość dyscypliny, by wciąż zapewnić feedback i synchronizację, które daily ma na celu?

Oczywiście, byłoby absurdem, by na siłę czekać do następnego poranka by przerzucić karteczkę do innej kolumny tablicy sprintowej lub by poinformować zespół o poważnych przeszkodach w Twojej pracy. Powinieneś to robić na bieżąco.

Co jednak z ewaluacją jak Twój zespół stoi z celem sprintu? Co z planowaniem jak podzielić i zrównoleglić prace pomiędzy wszystkimi członkami zespołu? Czy to również odbywa się na bieżąco? Czy jesteś pewny, że wszyscy członkowie zespołu są równie zorientowani w tym temacie? Czy masz pewność, że wszyscy nadal regularnie poświęcają czas by pomyśleć, jak najefektywniej zespołowo osiągnąć cel sprintu?

I czy jesteś przekonany, że ta synchronizacja nie zostanie zaniedbana pod presją, lub że nie zapomnisz o niej będąc w stanie “flow”, nieświadomy świata wokół siebie?

Redukcja zakresu lub transparentności ceremonii.

Oczywiście, nie ma sensu czekać na zaplanowany przegląd sprintu, jeśli Twoi interesariusze są pod ręką, mają czas i są chętni by przeglądać funkcjonalności jedna po drugiej, zaraz po tym, jak je zakodujesz.

Ale czy zastanowiłeś się:

• Czy wciągasz w tego typu przegląd “w locie” wszystkich Twoich interesariuszy, czy tylko kilku kluczowych? A co z pozostałymi? W jaki sposób mogą obejrzeć wyniki Twojej pracy i dać feedback?
• Co z osobami, które mogą nie mieć czasu na review “w locie” (np. Twój CEO).
• Co z osobami zainteresowanymi jedynie kilkoma wybranymi funkcjonalnościami? Czy potrafisz zidentyfikować wszystkie te osoby? Czy wiedzą one, w jaki sposób mogą dać Ci znać, że są zainteresowane przeglądem konkretnej funkcjonalności? Czy będziesz o nich pamiętać?
• Co z pozostałymi zespołami developerskimi? Czy dla każdego z nich też będziesz przeprowadzać indywidualny przegląd? Czy będziesz przerywać im pracę po kilkanaście razy na sprint, za każdym razem gdy ukończysz jakąś funkcjonalność?

Jesteś pewien, że robiąc przegląd sprintu “w locie” nie sprawisz, że niektóre osoby wypadną z obiegu?

Niezrozumienie interakcji pomiędzy daną ceremonią a pozostałymi.

Scrum to kompletny pakiet. Większość ceremonii ściśle ze sobą współgra, albo zapewnia informacje wejściowe dla innych ceremonii.

OK, zrezygnowałeś więc ze sprintów i wdrażasz funkcjonalności na produkcję w trybie ciągłym. Wyśmienicie! Ale gdy wdrożysz jakąś funkcjonalność, skąd wiesz nad jaką kolejną funkcjonalnością masz pracować? Właśnie wymusiłeś na sobie konieczność, by robić w trybie ciągłym także planning. A żeby móc zrobić dobry planning, musisz mieć feedback od stakeholderów po przeglądzie sprintu i dobrze zgroomowany backlog. Trach! W efekcie reakcji łańcuchowej właśnie skazałeś się na to, by robić w locie również przegląd i grooming.

Nie zrozum mnie źle – robienie wszystkiego w locie jest fantastyczne! Ale czy na pewno rozważyłeś wszystkie implikacje, gdy podejmowałeś decyzję o rezygnacji ze sprintów? Czy zastanowiłeś się, do jakiego wysiłku zmusi to interesariuszy, PO, ekspertów domenowych i inne zespoły developerskie? Jesteś pewien, że Twoja organizacja będzie w stanie to udźwignąć?

Złamanie zasady Focus lub przeprowadzanie danej ceremonii zbyt często.

Stosując daną ceremonię w trybie ciągłym możesz nie tylko ją rozwodnić – można także pójść w przeciwną stronę i dojść z daną ceremonią do przesady. Może się to także przyczynić do złamania pierwszej z 5 Scrumowych wartości: Focus.

Jeśli retrospektywa sprintu jest zaplanowana jako spotkanie, cele są jasne: w trakcie sprintu skupiamy się na dostarczeniu celu sprintu, w trakcie retrospektywy na usprawnianiu naszego procesu. Mamy okazję, by przedyskutować nasze pomysły, zdecydować jakie akcje podjąć, a następnie, podczas planningu, wziąć niezbędny na te akcje czas pod uwagę, tak by nie kolidowały one z naszym celem sprintu.

Rozważ teraz sytuację, w której możesz wychodzić z pomysłami usprawnień kiedy tylko wpadną Ci do głowy:

• Jak możesz przedyskutować taki pomysł ze swoim zespołem? Czy powinieneś natychmiast przerwać im pracę? Czy odłożyć ten pomysł na chwilę, do jakiegoś rodzaju backlogu?
• Jeśli odłożysz pomysł do backlogu, kiedy go przedyskutujesz? Kiedy zdecydujesz, jakie akcje podjąć?
• Kiedy zrealizujesz Twoje pomysły na usprawnienia? W jaki sposób zapewnisz, że nie narazisz na niebezpieczeństwo celu sprintu skupiając się na usprawnieniach za bardzo? W jaki sposób zapewnisz, że w ogóle wcielisz w życie jakiekolwiek usprawnienia, będąc skupionym na swoim celu sprintu?
• Kiedy dokonasz ewaluacji usprawnień, które wcieliłeś w życie?

Czy jesteś pewien, że wiesz w jaki sposób zapewnić odpowiednio wyważony nacisk zarówno na cel sprintu jak i na wdrażanie usprawnień, gdy robisz retrospektywy w trybie ciągłym?

Kiedy więc możemy stosować Scruma bez spotkań?

Scrum jest niczym fabryczny samochód: działa całkiem nieźle prosto z salonu (jeśli tylko wiesz jak go używać i o niego dbać), jednak może działać znacznie lepiej po tuningu. Nie próbuj jednak tuningować samochodu, dopóki nie wiesz dokładnie co robisz. Jest znacznie większa szansa, że go zepsujesz, niż że usprawnisz jego działanie.

Zanim podejmiesz decyzję o przejściu z jakąkolwiek Scrumową ceremonią w tryb ciągły, rozważ czy:

• Rozumiesz wszystkie korzyści, jakie ta ceremonia powinna zgodnie z zamysłem Scruma zapewniać.
• Rozumiesz pełny zakres tej ceremonii: których osób dotyka, w jakie interakcje wchodzi z innymi ceremoniami itp.
• Rozumiesz, które z zalet zaplanowanego z góry spotkania utracisz, przechodząc z daną ceremonią w tryb ciągły, i wiesz, jak zrównoważyć tą stratę.
• Będziesz dostatecznie zdyscyplinowany, by podtrzymywać daną praktykę nawet pod naciskiem czy w obliczu kryzysu.

Jeśli masz jakiekolwiek wątpliwości, istnieje spora szansa, że przejście z daną ceremonią w tryb ciągły okaże się strzałem w stopę.

Co Ty na to?

Co sądzisz o Scrumie bez spotkań? Czy jest to warte zachodu, czy ryzyko jest zbyt wysokie? Jakie jeszcze pułapki takiego ciągłego podejścia dostrzegasz? Podziel się swoją opinią w komentarzach poniżej!