Korzyści z krótszych Sprintów

Jakie korzyści może przynieść praca w krótszych Sprintach? Często w naszej pracy spotykamy zespoły, które pracują w Sprintach trwających nawet 3-4 tygodnie. Naszym zdaniem krótsze Sprinty zwykle są korzystniejsze i pokażemy Ci konkretne argumenty, które to uzasadniają. Dowiesz się też, jak możesz skrócić Sprinty w Twoim zespole.

Ile powinny trwać Sprinty? Jakie są korzyści z krótszych Sprintów? Co zrobić, aby skrócić Sprinty w zespole?

Na powyższe pytania odpowiemy w tym artykule. Osobiście uważamy, że krótkie iteracje mają większy sens i poprzemy to konkretnymi argumentami. Jednocześnie podzielimy się swoim doświadczeniem, prezentując porady, jak możesz skrócić Sprinty w swoim zespole. 

Poprzez długie Sprinty mamy na myśli takie, które trwają 3, a nawet 4 tygodnie i mimo że nie są one mocno popularne, to jednak uważamy, że warto poruszyć ten temat, gdyż jednak wciąż je spotykamy.

Jakie są korzyści z krótszych Sprintów?

Poniższe korzyści poukładaliśmy w kolejności, która odzwierciedla proces pracy zespołu zwinnego.

Krótszy Sprint:

• promuje dekomponowanie pracy – wynika to z tego, że abyśmy zmieścili się z planowaną do wykonania w ramach Sprintu pracą, musimy włożyć w to większy wysiłek, a to z kolei często prowadzi nas do dekompozycji. Dzięki temu jesteśmy w stanie lepiej zrozumieć, co jest do zrobienia, a także możemy szybciej dostarczyć wartość.
  Jeżeli temat dekompozycji Backlogu Produktu jest dla Ciebie interesujący, zapraszamy nasz webinar, który znajdziesz pod adresem porzadnyagile.pl/dekompozycja.
  
• wspiera selekcję wartości i odrzucanie elementów zbędnych – łączy się to ze wspomnianą wcześniej dekompozycją, która wskaże nam, które elementy produktowe są faktycznie wartościowe dla klientów, a które niekoniecznie. Może się na przykład okazać, że ustawienia języka, które były ukryte pod ogólnym hasłem „ustawienia”, nie są aż tak istotne i prawdopodobnie będą używane bardzo rzadko. Taka dekompozycja i krótsze Sprinty motywują do wybierania rzeczy, które naprawdę należy zrobić, bo idą za nimi konkretne uzasadnienia. To czy te pozostałe rzeczy, które zostały uznane za mniej wartościowe, będziemy implementować w kolejnej iteracji czy nie, jest już decyzją biznesową.
  
• ułatwia planowanie – mamy tu krótszy horyzont czasu do zaplanowania, dzięki czemu ustalenie Celu Sprintu będzie prostsze i bezpieczniejsze. Z naszych doświadczeń wiemy, że im dłuższy czas, tym większa szansa, że nasz pierwotny plan się rozjedzie z uwagi na różne nieprzewidziane sytuacje, których wystąpienie jest mniejsze w krótszym odcinku czasu. 
  
• daje częstszą okazję do zmiany – jest to potrzebne z perspektywy biznesowej, zwłaszcza jeśli rynek często się zmienia, pojawiają się nowe okazje lub jakieś ryzyka. W takiej sytuacji dłuższe Sprinty są przyczyną tzw. wrzutek lub przerwania Sprintu i zmiany jego celu. Krótsze Sprinty pozwalają na większą elastyczność i dają szybsze okazje do zmiany kierunku i celu kolejnego Sprintu.
  
• zachęca zespół do wspólnej pracy – zwykle zaplanowanie pracy na trochę krótszy okres, może wymagać omówienia pewnych rzeczy razem z zespołem. W przypadku dłuższych Sprintów często widzimy, że członkowie zespołów po prostu biorą jakieś zadania i mają podejście: na koniec Sprintu jakoś to będzie, bo przecież Sprint jest długi. Jak mamy tylko tydzień, to musimy się dosyć dobrze zastanowić, kto na kogo czeka i jak będziemy współpracować oraz jak doprowadzimy do tego, że w tym dosyć krótkim czy relatywnie krótkim okresie, na koniec Sprintu pojawi się coś użytecznego, namacalnego, co będziemy mogli sklasyfikować jako sensowny przyrost do rozwijanego produktu.
  
• zmniejsza złożoność techniczną rozwiązania – w krótkim Sprincie nie jesteśmy w stanie przekombinować ze złożonością rozwiązania i siłą rzeczy otrzymujemy prostsze rozwiązania od strony technicznej. Prostszy produkt, który zostanie wytworzony w takim krótszym Sprincie, będzie też prostszy do dalszego procesowania. Łatwo go będzie wdrożyć, łatwo będzie można sprawdzić jego jakość.
  Oczywiście zakładamy tu, że zespół nie wdraża co parę minut czy godzin, tylko robi to np. raz na Sprint.
  
• umożliwia częstsze uzyskanie informacji zwrotnej –  dotyczy to sytuacji, gdzie na koniec Sprintu lub iteracji odbywa się jakaś forma przeglądu, spotkania z klientem lub interesariuszami i prezentujemy efekt pracy. Częściej otrzymujemy komentarze, co wyszło sensownie, a co można usprawnić i co dodamy do Backlog Produktu. Mamy tu na myśli rzecz jasna dodatkowe spotkania, nie tylko Przegląd Sprintu.
  
