Porządny Sprint

Jaka jest definicja Sprintu? Jak powinien wyglądać Sprint? Przedstawiamy sześć porad, jak powinno się wykonywać i organizować Sprint. Niezależnie od tego, czy jesteś Agile Coachem, Scrum Masterem czy członkiem zespołu – wśród naszych propozycji możesz znaleźć taką, która korzystnie wpłynie na to, jak funkcjonuje Sprint w Twoim zespole.

Jak powinien wyglądać Sprint?

Jak go zdefiniować i naprawdę dobrze wykonać? Dowiedz się jak prawidłowo zorganizować Sprint, aby wykorzystać z korzyści, jakie daje.

Artykuł ten dedykujemy zarówno Agile Coach’om, jak i Scrum Masterom oraz członkom zespołów, gdyż każda z tych ról ma wpływ na przebieg Sprintu. 

Wyjdźmy od tego, czym Sprint jest, a czym nie jest. Popularnymi mitem, z jakim się spotykamy i któremu teraz chcemy stanowczo zaprzeczyć to to, że Sprint nie jest takim mini-waterfallem.

“Przewodnik po Scrumie” definiuje Sprint jako: Ograniczenie czasowe (nie dłuższe niż miesiąc), w którym powstaje produkt; w ramach tego miesiąca Zespół Scrumowy wykonuje pracę, a na koniec uzyskuje Przyrost. Dodamy jeszcze tutaj ważny aspekt tego, że Scrum określa Sprint jako swego rodzaju sposób na limitowanie ryzyka, dzieląc działania na mniejsze części i ciągle sprawdzamy efekty i ewentualne problemy. Dzięki temu szybko możemy zareagować i zarządzić procesem.

Jak widzisz, w Scrumie do ryzyka podchodzimy w sposób empiryczny, czyli zamiast odpowiadania sobie, jakie są ryzyka i jaki mamy plan mitygacji, to z uwagi na to, że na koniec Sprintu mamy coś dostarczyć, te ryzyka muszą być jak najbardziej widoczne i transparentne dla wszystkich zainteresowanych inicjatywą, projektem czy produktem, który rozwijamy.

W wielu projektach prowadzonych bez Sprintów często jest dużo zabawy w złudzenia, że coś nadrobimy, może coś się odblokuje, może zakupiony sprzęt, na który czekamy, wreszcie dojdzie. Sprint podchodzi do takich sytuacji bardzo brutalnie: jeśli w pierwszym Sprincie Ci się nie udało, to jasno powiedzcie sobie, że mimo intensywnej pracy przez ostatni okres, nie jesteście w stanie pokazać czegokolwiek.

Ma to dużą wartość, gdyż takie Przeglądy Sprintu, podczas których zespół nie jest w stanie nic pokazać, chociaż wykonał ogrom pracy, jest często mocnym impulsem, zwłaszcza dla managementu, że są jakieś przeszkody na drodze, które mogą spowodować, że możemy nie dostarczyć produktu.

Jak przeprowadzić porządny Sprint?

Podzielimy się teraz z Tobą 6 konkretnymi wskazówkami jak prawidłowo podchodzić do Sprintu, czyli jak przeprowadzić porządny Sprint. 

Oczywiście nie wszystkie nasze porady i sugestie sprawdzą się w Twoim przypadku, dlatego zastanów się, która z nich może wesprzeć Sprinty w Twoim zespole.

1. Miej Przyrost na koniec każdego Sprintu

Z naszej perspektywy takim najprostszym wskaźnikiem mówiącym o tym, czy zespół faktycznie w sensowny sposób wykorzystuje Scruma, jako narzędzie do rozwiązywania problemów jest to, czy na koniec Sprintu mamy jakiś konkretny Przyrost Produktu. 

Przykładowo, jeśli tworzymy aplikację cyfrową, to mówiąc o Przyroście Produktu, mamy na myśli jakiś kawałek tej aplikacji, dający możliwość jej zobaczenia, kliknięcia, przetestowania bardzo uproszczonej funkcjonalności. Dla nas przyrostem nie jest spisana część backendowa czy stworzone makiety. To tylko elementy składowe, a to, co nas powinno interesować to to, czy potrafimy zebrać w całość te wszystkie elementy składowe tworzone przez inne osoby i co w tak krótkim okresie Sprintu jesteśmy w stanie dostarczyć.

Nawiązując do wcześniej wspomnianego backendu, warto powiedzieć sobie, po co w ogóle mieć przyrost co Sprint. A to szybko przenosi nas do tematu ryzyk, bo np. właśnie mając ten backend, który nie jest jeszcze połączony z frontendem i nietworzący produktu, może zawierać w sobie wiele ryzyk jak: ryzyko integracji, ryzyko niedociągnięć technologicznych czy ryzyko złego zrozumienia wymagań. Póki nie jesteśmy w stanie całościowo spojrzeć na produkt, to nie wykryjemy tych ryzyk. Tak naprawdę to rzeczywistość i używanie produktu pokaże co nie działa. Stąd też przyrostowość, bo zrobienie nawet najprostszej wersji produktu, pozwala zbierać informację zwrotną od realnych użytkowników.

2. Rób krótkie Sprinty

W “Scrum Guidzie” możesz przeczytać o Sprintach miesięcznych, jednak my zachęcamy do robienia jak najkrótszych Sprintów, nawet tygodniowych. 

Spotykamy się z wieloma argumentami, że takie krótkie Sprinty są niemożliwe w danej organizacji, jednak według nas to pokazuje tylko niedoskonałości organizacji, które trzeba wyciągnąć i naprawić. Te niedoskonałości mogą być związane z technologią lub narzędziami, a uświadomienie sobie tego pozwoli zoptymalizować pracę. Oczywiście gęsta iteracja będzie brzmieć bardzo ambitnie i trzeba będzie się nauczyć nowego sposobu pracy, jednak wraz z nabieraniem wprawy będziemy widzieć coraz więcej korzyści płynących z takiego trybu pracy.

W długich Sprintach poniekąd tworzymy sobie iluzję pracy zwinnej i nie uzyskamy tu tej wartości, którą moglibyśmy uzyskać, pracując faktycznie w sposób zwinny. 

Można powiedzieć, że chęć lub też niechęć do krótkich Sprintów jest bardzo szybkim walidatorem na to, czy firma jest faktycznie gotowa, żeby rozpocząć transformację zwinną. 

Mamy rzecz jasna świadomość, że w danym momencie, w danej firmie czy w danym zespole, nie jesteśmy w stanie wdrożyć krótkich Sprintów, bo blokuje nas szereg ograniczeń. Jednak wtedy warto ustalić, co można zrobić, aby te ograniczenia zniknęły i kto się tym zajmie? Bez tego idea zwinności na poziomie organizacji zakładająca ciągłe doskonalenie, gdzieś się zgubi.

O argumentach za krótkimi Sprintami możesz też przeczytać w artykule Jacka “Krótkie Sprinty w Scrumie”.

3. Miej Cel Sprintu

Temat Celu Sprintu poruszaliśmy już wielokrotnie, a nawet nagraliśmy o nim osobny odcinek.

Naszym zdaniem Cel Sprintu pomaga nam przenieść wykorzystanie Scruma na wyższy poziom. Sprint jest tylko środkiem do celu, natomiast najważniejszy w tym wszystkim jest cel i jego sprawna realizacja. 

Jeśli będziemy traktować Sprint “jako pojemnik, do którego wrzucamy konkretne zadania”, to nasze podejście będzie zupełnie odmienne od tego, gdy uznamy Sprint “jako okres, w którym chcemy zrealizować konkretny cel”. Różnica wydaje się niewielka, jednak wiedząc, co chcemy osiągnąć nie mamy poczucia, że robimy to tylko dla odhaczania zadań.

Praca na celach kształtuje zupełnie inną kulturę działania, a zespół, który ma określone Cele Sprintu, będzie szukał możliwości ich osiągnięcia, np. poprzez wychodzenie ze swoich ról, wzajemne pomaganie sobie, pomyśleć o nowych rozwiązaniach lub może zdefiniować zakres pracy.

Ujmując to krótko: Cel Sprintu pomaga zespołowi reagować na bieżąco na niespodziewane sytuacje, zreorganizować swoją pracę pod to, żeby jednak zrealizować cel, dążyć do tego celu czy go wykonać.

4. Zastosowanie inspekcji i adaptacji co Sprint na poziomie produktu

Dobre Sprinty oznaczają jakiś skończony cel, jakąś skończoną pracę, po której zatrzymujemy się, żeby się zastanowić nad tym, co się nam udało osiągnąć, gdzie jesteśmy, jak zmieniły się realia, jak to, co zrobiliśmy, odbierają nasi odbiorcy docelowi lub interesariusze. Na bazie tych wszystkich nowych informacji oraz tego wszystkiego, co się udało dokonać do tej pory, zastanówmy się, jak się do tego zaadaptujemy. 

To może oznaczać kontynuację pracy według pierwotnie założonego planu, ale może też oznaczać drobne poprawki w dotychczas wykonanej pracy, a nawet mocną przebudowę wcześniejszego planu pracy. 

Mylnym założeniem jest, że w kolejnym Sprincie będziemy realizować niedokończone zadania. Może być zupełnie inaczej i to Product Owner podejmie decyzje, co robimy w kolejnym Sprincie.

Warto też zaprosić wszystkich Stakeholderów na Przegląd Sprintu, aby pokazać im, gdzie obecnie jesteśmy oraz jak najwcześniej zbierać informacje zwrotne, które mogą sprawić, że skorygujemy uprzednio obrany kurs.

W naszej pracy z różnymi firmami i zespołami widzimy, że pokazywanie nawet takich drobnych kroków, które mogą być często korygowane, buduje ważny kapitał: zaufanie interesariuszy do zespołu. Zespół również ma poczucie, że to, co robi, jest ważne, a jeśli coś idzie nie tak, to otrzymama szybko o tym informację oraz wsparcie w podejmowaniu ważnych decyzji.

5. Inspekcja i adaptacja co Sprint na poziomie procesu

Porada ta jest zachętą do regularnego odbywania Retrospektywy Sprintu na koniec Sprintu.

Tak jak inspekcja i adaptacja na poziomie produktu pokazuje nam co mamy i co robić dalej, tak Retrospektywa daje nam podobne korzyści, tylko z perspektywy tego, jak pracujemy. Nie skupiamy się tu na produkcie, a na procesie i zastanawiamy się, co możemy usprawnić lub co idzie świetnie i warto to kontynuować.

Dla nas Retrospektywa to absolutne serce wszelkich usprawnień. Jeśli wraz z zespołem mielibyście robić jedną rzecz, to róbcie Retro. 

Wielokrotnie widzieliśmy, że zespoły pomijały Retrospektywę, tłumacząc to tym, że zyskają 2h pracy na wykonywanie zadań z backlogu. Jednak jest to pułapka, która i może wygląda obiecująco, ale tylko krótkoterminowo. Oczywiście zyskujemy godzinę czy dwie, natomiast w dłuższym okresie nie widzieliśmy zespołu, który by się usprawniał, nie rezerwując sobie pewnej ilości czasu na to, żeby się zastanowić, co warto usprawnić. 