• ujawnia niedoskonałości procesu – pomagają odkryć wąskie gardła procesu, technologii czy na poziomie międzyludzkim, które mogą zostać niezauważone przy dłuższych Sprintach, a spowalniają pracę.
  
• daje częstszą okazję do rozmowy usprawnieniowej – zakładając, że kończymy iteracje czy Sprint jakąś formą Retrospektywy, to im częściej kończymy Sprint, tym częściej mamy szansę, żeby się usprawnić. Mamy też większą szansę, aby porozmawiać między sobą, co się udało, co można poprawić, gdzie pojawiły się problemy, a następnie ustalić działania usprawnieniowe. 

Jeśli te argumenty Cię przekonują lub jesteś procesie wdrożenia krótszych Sprintów w zespole, to wsłuchaj się koniecznie w argumenty osób, które są na nie. Spróbuj wczuć się w perspektywę drugiej osoby i zrozumieć, dlaczego nie jest za krótszymi Sprintami. Być może czegoś nie wyjaśniłeś, a być może ta osoba ma złe doświadczenia z krótkimi Sprintami i  zrozumienie jej obaw może Ci pomóc uniknąć jakichś komplikacji w przyszłości. 

Jak skrócić iteracje w zespole?

Teraz podzielimy się z Tobą naszymi pomysłami i wskazówkami jak wdrożyć krótsze Sprinty w zespole.

1. Nazwij problem długich Sprintów – nie wdrażaj krótszych Sprintów tylko pod wpływem mody na nie, zdefiniuj konkretny problem, jaki teraz widzisz, który jest związany z dłuższymi iteracjami i na podstawie tego zaproponuj to jako opcję jego rozwiązania lub pojawienia się okazji na jakieś usprawnienia.
   
2. Pokaż korzyści dla członków Zespołu Scrumowego i interesariuszy – znając problem, który rozwiążemy krótszym Sprintem, a także mając listę konkretnych korzyści, łatwiej będzie nam przekonać osoby mniej chętne do tego pomysłu.
   
3. Przepracuj wszystkie argumenty na “nie” – niezależnie od tego, że jesteśmy pewni, że osoby będące na nie, się mylą, to wysłuchaj ich argumentów, bo przyczyn tej postawy może być naprawdę wiele. Być może powodem jest brak zrozumienia pewnych praktyk, a może ktoś sobie dorabia trochę dodatkowych i nieprawdziwych historii, które tak naprawdę prawdą nie są.
   
4. Zdobądź sojuszników zmiany – czyli osobę lub osoby, które będą Cię wspierać w przeprowadzeniu zmiany. Jest to szczególnie przydatne, jeśli jesteśmy osamotnieni w tym procesie, bo większość zespołu jest na nie. Taka osoba może w inny sposób przedstawić argumenty za krótszymi Sprintami, może też widzieć inne korzyści, a może po prostu być bardziej przekonująca. Przykładowo nietechniczny Scrum Master inicjujący dyskusje o krótkich Sprintach, ma o wiele łatwiej, mając wsparcie Backend Developera, który jest w stanie bardzo precyzyjnie, używając słów zrozumiałych dla innych programistów, wyargumentować, dlaczego powinniśmy spróbować i co to nam może dać z perspektywy czysto deweloperskiej.
   
5. Rozwiej wszelkie mity – mamy tu na myśli wszystkie te rzeczy, które są nieracjonalne, absurdalne i zwyczajnie nieprawdziwe. Wśród osób niechętnie nastawionych do tego typu zmiany, często powtarzają się takie argumenty oparte na mitach, że np. w krótkim czasie nie da się nic osiągnąć, klient nie chce małych zmian, tylko coś wielkiego. Warto takie argumenty usłyszeć i zastanowić się jak możemy je rozwiać. Dojdźmy pytaniami do uświadomienia stronie, z którą dyskutujemy, że to, co twierdzi to naprawdę absurdalny mit. Zadawajmy pytania, próbujmy zrozumieć, a dzięki temu ta osoba sama zobaczy, że jej logika jest niespójna lub generalizuje.
   
6. Pokaż konkretne techniki – proponując taką zmianę w organizacji albo nawet w trakcie trwania procesu zmiany, warto pokazać konkretne narzędzia, techniki czy podejścia, które mogą nam pomóc w realizowaniu krótszych Sprintów. To mogą być np. techniki dekompozycji, wskazówki, jak lepiej przeprowadzać codzienne stand up-y lub jak efektywniej prowadzić spotkania, żeby trwały krócej. To wesprze zmianę, gdyż sama zmiana długości Sprintu to za mało. Za tym musi pójść też pewna zmiana zachowań.
   
7. Aktywnie wesprzyj zespół w próbowaniu nowych technik i podejść – samo pokazanie technik to jedno, drugie natomiast to wsparcie w ich wdrażaniu. Nie bój się osobiście pomoderować, pokazać pewne działania czy techniki na konkretnych przykładach z danego zespołu. To dla wielu będą zupełnie nowe rzeczy i wchodząc w rolę instruktora ułatw, proces zmiany długości Sprintów i przyzwyczajeń. 
   
8. Podsumuj eksperyment krótszego Sprintu – wyciągaj wnioski już w trakcie i koniecznie dedykuj oddzielny czas na Retrospektywie, aby zobaczyć efekty eksperymentu. Możecie zobaczyć, co się zmieniło po pierwszym Sprincie, jak zespół odnajduje się w nowym trybie pracy, czy kontynuujemy eksperyment, czy nie. Krótszy Sprint może wydobyć na światło codzienne problemy, które do tej pory były ukryte i należy je przepracować, a nie rezygnować z krótkich iteracji, bo są niewygodne i zupełnie różne od przyzwyczajeń.