Więcej o retrospektywie Sprintu posłuchasz i przeczytasz w piątym odcinku podcastu: “Porządna Retrospektywa Sprintu”.

6. Inspekcja i adaptacja nie musi się odbywać tylko i wyłącznie na koniec Sprintu

Porządny Sprint oznacza to, że wszystkie te rzeczy możemy realizować również w środku Sprintu.

Jest to dobre wykorzystanie codziennego Scruma, na którym aktualizujemy nasze plany, synchronizujemy pracę, która została wykonana, odkrywamy jakieś trudności i wspólnie ustalamy całym zespołem, jak się adaptujemy i jak reorganizujemy nasze działania. Nie ma potrzeby czekać do końca Sprintu, jeśli widzimy, że coś ewidentnie nie działa i wymaga usprawnienia. 

Scrum wcale nie każe czekać do końca Sprintu, podobnie zresztą jest ze współpracą z klientem czy odbiorcą tworzonego produktu. Możemy wdrożyć nasze rozwiązanie również w środku Sprintu, a następnie zaprosić naszych użytkowników do przeglądnięcia tego, co wykonaliśmy. Możemy też blisko współpracować z Ownerem i interesariuszami, żeby odbierali naszą pracę na bieżąco w takim trybie ciągłym. Daje to możliwość np. na to, że zaadaptujemy się jeszcze w środku tego samego Sprintu. Natomiast na Przeglądzie Sprintu już w zasadzie dla czystej formalności prezentujemy sobie wykonaną pracę i robimy podsumowanie w celu aktualizacji dalszych planów. 

Mamy nadzieję, że nasze porady pomogą Wam w przeprowadzaniu Sprintów. Chętnie też poznamy Wasze wskazówki, jeśli o czymś nie wspomnieliśmy, a sprawdziło się to w Waszych zespołach.

Wydarzenia, które wspominamy w nagraniu:

• 24 października we Wrocławiu poprowadzimy warsztat Porządny Agile podczas konferencji Management 360.

Dodatkowe materiały

• Artykuł Jacka Krótkie Sprinty w Scrumie
• Cel Sprintu
• Porządna Retrospektywa Sprintu

Sprawdź nasz webinar o dzieleniu elementów Backlogu Produktu na mniejsze elementy.

Transkrypcja podcastu „Porządny Sprint”

Jacek: Jakiś czas temu zapytaliśmy Was o to, z jakimi mitami dotyczącymi Scruma i podejścia zwinnego spotykacie się na co dzień. Zapytanie to okazało się istną kopalnią pomysłów i inspiracji dla nas na kolejne odcinki – za co dziękujemy. I jednym z takich zgłoszeń, które dostaliśmy, kiedy zapytaliśmy o Scruma, było stwierdzenie, że Sprint to taki mini-waterfall. I bazując na tym stwierdzeniu, na tym popularnym micie, który bardzo często można usłyszeć, zdecydowaliśmy się, że nagramy dzisiaj odcinek, który zatytułowaliśmy „Porządny Sprint” i chcielibyśmy opowiedzieć Ci o tym, jak definiujemy Sprint i jak naszym zdaniem zrobić go w sposób poprawny.

Kuba: I definiując Sprint, zaczniemy od tego, co mówi o tym „Przewodnik po Scrumie” – Sprint jest zdefiniowany jako: „Ograniczenie czasowe, okres, w którym powstaje produkt nie dłuższy niż miesiąc, i w ramach tego miesiąca Zespół Scrumowy wykonuje prace, a na koniec uzyskuje Przyrost”. I to jest taka definicja czysto scrumowa, z takich definicyjnych rzeczy jeszcze warto dołożyć taki bardzo ważny aspekt tego, że Scrum mówi o tym, że Sprint jest takim sposobem na limitowanie ryzyka, czyli podejmujemy jakąś pracę, dzielimy ją na krótsze okresy, na jakieś takie… wycinki czasowe, wewnątrz których próbujemy zrealizować pewne działanie. I dzięki temu podejściu małych kroków albo mniejszych kroków, sprawdzamy, jak nam idzie, sprawdzamy, czy pojawiają się jakieś ryzyka technologiczne, ryzyka procesowe czy też ryzyka w naszym produkcie – i dzięki temu możemy na to zareagować, możemy tym zarządzić, możemy mieć pewien monitoring ryzyka, tak jak w klasycznym zarządzaniu projektu monitoruje się te ryzyka, tak Scrum jest tutaj też sposobem na monitorowanie ryzyka, chociaż zabiera się za to w nieco odmienny sposób.

Jacek: I ja myślę, że ten nieco odmienny sposób ma tutaj kluczowe znaczenie, bo tak naprawdę podchodzimy do tego ryzyka w sposób empiryczny, czyli zamiast odpowiadać sobie, jakie są ryzyka, jaki mamy plan mitygacji, jaki wpływ itd. itd. No to tutaj de facto dostajemy namacalny dowód na to, jak zaawansowani jesteśmy albo jak dużo problemów jest przed nami, więc ten akcent ryzyka, z mojej perspektywy, jeśli chodzi o Sprinty, jest o tyle istotny, że formuła, w jakiej Sprint oczekuje od nas, że będziemy mieć coś na koniec, w pewnym sensie zmusza nas do tego, żeby te ryzyka były jak najbardziej widoczne i transparentne dla wszystkich zainteresowanych inicjatywą, projektem czy produktem, który rozwijamy.

Kuba: I jest jednocześnie takie – jak mówisz o empiryzmie – takie najbardziej trudne do niezrozumienia, czy Sprint nam się udał czy się nie udał, no, założyliśmy sobie pewien Cel Sprintu, osiągnęliśmy go lub nie, założyliśmy sobie, że coś wykonamy – udało się lub się nie udało i w wielu projektach jest dużo zabawy w takie złudzenia – zwłaszcza w środku projektu – nadrobimy, może się odblokuje, może nam wreszcie dostarczą, może ten zakupiony sprzęt jednak jak już dojdzie, to jakoś tam magicznie uratujemy pierwotnie przewidziany termin. No, Scrum tutaj podchodzi dosyć brutalnie – jeśli w pierwszym Sprincie ci się nie udało, to znaczy, że masz kłopot, a w klasycznym projekcie to często by oznaczało, no, mamy jakiś issues albo jest pewne ryzyko, które się trochę materializuje albo jego procent prawdopodobieństwa rośnie – Scrum mówi: „No, nie jesteśmy w stanie pokazać działającego produktu, pomimo tego, że się napracowaliśmy przez ostatni okres, nie mamy nic”.

Jacek: I takie smutne Przeglądy Sprintu, na których zespół nie jest w stanie nic pokazać – chociaż wykonali niesamowitą ilość pracy, to z mojej perspektywy jest takim niesamowitym bodźcem i uderzeniem – szczególności dla osób w managemencie – no bo te wszystkie papiery, te wszystkie tam raportowania, o których mówiłeś, to właściwie można schować do szuflady, no bo tutaj namacalnie widzimy to, że zespół spędził np. dwa tygodnie pracując i nie są w stanie nic pokazać, nie widać produktu, nie możemy nic na jego temat powiedzieć. No, moim zdaniem to daje bardzo mocno do myślenia, czy my w ogóle jesteśmy w stanie dostarczyć ten produkt albo jakie przeszkody na naszej drodze musimy usunąć, żebyśmy byli w stanie ten produkt dostarczać w sposób płynny.

Kuba: Drugą część tego odcinka chcemy skupić na tym, żeby już nie rozmawiać o definicjach albo jakichś historiach porównawczych między Scrumem a podejściem klasycznym, tylko po prostu opowiemy o tym, jak definiujemy, naszym zdaniem, porządny Sprint, i ta definicja to będzie sześć porad, konkretnych sugestii, jak wykonywać Sprint, jak go organizować, jak się do niego zabierać, co może być ważne dla Ciebie, jeżeli jesteś z perspektywy Agile Coacha, Scrum Mastera czy członka zespołu. Zobacz, która z tych porad może pasować, która z tych porad może zmienić to, jak funkcjonuje Sprint w Twoim Zespole Scrumowym.

Jacek: Pierwsza porada brzmi: „Miej Przyrost na koniec każdego Sprintu”. Jeśli chodzi o mnie, to to była pierwsza rzecz, która przyszła mi do głowy, jeżeli miałbym powiedzieć, po czym poznać udany Sprint. Jak zaraz zobaczycie, tych wymiarów porządności może być bardzo wiele, ale z mojej perspektywy takim najprostszym do sprawdzenia i też takim najbardziej dającym „czucie” czy zespół faktycznie w sensowny sposób wykorzystuje Scruma jako narzędzie do rozwiązywania problemów jest to, czy na koniec Sprintu mamy jakiś konkretny, namacalny Przyrost naszego produktu. Czyli przykładowo, jeżeli budujemy jakąś aplikację cyfrową, no to mówiąc o Przyroście Produktu, spodziewałbym się jakiejś namacalnej formy tej aplikacji, żebym ja mógł ją zobaczyć, wyświetlić, kliknąć. Chciałbym zobaczyć jakąś superuproszczoną pierwszą funkcjonalność – coś takiego super, obdartego z wszelkiego rodzaju „wodotrysków”, ale pokazujące jednocześnie, że pierwszy krok zbliżający nas do stworzenia produktu, którego wersja nas satysfakcjonuje, został zrobiony. Absolutnie nie przemawia do mnie argument w stylu: „Mamy napisaną część backendową”, czyli programiści wykonali pracę. Nie przemawia do mnie, że ktoś przygotował jakieś tam makiety. Nie przemawia do mnie, że zrobiliśmy świetną analizę. To wszystko, to są tylko elementy składowe. Bardziej mnie interesuje, czy te wszystkie elementy składowe produktu tworzone przez różne osoby, czy my jesteśmy w stanie to, raz, spiąć w całość, a dwa, czy w ogóle zastanowiliśmy się, co w tym krótkim okresie czasu Sprintu jesteśmy w stanie dostarczyć. I to jest dla mnie takie absolutne clue pracy w Sprintach, a niestety obserwuję, że jest to nadal dosyć trudne do osiągnięcia, w szczególności w firmach, które dopiero zaczynają przygodę z… no, konkretnie, tutaj z frameworkiem Scrum.

Kuba: I warto się zastanowić, po co w ogóle mieć przyrost co Sprint. Tu znowu wracamy do tematu ryzyk, bo to jest bardzo uniwersalny argument, akurat w kwestii Przyrostów, no, wymieniłeś chociażby np. backend. Backend niepołączony z frontendem, nietworzący całego produktu może nadal zawierać w sobie ryzyka – ryzyko integracji, ryzyko jakichś niedociągnięć technologicznych, może jakieś ryzyko złego zrozumienia wymagań, które, póki nie jesteśmy w stanie całościowo spojrzeć na produkt, to nie wykryjemy. Ryzyka zwłaszcza tematów typu: analiza, gotowy dokument albo jakaś tam przyszykowana makieta – to wiele produktów, póki nie użyjemy, póki ich klient docelowy nie spróbuje użyć w środowisku docelowym, najzwyczajniej w świecie jest tylko wyłącznie pewnym przypuszczaniem albo, brutalizując sprawę, zakładaniem czy obstawianiem, że wszystko będzie dobrze, że wszystko przewidzieliśmy, wszystko rozpoznawaliśmy, wystarczająco dobrze główkowaliśmy przed rozpoczęciem pracy. Nikomu nic nie ujmując, ale mierzymy się tutaj ze złożoną sytuacją. Możemy być bardzo mądrzy, ale nadal ta rzeczywistość, te realia takiego świata złożonego po prostu przywołają szereg rzeczy, który dopiero wyjdzie, gdy zaczniemy produktu używać. Stąd przyrostowość – zróbmy prostą wersję jak najwcześniej, zróbmy ją całą, żeby jak najwcześniej też zacząć zbierać ten feedback, tę informację zwrotną z realnego świata, od realnych użytkowników, od realnych klientów.