A jak wygląda kwestia długości Sprintów w Twoim zespole lub firmie? Może podzielisz się z nami swoim doświadczeniem lub wskazówkami, których my nie wymieniliśmy?

Transkrypcja podcastu „Korzyści z krótszych Sprintów”

Kuba: W tym odcinku poruszymy temat korzyści z krótszych Sprintów. Spotykamy w naszej codziennej praktyce zespoły, które mają długie Sprinty. Mamy tu na myśli sprinty 3 albo 4 tygodniowe. Nie ma tych zespołów dużo, ale gdy już się spotkamy, to jest ciężka rozmowa i to często są dosyć ciekawe przypadki. Trudno nam przyjąć argumenty za tym, żeby realizować tak długie Sprinty. Czasami są jakieś argumenty, ale szczerze mówiąc większość z nich nie trafiają do nas. Natomiast ma sens i ten odcinek poświęcimy tematowi argumentów uzasadniających jak najkrótsze iteracje. 

Jacek: O czym powiemy w tym odcinku? Przede wszystkim konkretne argumenty za tym, dlaczego warto pracować w krótkich Sprintach. Dołożymy do tego przestrogę o głosach przeciwko krótkim interakcjom i na koniec podzielimy się swoim doświadczeniem, prezentując porady, jak możesz wprowadzić w swoim zespole krótsze iteracje. 

Kuba: No i przechodząc do sedna, jakie mamy argumenty za krótkimi interakcjami czy krótkimi Sprintami? Poukładaliśmy je w pewnej kolejności, która odzwierciedla proces pracy zespołu zwinnego. Więc Jacek, jaki jest pierwszy argument? Dlaczego warto pracować krótkimi interakcjami? 

Jacek: Krótszy Sprint promuje dekomponowanie pracy. Żebyśmy zmieścili się z pracą, którą prognozujemy wykonać na Sprint, no to im ten Sprint będzie krótszy, tym większy wysiłek musimy włożyć w to, żeby ta praca się w tym Sprincie zmieściła. Prowadzi nas to do dekompozycji, która zwykle powoduje, że po pierwsze, jesteśmy w stanie lepiej zrozumieć, co tak naprawdę jest do zrobienia, a po drugie jesteśmy w stanie szybciej dostarczyć wartość. Jeżeli temat dekompozycji Backlogu Produktu jest dla Ciebie interesujący, sprawdź nasz webinar pod adresem porzadnyagile.pl/dekompozycja.

Kuba: Drugi argument za krótszymi Sprintami to to, że wspierają selekcję wartości i odrzucanie elementów zbędnych. To się silnie łączy ze wspomnianą przez Jacka dekompozycją. Jak już coś dużego zdekomponujemy na mniejsze elementy produktowe, to może się dosyć łatwo okazać, że wewnątrz większego kawałka były rzeczy wartościowe, ważne, bardzo potrzebne, potrzebne dużej części klientów. I takie elementy, które tak się wiozą na doczepkę. Jak myśleliśmy, że zrobimy całe ustawienia, to chcieliśmy to zrobić. Jak zdekomponowaliśmy to na jakieś cząstki składowe, to się okazało, że ustawienia języka nie są w naszym produkcie aż tak istotne, ponieważ i tak i tak czujemy, że będą używane super rzadko. Więc tutaj krótsze Sprinty niejako wymuszają, zachęcają, powodują, że zespół musi zastanowić się, co tu jest wartościowe. No bo wszystkiego w jednym Sprincie nie zmieścimy i może się okazać, że tak troszkę pośrednio. To, co może być w pierwszym odruchu lekko niewygodne, staje się jakąś taką zachętą czy dopingiem do tego, żeby spośród wielu rzeczy, które można zrobić, wybrać te, które naprawdę trzeba zrobić i je zrobić. W pierwszej kolejności je zmieścić do trochę krótszej iteracji. Czy będziemy te pozostałe dorabiać w kolejnej iteracji czy nie, to to już jest decyzja biznesowa, decyzja Product Ownera na przykład.

Jacek: Kolejny argument, krótszy Sprint ułatwia planowanie. Przez to, że w krótszym Sprincie mamy trochę krótszy horyzont w przód, no to planowanie z jednej strony jest trochę bezpieczniejsze, dlatego że nie musimy wybiegać aż tak daleko w przyszłość. Po drugie, Cel Sprintu, który mamy do osiągnięcia, zwykle też będzie trochę prostszy. Stąd też ta nasza prognoza zakresu, którą będziemy realizować, również będzie krótsza. Im dłuższy czas, na bazie moich doświadczeń, tym większa szansa, że ten nasz pierwotny plan się rozjedzie, ze względu na różne sytuacje nieprzewidziane. Tak więc w momencie, kiedy planujemy na trochę krótszy okres czasu, to automatycznie zawężamy sobie możliwość tego, że jakieś nieprzewidziane sytuacje się wydarzą. No i też krótszy Sprint powoduje, że nie musimy obejmować naszą świadomością tak rozległego obszaru czasowego. 

Kuba: I z tym planowaniem może być tak, że różne zespoły będą miały na ten temat różne zdanie. Ale ja obserwuję to, że nieproporcjonalnie łatwiej zaplanować na przykład tygodniową pracę, niż dwutygodniową pracę. Bo tutaj ta ilość zmiennych do ogarnięcia, ta ilość rzeczy, o których trzeba pamiętać, po prostu zaczyna, zaczyna narastać na tyle dużo, że ten plan jest trudny do osiągnięcia. No i niektóre zespoły realizują coś w stylu takim jak zespół, z którym aktualnie współpracuję, który po prostu jawnie mówi drugiego tygodnia Sprintu to praktycznie nie jesteśmy w stanie zaplanować i tego nie robią. Zaplanowanie parę dni w przód, bo to realnie w przypadku tygodniowego Sprintu, mówimy o raptem 3,5, 4 dniach wprzód, to to jest dosyć łatwe i moim zdaniem proporcjonalnie łatwiejsze niż dwa razy dłuższy dwutygodniowy Sprint. 

Kuba: Następny argument za krótkimi Sprintami to to, że dają częstszą okazję do zmiany. Tak jak poprzedni argument był z tą perspektywą wygody zespołu, tak ta częstsza okazja do zmiany, to jest perspektywa potrzebna biznesowo. Czy to interesariuszom, czy to Product Ownerowi. Zwłaszcza jeśli strona biznesowa jest zmienna, jeśli jest zmienny rynek, dużo nowych okazji się pojawia, albo też takich negatywnych ryzyk się aktywuje. To może się okazać, że dłuższe Sprinty są niewskazane i dłuższe Sprinty powodują taką presję na tzw. wrzutki. Na na przykład przerwanie Sprintu i zmianę Celu Sprintu. I tutaj krótsze Sprinty powodują, że trochę łatwiej zaabsorbować taką sytuację. Pojawia się jakaś potrzeba zmiany i tak naprawdę już za parę dni pojawi się okienko, w którym możemy sobie nowy Cel Sprintu zaplanować, albo okienko, żeby podjąć coś do zakresu Sprintu. Więc jest mniej presji na to, żeby tak powiedzmy negatywnie wpływać na toczący się Sprint, bo to też ten horyzont, czy te otwierające się drzwiczki do nowego Sprintu są tuż, tuż, za chwilę. Więc tutaj okazja do zmiany, czy to z perspektywy Product Ownera, czy z perspektywy interesariuszy, którzy mają jakieś potrzeby czy życzenia co do tego, co ma być w produkcie w najbliższym czasie pilnie, albo ważnie zrealizowane.

Jacek: Jak słyszysz Tych argumentów jest całkiem sporo, a jeszcze kilka przed nami. Krótszy Sprint zachęca zespół do wspólnej pracy. Mianowicie zwykle zaplanowanie pracy na trochę krótszy okres czasu, może wymagać tego, że będziemy musieli pewne rzeczy dobrze omówić w zespole. Na przykład na skutek tego, że w sposób drobiazgowy przeprowadzimy dekompozycję no i będziemy chcieli też zapewne zapewnić to, że na koniec Sprintu otrzymamy faktycznie coś namacalnego. Więc całą tę pracę, która jest konieczna do zrealizowania celu Sprintu, będziemy musieli dobrze zaplanować. W dłuższych Sprintach widzę, że zespoły łatwo idą w taki kierunku, jak biorę swoją pracę i po prostu na koniec Sprintu będzie, jakoś to będzie, no bo ten Sprint jest długi. Jak mamy tydzień przykładowo, no to tak naprawdę musimy dosyć dobrze się zastanowić, kto na kogo czeka, jak będziemy współpracować. No i jak doprowadzimy do tego, że w tym dosyć krótkim czy relatywnie krótkim okresie, na koniec Sprintu pojawi się coś użytecznego, namacalnego, co będziemy mogli sklasyfikować jako sensowny przyrost do rozwijanego produktu.

Kuba: Kolejną zaletą krótszych czy krótkich Sprintów jest to, że siłą rzeczy zmniejszają one złożoność techniczną rozwiązania, tak jak wspólna praca z Jacka korzyści. Wymaga tego gramatyka. Jeszcze raz. Kolejną zaletą krótszych sprintów jest to, że krótszy Sprint zmniejsza złożoność techniczną rozwiązania. Jacka poprzedni argument mówił o tym, że siłą rzeczy musimy pracować całym zespołem, żeby w ogóle osiągnąć jakiś rezultat. Ta moja uwaga jest o tym, że w krótkim Sprincie po prostu nie jesteśmy w stanie przekomplikować rozwiązania i siłą rzeczy te prostsze trochę rozwiązania od strony technicznej. Prostszy produkt, który zostanie wytworzony w takim krótszym Sprincie, będzie też prostszy do dalszego procesowania. Łatwo go będzie wdrożyć, łatwo będzie może sprawdzić jego jakość. Jeśli się zdarzy czarniejszy scenariusz, że na przykład będzie jakiś błąd, jakiś jakiś problem z wdrożeniem, to też mniejszą porcją pracowaliśmy i ją wypuszczamy. Oczywiście w tym, co mówię jest pewne założenie, że zespół nie wdraża co parę minut albo co parę godzin, tylko robi to powiedzmy raz na Sprint. No ale tutaj jednak mimo wszystko w praktyce często widzimy, że te rzeczy są dosyć powiązane. No i za duża ilość czasu może wygenerowywać też trochę zbyt skomplikowane kawałki produktu, zbyt skomplikowane rozwiązania. A ta prostota tutaj może być bardzo ważną zaletą i ona może być, tak troszkę znowu użyję słowa wymuszona przez to, że tego czasu nie ma aż tyle. No i preferowane będą przez zespół, preferowane będą przez Product Ownera te rozwiązania, które się w tym Sprincie krótkim po prostu zmieszczą. 