Jacek: Wiele razy spotkałem się z taką obietnicą, że podejście zwinne pozwala uzyskać więcej wartości w krótkim czasie i kiedy myślę sobie o wartości, to właśnie pierwsze moje skojarzenie jest takie, że powinna się pojawić jakaś namacalna rzecz na koniec Sprintu i to jest właśnie ten Przyrost, więc też tak patrząc, jakby trochę rozróżniając Scruma od podejścia zwinnego, no to jeżeli chcemy być zwinni, no to warto, żeby ten Przyrost Produktu w Scrumie się po prostu uwidocznił na koniec Sprintu.

Kuba: I kolejną poradą, jaka przychodzi nam do głowy, pierwsza, która mi przyszła do głowy, tutaj nawiązując, Jacek, do twojej myśli z początku tej części. Mnie przychodzi do głowy taka porada: „Rób krótkie Sprinty”. Szczerze mówiąc, śmieję się dosyć często i głośno, jak czytam w „Scrum Guidzie” o Sprintach miesięcznych – absolutnie współczuję osobom, które w takich miesięcznych Sprintach muszą pracować, bo dla mnie to jest strasznie długo. Ja sam osobiście zachęcam do najkrótszych Sprintów, jak się tylko da. I mam na myśli najlepiej tygodniowe Sprinty, a ewentualnie porozmawiajmy o dwutygodniowych. I w wielu realiach, zwłaszcza w firmach o jakichś tradycyjnych procesach, strukturach, przyzwyczajeniach do długich projektów, to taki dwutygodniowy czy tygodniowy Sprint brzmi jak po prostu pstryknięcie palcami i już mamy koniec Sprintu, co jest nierealne, niemożliwe, „u nas się tak szybko nie pracuje”, siedemnaście powodów, dla których praca w zespole będzie absolutnie nie do wykonania, zblokowana, tylko dokładnie ja to odwracam tę sytuację, te wszystkie powody, dla których nie da się pracować tak szybko w tak krótkich Sprintach, to są powody, które prawdopodobnie są – nazwijmy do dyplomatycznie – niedoskonałościami organizacji, za które się trzeba zabrać, które trzeba ujawnić, pokazać, jaki jest kłopot z tym, że takie intensywne tempo, takie krótkie cykle pracy są po prostu niemożliwe. I to często będzie temat technologii, to często będzie temat narzędzi, ale to też mogą być kompetencje w zespole. Nagle się okaże, że nie jesteśmy w stanie tak intensywnie jako zespół pracować, natomiast ja tu sobie zakładam w tej rekomendacji, że krótkie Sprinty czy gęsta iteracja oznacza po prostu bardzo ambitne podejście, którego na początku się trzeba trochę nauczyć, trochę nas będzie uwierało, ale wraz z tym, jak nabieramy wprawy oraz wraz z tym, jak poprawiamy nasze środowisko czy nasze otoczenie, czy też narzędziówkę, no po prostu to wszystko sprawia, że nasza praca w dłuższym okresie czasu jest coraz lepsza, coraz łatwiejsza, coraz lepiej dopasowana do tej obietnicy, jak to, Jacek, ujmujesz, zwinnego podejścia, czyli wcześnie wdrażamy wartość i często wdrażamy jej kolejne kawałki.

Jacek: Tak, no i tak jak przyrost z tego pierwszego punktu, z mojej perspektywy, zapewnia wartość, tak żeby dostać tę wartość wcześniej, no to miejmy krótsze iteracje. Swoją fascynację do krótkich Sprintów opisałem na blogu bardzo dawno temu – myślę, że parę lat – podlinkujemy ten artykuł w odcinku, natomiast takim dalej papierkiem lakmusowym, kiedy wchodzę do organizacji jako osoba z zewnątrz, jako konsultant, żeby pomóc z podejściem zwinnym, jest reakcja zespołu i managementu na moją propozycję: „To może zróbmy tygodniowe Sprinty”. Bardzo szybko, tak jak powiedziałeś, zaczynają się pojawiać problemy, no i teraz tak, z mojej perspektywy, to bardzo dobrze, że te problemy się pojawiają. To są pytania w stylu: „Jak podzielić duże wymagania na małe części?”. To są pytania w stylu: „A co robi w takim razie tester przez Sprint?”. To są pytania w stylu: „W sumie to nie mamy tego jeszcze dobrze opisanego, więc jak mamy zacząć?”. I to są świetne pytania, z mojej perspektywy, problemy, które musimy rozwiązać, no bo tak czy inaczej, bez rozwiązania tych problemów, jeżeli stworzymy sobie jakąś tam iluzję pracy zwinnej w jakichś superwydłużonych Sprintach, no to i tak nie uzyskamy tej wartości, którą moglibyśmy uzyskać, gdybyśmy faktycznie pracowali w zwinny sposób. Więc tak parafrazując, dla mnie krótkie Sprinty są takim bardzo szybkim walidatorem też na to, czy firma jest faktycznie gotowa na to, żeby wejść na tą drogę zmian. Nie? Ten entuzjazm bądź strach, który widzę w tych rozmowach, pokazuje mi, gdzie jesteśmy w ogóle, jeśli chodzi o ten faktyczny apetyt na zwinność. Czy faktycznie chcemy się zmieniać? Czy po prostu chcemy fajnie na konferencji powiedzieć, że jesteśmy zwinną firmą? No, ale, znów, taka pozorna zwinność, no to umówmy się, nie daje żadnej wartości.