Jacek: Kolejny argument. Krótkie Sprinty umożliwiają częstsze uzyskiwanie informacji zwrotnej. Mówię tutaj o przypadku, w którym na koniec Sprintu, czy na koniec iteracji odbywa się jakaś forma przeglądu, dema czy spotkania z klientem, czy interesariuszami, gdzie jesteśmy w stanie pokazać efekt naszej pracy. No i wystawić ten efekt pracy na światło dzienne, żeby usłyszeć komentarze, co w tym produkcie wyszło sensownie, co moglibyśmy usprawnić? Może pojawią się jakieś pomysły, które dodamy do naszego Backlogu Produktu. I oczywiście mówię to w takim założeniu, że pracujemy w zespole, który nie korzysta z częstszych okazji do tego, żeby wystawiać efekty swojej pracy na światło dzienne. Mówię o tym dlatego, żebyś nie zrozumiał, czy nie zrozumiała tego w ten sposób, że Przegląd Sprintu, jeśli mówimy o Scrumie, że to jest jakby jedyna okazja, kiedy możemy pokazać produkt. Oczywiście tak nie jest. Natomiast bardzo często zespoły po prostu nie wykorzystują tej szansy, żeby pokazywać efekty pracy wcześniej, stąd korzystają po prostu z instytucji Przeglądu Sprintu. Tak więc jeżeli możemy spotykać się z interesariuszami co tydzień, a nie tylko raz na miesiąc, to niewątpliwie jest to korzyść, bo mamy cztery razy szansę na to, żeby dostać feedback i wykorzystać ten feedback. Na zasadzie, być może skręcić trochę w kontekście tego, jaki mieliśmy plan rozwoju albo to, co padło we wcześniejszych punktach, częściej będziemy w stanie też zareagować na zmianę, którą dostaniemy od interesariuszy. 

Kuba: Przedostatni argument za krótkimi Sprintami to to, że krótszy Sprint ujawnia niedoskonałości procesu. To jest taki pewien paradoks. Coś. co może być nieintuicyjne, że zespół, który ma na przykład trzytygodniowe Sprinty i mówi, że to nie da się pracować inaczej, ponieważ mamy taki proces wdrożeniowy, takie zarządzanie środowiskami. Tak, jesteśmy rozdzieleni, na przykład kompetencyjne, i szereg konkretnych argumentów. No to tutaj metody zwinne raczej mocno mówią, no właśnie, musicie jeszcze częściej iterować. Bo te powody, dla których nie robicie tego często, tak naprawdę są do usunięcia. One was spowalniają, one usuwają takie okazje do zwinności i biznesowej i na tym poziomie, powiedzmy procesowym czy technologicznym. Czyli przez konkretne historie, takie krótsze Sprinty ujawniają schowane wcześniej, albo aż tak nie bolące, wąskie gardła niedoskonałości, czy to technologii wytwarzania, czy procesu, ale też na takim poziomie międzyludzkim. Między innymi wspiera się krótszym Sprintem, wspiera się te wszystkie rzeczy, które wymienialiśmy, czyli współpracę, lepsze zrozumienie, dobrą dekompozycję. No i tak naprawdę te niedoskonałości procesu przy długich iteracjach sobie są. Wokół nich planujemy, akceptujemy je, możemy sobie pozwolić na pewne przestoje, bo przecież mamy mnóstwo zakresu wziętego do tak długiego Sprintu, a tu jest taka gra w naprawdę intensywną współpracę i intensywne dostarczanie. I teraz dzień przestojów w trzytygodniowym Sprincie nie boli, a dzień przestojów tygodniowym Sprincie, no to jest powiedzmy, jedna czwarta, jedna piąta czasu, jaki w ogóle mamy do dyspozycji. Tego już absolutnie nie ma szans nadrobić. Więc tutaj, to może tak trochę na poziomie filozofii pewnej, już może samej transformacji zwinnej, ale wprowadzenie czy zachęcenie, skrócenie tych cyklów, w jakich pracuje organizacja, może być kłopotem, wyzwaniem, może być bardzo trudne, może wygenerować masę rzeczy do poprawy, ale w efekcie tak naprawdę realnie właśnie odkrywamy ten fragment przyczyn sukcesu zwinności. To, że możemy naprawdę szybko dostarczać rozwiązania, szybko zmieniać kierunki. A żeby to osiągnąć, musimy zainwestować i usunąć niedoskonałości procesowe. 

Jacek: I przechodzimy do ostatniego argumentu. Krótszy Sprint daje częstszą okazję do rozmowy usprawnieniowej. Zakładając, że kończymy iteracje czy Wprint jakąś formą Retrospektywy, to im częściej kończymy Sprint, tym częściej mamy szansę, żeby się usprawnić. Jest to komentarz w pewnym sensie podobny do częstszego uzyskiwania informacji zwrotnej. Na takiej zasadzie, że oczywiście Retrospektywa na koniec Sprintu nie jest jedyną, jedyną okazją do tego, żeby się usprawnić. Natomiast bardzo często głębsze dyskusje przeprowadzane są właśnie na tego typu wydarzeniu. No więc naturalnie, im częściej celebrujemy moment zakończenia Sprintu, tym częściej mamy szansę porozmawiać o tym, jak nam ten Sprint poszedł, co było dobre, co działało tak sobie, co nie działało. No i ustalić konkretne akcje, usprawnieniowe. 

Kuba: I jak już skończyliśmy wymieniać te ładnie ustrukturyzowane argumenty za krótkimi Sprinta, to taka bardzo ważna przestroga. My we dwóch z Jackiem jesteśmy strasznie przekonani do krótszych Sprintów. Pewnie też w przekonywujący sposób oddziałujemy na osoby, z którymi pracujemy. Natomiast, żebyśmy się tutaj nie zapędzili. To, że my jesteśmy przekonani, to że to do nas trafia i to jest w zasadzie jedyny logiczny kierunek i jedyna słuszna wersja, może spowodować, że będziemy nie ostrożni, głusi. Nie dyplomatyczni, jeśli chodzi o interakcję z osobami, które tych argumentów albo nie znają, albo ich nie przyjmują, albo chowają się za jakąś pulą argumentów przeciwnych, argumentów na nie. Być może mają jakieś złe skojarzenia albo mity. Więc tutaj bardzo ważna taka uwaga, już przechodząca płynnie pomiędzy argumentami za krótkimi Sprintami, a poradami jak to zrobić dokładnie. No to przestroga o tym, żebyśmy się, jeśli jesteś słuchaczu lub słuchaczu, w sytuacji, której przeprowadzasz, czy szykujesz się do przeprowadzenia takiej zmiany długości Sprintów w swoim zespole, to wsłuchaj się koniecznie w argumenty osób, które są na nie. Łatwo wpaść w tutaj ekscytację i od razu szarpać i opluć człowieka dziesięcioma argumentami na korzyść krótkich Sprintów, ale jednak tutaj dobrze wczuć się w perspektywę tej innej osoby, spróbować zrozumieć, co ona myśli, czego się boi, może właśnie jakie ma jakieś złe doświadczenia z przeszłości. Być może są pewne rzeczy, które są niedopowiedziane w Twojej komunikacji, które powodują, że ta osoba jest nie przekonana. Warunków, okoliczności może być cała masa. I tutaj nie uzyskamy zmiany tylko poprzez spójną logikę argumentacji za naszą zmianą. Musimy też jakby zrozumieć i widzieć świat oczami tej drugiej strony. Pokazać empatię.

Jacek: Tak jak słyszysz jest cała masa argumentów za tym, dlaczego warto pracować krótszymi iteracjami. Kuba dopowiedział ten ważny aspekt, żeby jednak posłuchać drugiej strony, a nie tylko zasypać tą masą argumentów. Natomiast mamy też porcję porad, jak konkretnie można podejść czy na co zwrócić uwagę, kiedy chcemy skrócić iteracje w zespole. Od czego byś się zaczą Kuba? 

Kuba: Najważniejsze wydaje mi się to, żeby nazwać problem długich Sprintów. Czyli tutaj zdefiniować w ogóle problem. Bo może być tak, że tutaj mamy chęć zmiany, bo na przykład właśnie w przekonywujący sposób w tym odcinku pokazaliśmy, że są korzyści, żeby skrócić Sprint z dwóch tygodni do jednego tygodnia. Ale nie róbmy to tylko dlatego, że to brzmi sensownie, albo że to brzmi jak jakaś moda. Zróbmy to raczej pod hasłem rozwiązania jakiegoś konkretnego problemu, albo pojawienia się czy otworzenia jakiejś nowej okazji, czy jakiegoś nowego usprawnienia. Więc wielkim testem dla na przykład Scrum Mastera czy Agile Coacha w takim zespole, albo lidera, może być próba pokazania, jakie są obecne konsekwencje długości Sprintów, które mamy i okazja do pokazania też jakichś argumentów, które są kontekstowo dobrane do konkretnie naszej sytuacji, czy konkretnie do naszego zespołu.

Jacek: Kolejna podpowiedź pokaż korzyści dla członków Zespołu Scrumowego. Czyli z jednej strony musimy rozumieć jaki mamy problem, to co powiedział Kuba, ale jest też sporo korzyści, które płyną z krótszych Sprintów i część z nich wynika z tej listy, którą przed chwilą przedstawiliśmy. Oprócz członków Zespołu Scrumowego, no to taką grupą, która może odczuć potencjalne korzyści, są oczywiście szeroko rozumiani interesariusze. Tak więc warto też o nich pamiętać, bo możemy się spotkać z naturalnym oporem na zasadzie, a dlaczego mam poświęcać więcej czasu i częściej do was przychodzić? Warto dobrze tę grupę interesariuszy rozpoznać, zaopiekować, no i generalnie zaprosić zarówno tą część zespołową, jak i interesariuszy do wspólnego eksperymentu, który może oznaczać, że tak naprawdę, jeżeli rezultaty nie będą przekonujące i nie będą wartościowe, no to zawsze z takiego eksperymentu możesz się wycofać.

Kuba:Trzecia porada brzmi przepracuj wszystkie argumenty na nie. Niezależnie od tego, że my przekonani jesteśmy. Niezależnie od tego, że mamy też silne przeczucie, że ta druga strona w naszej dyskusji o tym skracaniu będzie się mylić, to i tak przedyskutujemy na spokojnie. Posłuchajmy te argumenty, te przemyślenia osób, które są przeciwne, czy odrzucają zaproszenie do naszego eksperymentu, jak powiedział chwilę temu Jacek. Bo może się okazać, że tak naprawdę to jest na przykład brak zrozumienia pewnych praktyk. To może być coś, co spokojnie sobie przedyskutujemy, spokojnie wymienimy się argumentami. Być może ktoś sobie dorabia trochę dodatkowych historii, które tak naprawdę prawdą nie są. I tutaj jakby nie odrzucajmy, czy nie przegapmy okazji do tego, żeby odrobinę poprzekonywać, odrobinę ponamawiać, czy po prostu wzajemnie się spróbować zrozumieć. 