Kuba: Może oczywiście się okazać, że w danym momencie, w danych realiach, w danej firmie, w danym zespole tygodniowego Sprintu niestety nie damy rady, bo nas ten szereg ograniczeń gdzieś tam blokuje, ale dokładnie tak to ujmijmy, czyli są ograniczenia, które powodują, że nie możemy przyspieszyć i zadajmy sobie pytanie: „Kto co z tym robi, żeby te ograniczenia zniknęły?”. No bo jeśli np. proces wdrożeniowy albo brak środowisk powoduje, że nasze Sprinty są długie i rzadko wdrażamy i nikt z tym nic nie zrobi, to absolutnie tak już zostanie. I za rok, i za dwa lata i za pięć – też tacy będziemy. No, to nie będzie zwinność rozumiana też na poziomie organizacji, gdzie mówimy tutaj o ciągłym doskonaleniu procesu. Jeśli proces dobrnął do swoich granic i sobie elegancko się w nich rozgościł i nie chce ruszyć o krok dalej, no to też gdzieś tam się zwinność zgubiła, nawet jeśli przestrzegamy mechaniki scrumowej, no to nie zmieniamy, nie udoskonalamy się jako organizacja czy jako zespoły.

Jacek: Trzecią poradę, którą mamy dla Ciebie, związaną z porządnym realizowaniem Sprintu, jest porada brzmiąca: „Miej Cel Sprintu”. O Celu Sprintu, mamy takie poczucie z Kubą, że mówiliśmy już bardzo dużo w poprzednich odcinkach – wspominaliśmy a oprócz tego nagraliśmy dedykowany odcinek, siódmy, który podlinkujemy w notatkach, natomiast cały czas mamy poczucie, że ten Cel Sprintu to jest coś, o czym warto wspominać i moim zdaniem to jest coś, co pomaga nam przenieść wykorzystanie Scruma na wyższy poziom. Czyli moja zachęta dla Ciebie to jest zmiana optyki z: „Sprint to jest pojemnik, do którego wrzucam konkretne zadania do realizacji” na myślenie: „Sprint to jest okres, w którym chcemy zrealizować konkretny cel”. Różnica wydaje się niewielka, natomiast na bazie moich doświadczeń, kompletnie zmienia sposób patrzenia na pracę, na to, jak ta praca może się zmieniać w trakcie w Sprincie, no i też automatycznie uruchamia bardzo fajne aktywności w zespole. Przede wszystkim są to aktywności, powiedziałbym, bazujące na częstej komunikacji i sprawdzaniu, gdzie tak naprawdę jesteśmy, ale cały czas tak naprawdę jakby w tym naszym takim spojrzeniu, gdzie jest Cel Sprintu, gdzie my jesteśmy, co jeszcze powinniśmy zrobić, żeby ten Cel Sprintu zrealizować. I to kompletnie spycha tą perspektywę – przerysuję teraz – „dziubania tasków” na inny plan. To jest tylko środek do celu, natomiast najważniejszy w tym wszystkim jest cel i jego sprawna realizacja.

Kuba: I ten Cel Sprintu nawiązuje do tego, co było taką naszą inspiracją pierwszą, czyli ten wątek, że Sprint to jest mini-waterfall, no, mini-waterfall się w takim ujęciu raczej kojarzy właśnie z poszczególnymi specjalistami wykonującymi swoje specyficzne czynności, które dopiero razem magicznie złożą się w całość. A zespół, który realizuje cele czy pracuje na celach, no, po prostu od początku rozpoczęcia pracy do końca rozpoczęcia pracy w ramach Sprintu, dąży do tego, żeby ten cel zrealizować, co automatycznie zachęca do tego, żeby wychodzić ze swoich specyficznych ról, jakichś specjalizacji eksperckich, żeby sobie wzajemnie pomagać, żeby też praktycznie codziennie szukać okazji do tego, żeby może zredefiniować zakres pracy, przemyśleć nowe rozwiązania, wpaść na jakieś nowe rozwiązania. No i ja czasami słyszę argument: „No ale po co nam cel, my wiemy, co robić, nasze taski są takie opisane, wszystko wiadomo”. Ja mam tu wrażenie, że tu jest problem – w niektórych zespołach – jajka i kury, że nie pracujemy na celach, więc nawet nie umiemy sobie wyobrazić, jakby to mogło być. A zwłaszcza jeśli do zespołu trafia już z góry zdefiniowany zakres, który tak jest łatwy do podzielenia na poszczególne osoby, no to zespół nie rozwiązuje problemu, zespół nie jest w stanie dążyć do jakiegoś celu lub musi nieźle się nagłówkować, żeby w ogóle ten cel sobie wstecznie odtworzyć. I czasami właśnie ten problem jest jedną z przyczyn takich źródłowych. Ale trochę odbiegamy od zalecenia co do Sprintu. No, zdecydowanie ja też się mocno pod tym podpisuję. Cel Sprintu tutaj robi różnicę. Cel Sprintu jest czymś, co integruje. Cel Sprintu jest też czymś, co pomaga zespołowi zareagować w trakcie pracy, zreorganizować swoją robotę pod to, żeby jednak zrealizować cel, dążyć do tego celu czy go wykonać. Następnym punktem, który zarekomendujemy, to jest: „Zastosowanie inspekcji i adaptacji co Sprint na poziomie produktu”. Dobre Sprinty oznaczają jakąś skończoną myśl czy skończony cel, skończoną pracę, po której ponownie zatrzymujemy się, jak co Sprint, zatrzymujemy się, żeby się zastanowić, co się nam udało osiągnąć, gdzie jesteśmy, jak zmieniły się realia, co o tym, co do tej pory wykonaliśmy, sądzą interesariusze, jak to odbierają nasi odbiorcy docelowi – czy to są jacyś użytkownicy czy co to są jacyś klienci. I na bazie tych wszystkich nowych informacji oraz tego wszystkiego, co się udało dokonać do tej pory, zastanówmy się, jak się zaadaptujemy. To może oznaczać kontynuację pracy według pierwotnie założonego planu, ale często to może oznaczać drobne sugestie co do poprawki tego, co zostało do tej pory zrobione, a czasami będzie oznaczać, no, sporą przebudowę planów. Być może zmiany w Product Backlogu, być może jakieś nowe elementy, być może porzucenie jakiegoś całego wątku w naszym produkcie. Wiele Zespołów Scrumowych pracuje w iteracjach, pracuje w jakichś cyklach czasowych, ale zapomina o tym aspekcie, że wcale nie jest oczywiste to, co będziemy realizować w kolejnym Sprincie. Na pewno nie będziemy dokańczać z automatu wszystko to, co rozpoczęliśmy w poprzednim. Bo to jest uprawnienie właściciela produktu, żeby podjąć decyzję na bazie tych wszystkich informacji, o których wspomniałem.