Jacek: Co dalej? Zdobądź sojuszników zmiany. Może być tak, że ktoś cierpi na tym, że obecna długość Sprintu jest dosyć długa. Taka osoba może być bardzo fajnym sojusznikiem, czyli kimś, kto będzie pomagał nam przeprowadzić zmianę. Jest to bardzo duża wartość, w szczególności w sytuacji, gdy osoba, która inicjuje propozycję skrócenia Sprintu jest absolutnie osamotniona. Wtedy bardzo łatwo jest ustawić się w taki sposób, że tylko ja chcę, a tak naprawdę 9 pozostałych osób w zespole ma przeciwne zdanie. Więc warto wyszukać wśród tych osób te, które będą beneficjentami tego, że Sprinty będą trochę krótsze i wtedy co zyskujemy? Zyskujemy to, że to nie będzie już taki jednogłos, tylko być może dwugłos. W pozytywnym tego słowa znaczeniu. I być może też ktoś przedstawi swoje argumenty, które są inne od naszych, albo przedstawi je językiem, który dla grupy, do której będzie mówić, będzie bardziej przekonujący. Czyli na przykład nietechniczny Scrum Master inicjujący dyskusje o krótkich Sprintach, otrzymuje wsparcie Backend Developera, który jest w stanie bardzo precyzyjnie, używając słów zrozumiałych dla innych programistów, wyargumentować, dlaczego powinniśmy spróbować i co to nam może dać z perspektywy czysto deweloperskiej.

Kuba: Kolejną poradą przy skutecznym wprowadzeniu krótszych Sprintów jest rozwiej wszelkie mity. Chwilę temu mówiłem o argumentach na nie i to mogą być bardzo racjonalne, uzasadnione powody, że są osoby niechętne, albo są osoby wręcz przeciwne zmianie. Natomiast w poradzie o rozwiązywaniu mitów jednak poruszmy ten temat, te rzeczy, które są nieracjonalne, absurdalne, po prostu bardzo, bardzo nieprawdziwe czy bardzo, bardzo niewłaściwe. I tutaj łatwo i powtarzają mi się takie teoretyczne argumenty, ale właśnie opierające się o mity. Między innymi mit typu, w tak krótkim czasie to nam się nic nie da, nie uda osiągnąć. Albo taki bardziej produktowy mit, czyli przecież klient by nie chciał takich drobnych zmian. Klient potrzebuje czegoś wielkiego. I tego typu argumenty się powtarzają. Z biegiem lat i doświadczenia to ta kolekcja robi się bardzo długa. Ja nie chcę chyba teraz jej specjalnie za długiej wymieniać. Natomiast warto takie argumenty złapać, warto je usłyszeć i zastanowić się, czy umiemy je odbić, albo wręcz pokazać pewien absurd. Błąd logiczny w myśleniu, czy jakieś niesłuszne generalizacje. Bo tutaj te mity to często będzie też odrobina manipulacji, jakiś brzegowy pojedynczy przypadek, który urasta do natury takiej generalnej i ogólnej zasady, że przecież raz tam kiedyś trzy lata temu coś nam nie wyszło, to teraz już na pewno nam nigdy nie wyjdzie. Więc tutaj musimy pewnie wspiąć się na wyżyny dobrego argumentowania, ale też pokazania pewnego absurdu. Sam z doświadczenia najczęściej w takich sytuacjach daję mówić drugiej stronie, czyli raczej metoda sokratejska. Dojdźmy pytaniami w takiej dyskusji do ujawnienia czy uświadomienia stronie, z którą dyskutujemy o jakimś micie, że ten mit tak naprawdę jest absurdalny. Żeby to ta osoba głośno sama sobie zaprzeczyła. Czasami nie wpadniemy w taką pułapkę dyskusji czy takiego wymieniania się na argumenty, bo to może to może być czasami ślepa uliczka. Zadawajmy pytania, próbujmy zrozumieć i może się dosyć łatwo okazać, że ta osoba właśnie generalizuje. Jej logika jest niespójna i poradzimy sobie z tym etapem.

Jacek: Kolejna wskazówka, jak skrócić iterację w zespole brzmi, pokaż konkretne techniki. Bardzo ładnie sobie z Kubą opowiadaliśmy o tym, dlaczego warto, jak w ogóle do tego podejść, ale jestem w stanie sobie wyobrazić, że w końcu padnie pytanie, no dobrze, ale jak to konkretnie zrobić? Więc warto przygotowując się w ogóle do takiej propozycji, albo już w trakcie trwania takiej zmiany być gotowym podpowiedzieć konkretne narzędzia, techniki czy podejścia, które mogą nam pomóc w realizowaniu krótszych Sprintów. To mogą być zarówno techniki dzielenia pracy na mniejsze kawałki, czyli techniki dekompozycji. To mogą być jakieś lepsze sposoby planowania, np. planowanie wizualne. To mogą być wskazówki, jak lepiej przeprowadzić codzienne stand up czy generalnie jak prowadzić efektywniejsze spotkania po to, żeby te spotkania trwały krócej. I żebyśmy mieli po prostu poczucie, że zwrot z inwestycji z takiego spotkania ma sens. Tak więc warto się przygotować. Bo moim zdaniem, na bazie mojej praktyki, na pewno te praktyki będą konieczne. Sama zmiana długości Sprintu to jest za mało. Za tym musi pójść też pewna zmiana zachowań.