Jacek: No i jak sięgam pamięcią, to sam wspominam moment, w którym pracując jako Scrum Master z właścicielem produktu w Zespole Scrumowym, spotkałem się z taką sytuacją, gdzie zespół tak „korytarzowo” umówił się, że „Aaa, przecież to, że nie skończyliśmy tego tematu to nic, przecież wiadomo, że na Przeglądzie Sprintu Product Owner nam to klepnie i będziemy robić to dalej”. No i pamiętam zaskoczone twarze na Przeglądzie Sprintu, gdy Product Owner powiedział: „Dobra, to te rzeczy są zrobione, to je biorę, natomiast ten temat, który jest rozgrzebany, no to ja powiem wam tak: nie będziemy go kontynuować, bo rzeczywistość jest taka, że chciałbym, żebyśmy się zajęli tym i tym, i tym, bo ma to wpływ na to i tamto” – i to wynikało z jakichś tam ograniczeń marketingowo-biznesowych, tak więc to taki tylko przykład na to, że to założenie, że ta praca może się przekładać ze Spritu na Sprint i w nieskończoność, no, może być błędne, w szczególności, jeśli tą inspekcję i adaptację produktu potraktujemy w poważny sposób. Druga myśl, która mi przychodzi do głowy jest taka, że czasem się spotykam z takim podejściem: „Nie zapraszajmy stake holderów, nie zapraszajmy interesariuszy na ten przegląd, w szczególności kiedy to jest jeden z pierwszych, bo nie mamy co pokazać”. No, moim zdaniem, to jest taka pułapka myślenia. Moim zdaniem – i to rekomenduję – jest zaproszenie tych wszystkich stake holderów, pokazanie im, gdzie jesteśmy, bo może być tak, że będziemy w stanie pokazać bardzo mało – to wtedy porozmawiajmy dlaczego nie jest to tak duże, jakbyśmy wszyscy się spodziewali. Albo z drugiej strony na bardzo wczesnym etapie jesteśmy w stanie dostać informacje zwrotne, które pomogą nam skorygować kurs, w który podążamy. Tak więc, pomimo takiego być może poczucia czasem wstydu, takiego poczucia, że nie mamy, co pokazać, no to ta regularna i wczesna inspekcja, adaptacja – na poziomie produktu, uważam, no, za jedną z kluczowych rzeczy, o którą warto dbać w trakcie Sprintu.

Kuba: I takie moje w miarę świeże przemyślenie na bazie zespołu, z którym współpracuję obecnie, to to, że nawet te drobne kroki, ale często pokazywane, często też korygowane, budują naprawdę ważny kapitał, często zapominany, czyli zaufanie. I tutaj zaufanie do zespołu ze strony interesariuszy, taki spokój, co do tego, że jeśli pójdą w złą stronę, to mogą być szybko skorygowani, myślenie perspektywą interesariuszy, gdzie oni to zespół, ale też ta perspektywa zespołu, że robimy coś, co jest ważne, interesariusze tego chcą, słuchają nas, oczekują na kolejne efekty, umieją powiedzieć, co jest ważne, co im się podoba, a ewentualnie co im się nie podoba – i to są wszystko takie aspekty, które powodują, że gdy przyjdą jakieś potrzebne kroki, np. wyrozumiałość, że nam poszło coś nie tak albo wsparcie, żeby coś przyspieszyć, albo konieczność jakiejś ważnej szybkiej decyzji – to to wszystko świetnie pasuje, jeśli mamy ten fundament już bardzo wczesnej inspekcji, adaptacji, bardzo wczesnego kontaktu. No i też bardzo bliskiej współpracy, czy takiej bardzo bliskiej relacji pomiędzy zespołem, Product Ownerem i interesariuszami.