Kuba: I tak jak pokazanie konkretnych technik jest potrzebne, to samo pokazanie to też będzie za mało. Więc następna porada to aktywnie wesprzyj  zespół w zastosowaniu tych nowych podejść. Tu może się okazać, że pierwsze próby będą dosyć nieudolne, że niekoniecznie nam wyjdzie aż tak różowo jak obiecywała technika, czy obiecywał autor tej techniki. No ale mimo wszystko próbujmy, dążmy, bądźmy bardzo aktywni. Tutaj czasami spotykam Scrum Masterów trochę za pasywnych na takim etapie zmiany. Tutaj nie bójmy się zakasać rękawy, osobiście może troszkę mocniej pomoderować, pokazać pewne działania czy pewne techniki na bardzo konkretnych życiowych przykładach z tego konkretnego zespołu. I tutaj ta aktywność musi być pewnie chwilę trochę mocniejsza. Może wchodzimy w trochę bardziej taką postawę instruktora, nauczyciela, mniej takiego coacha siedzącego sobie na rękach i czekającego, aż zespół sam sobie poradzi, czy sam się zorganizuje. Bo gdy wprowadzamy zmianę, to zespół też jest może mniej kompetentny. Czy na przykład wprowadzamy nową technikę, której zespół po prostu w ogóle nie zna. Tutaj nie bójmy się, żeby kontekstowo dobrać taką postawę o wiele bardziej aktywną, żeby być może dopiero po ugruntowaniu, czy wejściu w krew tej techniki wyjść z powrotem do takiej faktycznie postawy bardziej w drugim szeregu, gdzie zespół przejmuje całą odpowiedzialność, czuje się też sam, samodzielnie zarządzający swoim procesem.

Jacek: I ostatnia porada na koniec, odnośnie skracania iteracji w zespole. Podsumuj eksperyment krótszego Sprintu. Myślę, że to jest w pewnym sensie generyczna porada. Na takiej zasadzie, że jak decydujemy się na zmianę, to musi nastąpić moment, kiedy dokonujemy refleksji. Czy to na co się zgodziliśmy, prowadzi nas do tych rezultatów, które sobie zakładaliśmy na początku. Więc tutaj zarówno możemy wyciągać wnioski tak na gorąco, czyli w trakcie naszej pracy, jak również warto dedykować sobie taki konkretny slot, nawet jako element Retrospektywy. Po to, żeby upewnić się, że ta zmiana nie pozostanie gdzieś tam zawieszona w powietrzu, tylko faktycznie się zastanowimy. Zrobiliśmy tę zmianę. Jesteśmy po pierwszym Sprincie, właściwie jesteśmy jeszcze w trakcie trwania pierwszego Sprintu, no ale już na samym końcu. Tak naprawdę co się zmieniło? Jak się z tym czujemy? Co nam wyszło? Co nie wyszło? Czy kontynuujemy eksperyment, czy nie? Tak więc zdecydowanie jest to coś, na co warto poświęcić czas. Jak zresztą na każdą większą zmianę. I nie próbowałbym raczej przechodzić wobec takiej zmiany bez komentarza. Czasem słyszę argumenty, no przecież wszyscy widzą jak jest, tylko jednak zastanowił się i stworzył też przestrzeń, żeby argumentacja, zarówno za i przeciw, jak i wszelkiego rodzaju komentarze, po prostu porządnie wybrzmiała w zespole.

Kuba: Zwłaszcza że to, co już trochę w odcinku powiedzieliśmy. Ta zmiana może wygenerować na przykład ujawnione niedoskonałości procesu, albo niepotrzebne nowe zachowania, nowe techniki, z którymi nie czujemy się aż tak komfortowo. I tutaj jest niezwykle wysokie zagrożenie. Akurat przy tej konkretnej zmianie, przy tym typie zmiany, jest spore zagrożenie, że te trudności, te niedoskonałości będą argumentem za tym, żeby wrócić do starego. Czyli ten tutaj taki samobalansujący się świat, w którym spróbowaliśmy czegoś trudnego, nie do końca nam wyszło, nieodpowiednio to przepracowaliśmy, więc wracamy do tego, co nam do tej pory pasowało. Czyli nie uzyskamy korzyści, ponieważ trudności jakie są po drodze, nas od tych korzyści jakby odciągają, czy nam nie pozwalają tam dotrzeć. Więc tutaj warto to podsumować. Warto to przepracować i być może nawet warto zbudować sobie plan działania, jak poprawić niedoskonałości procesu, żebyśmy mogli pracować tymi krótszymi iteracjami.

Kuba: Podsumowując cały odcinek. Dlaczego warto pracować krótszymi iteracjami? Krótki Sprint promuje dekomponowanie pracy. Wspiera selekcję wartości i odrzucenie elementów zbędnych. Ułatwia planowanie. Daje częstszą okazję do zmiany.

Jacek: Zachęca zespół do wspólnej pracy. Zmniejsza złożoność techniczną rozwiązania. Umożliwia częstsze uzyskiwanie informacji zwrotnej. Ujawnia niedoskonałości procesu i daje częstszą okazję do rozmowy usprawnieniowej.

Kuba: Temat wprowadzenie zmiany w zespole, tak jak go eksplorowaliśmy w tym odcinku, w jego drugiej części, wraca też regularnie też przy case study’ies, jakie poruszamy na Prawdziwych Przypadkach Scrumowych. Już od dwóch odcinków zapraszam na te warsztaty. Zostało jeszcze kilka miejsc. Grupa, która już się zapisała, grupa, która już potwierdziła udział nie może się doczekać tych warsztatów. Natomiast jeśli jeszcze się wahasz, no to może być tak, że to jest ostatnia możliwa okazja, żeby do tych warsztatów dołączyć. Zapisy, więcej informacji, informacja o wolnych miejscach, bo w momencie, kiedy to nagrywamy jest ileś, ale może być tak, że w międzyczasie parę miejsc też jeszcze zniknie, wszystkie te informacje znajdziesz na stronie 202procent.pl/przypadki-scrumowe

Jacek: Natomiast notatki do tego odcinka, artykuł, transkrypcję, oraz zapis wideo, znajdziesz na stronie: porzadnyagile.pl/96

Kuba: I to by było wszystko na dzisiaj. Dzięki Jacek

Jacek: Dzięki Kuba i do usłyszenia wkrótce.