Jacek: Piątą poradą, wspierającą porządny Sprint, jest porada brzmiąca: „Inspekcja i adaptacja co Sprint na poziomie procesu”. I to być może enigmatycznie trochę brzmiące zdanie, tak naprawdę wyraża taką myśl, że chciałbym zachęcić Cię do regularnego odbywania Retrospektywy Sprintu na koniec Sprintu. Tak jak przed chwilą, Kuba, opowiadałeś – z jednej strony mamy inspekcję i adaptację na poziomie produktu, gdzie możemy, raz, zobaczyć, co mamy i dwa – podjąć decyzję, co zrobić dalej, no to Retrospektywa zabiera nas na tą samą podróż, tylko z perspektywy tego, jak pracujemy, czyli nie mówimy o produkcie, mówimy bardziej o procesie, no i zastanawiamy się, co możemy usprawnić, co możemy zrobić inaczej, co możemy zrobić lepiej. Myślę, że to wielokrotnie padło – bądź w podcaście, bądź w jakichś naszych artykułach, które publikujemy – że jeżeli miałbyś robić jedną rzecz, no to rób Retrospektywę, ponieważ jest to absolutne serce wszelkich usprawnień, no i pominięcie Retro z powodu „Nie mamy czasu, zobacz, ile jest rzeczy w Backlogu, czemu dwie godziny spędzamy na tym wydarzeniu”. No, uważam, że to jest absolutna pułapka, która krótkoterminowo wygląda obiecująco – zyskamy godzinę bądź dwie, natomiast w dłuższym okresie czasu nie widziałem zespołu, który by się usprawniał, nie rezerwując sobie pewnej ilości czasu na to, żeby się zastanowić: „Dobra, to co tak naprawdę możemy usprawnić?”. Jeśli chciałbyś bądź chciałabyś pogłębić temat tego, czym jest dobra Retrospektywa Sprintu, jak ją przeprowadzić, jak ją zrobić w sposób efektywny, to odsyłam Cię do piątego odcinka naszego podcastu. Link do odcinka włączymy do notatek.

Kuba: I szósta rada, taka bonusowa albo poszerzająca dwie poprzednie, to jest to, że: „Inspekcja i adaptacja nie musi się odbywać tylko i wyłącznie na koniec Sprintu” – taki fajny, porządny, dobry, wysublimowany Sprint oznacza to, że wszystkie te rzeczy możemy realizować również w środku Sprintu. Jest to dobre wykorzystanie codziennego Scruma, na którym aktualizujemy nasze plany, synchronizujemy pracę, która została wykonana, odkrywamy jakieś trudności i wspólnie ustalamy całym zespołem, jak się adaptujemy, jak replanujemy nasze działania, jak reorganizujemy to, jak funkcjonujemy. I dokładnie ten sam sposób podejścia może być wzięty do usprawniania procesu, jeśli mamy jakieś ewidentnie kłopoty albo jakąś wyraźną niedoskonałość – naprawdę nie ma żadnego problemu, żeby nie zrobić tego na szybko, w środku Sprintu, a nie czekać np. tydzień albo półtora, no bo „O usprawnieniach rozmawiamy tylko na Retrospektywie”. To zdecydowanie jest przesadzona perspektywa. Jeśli mamy jakąś drobną rozmowę, możemy ją wykonać jak najbardziej w środku Sprintu. Jeśli mamy jakiś kryzys, to również zatrzymajmy się i go rozwiążmy, a nie męczmy się przez tydzień, bo Scrum każe nam czekać do końca Sprintu. Scrum tego zdecydowanie nie każe. I dokładnie ta sama myśl jest również ze współpracą z klientem, z odbiorcą. Możemy wdrożyć nasze rozwiązanie również w środku Sprintu, możemy zaprosić naszych użytkowników do przeglądnięcia tego, co wykonaliśmy, możemy blisko współpracować z Ownerem i interesariuszami, żeby odbierali naszą pracę na bieżąco – w takim trybie, bym powiedział, ciągłym – co nam daje możliwość tego, że np. zaadaptujemy się jeszcze w środku tego samego Sprintu skorygujemy nasze działanie, więc na Przeglądzie Sprintu już w zasadzie dla czystej formalności odbieramy tą pracę czy wzajemnie ją sobie w jakiś sposób prezentujemy i podsumowujemy – i na tej bazie aktualizujemy dalsze plany. No bo już rozwiązanie jest na tyle dobre, że nie ma tam jakichś ryzyk hardkorowych, jakichś komentarzy, które przekreślają cały nasz wysiłek. Co w skrócie oznacza: korzystajmy z tego, że w ramach Sprintu blisko ze sobą współpracujmy i nie traktujemy zbyt święcie tych ram, że jest początek Sprintu, koniec Sprintu, a w środku Sprintu to my jesteśmy zamknięci w jakimś pokoju i realizujemy pracę zgodnie z tym, jak zaplanowaliśmy sobie na Planowaniu Sprintu. To zdecydowanie jest przegięcie. W żadnym punkcie Scrum nie zakłada takiego podejścia, jak teraz w pewien sposób przerysowałem, ale przerysowałem niestety na bazie obserwacji kilku zespołów. To tyle, jeśli chodzi o merytoryczną zawartość tego odcinka. Na koniec chcielibyśmy przypomnieć nasze zaproszenie na warsztat, który się odbędzie we Wrocławiu 24. października na konferencji „Management 360”. Razem z Jackiem zrealizujemy tam warsztat, który nazwaliśmy „Porządny Agile” i chcemy zabrać się za temat zwinności, właśnie dokładnie tak, jak w tytule. Możemy też od razu już ujawnić, że też w najbliższym czasie będziemy szykować wersję tego warsztatu taką otwartą, do którego każdy z nas, jeśli nie po drodze Wam do Wrocławia, będzie mógł się zapisać, będzie mógł wziąć udział i przejść z nami przez podróż przez porządną zwinność czy porządne podejście Agile.