#020 – 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.

Sześć rad dotyczących porządnego Sprintu, o których posłuchasz w odcinku:

  • Miej Przyrost na koniec każdego Sprintu.
  • Rób krótkie Sprinty.
  • Miej Cel Sprintu.
  • Zastosuj inspekcję i adaptację co Sprint na poziomie produktu.
  • Przeprowadzaj inspekcję i adaptację co Sprint na poziomie procesu.
  • Inspekcja i adaptacja nie muszą odbywać się wyłącznie na koniec Sprintu.

Wydarzenia, które wspominamy w nagraniu:

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

Dodatkowe materiały, które wspominamy w nagraniu:

Daj nam znać co sądzisz o tym odcinku

Transkrypcja odcinka

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.

J: 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.

K: 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”.

J: 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.

K: 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.

J: 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.

K: 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.

J: 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.

K: 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.

J: 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.

K: 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.

J: 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.

K: 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.

J: 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.

K: 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.

J: 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.

K: 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.

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

K: Dzięki, Jacek.

J: I do usłyszenia…

K i J: …wkrótce!


2 Replies to “#020 – Porządny Sprint”

  1. Mochał Lipek

    Super odcinek 🙂
    W mojej pracy mamy duże problemy z celem. Z reguły celem jest kilka storiesów ze sprintu. Rzadko kiedy jest to jedna konkretna rzecz jak jakiś nowy feature, czy mówiąc inaczej widoczny przyrost w aplikacji.
    Możliwe, że wynika to z tego, że zespół w którym pracuje zajmuje się pięcioma różnymi aplikacjami, które są w fazie utrzymania i najczęściej historyjki w sprincie dotyczą drobnych improvementów w różnych aplikacjach i różnych niezależnych procesach.
    Szczerze mówiąc, to nie mam pomysłu jak wyeliminować wielocel ze sprintów. Czasami się zastanawiam czy Scrum tu pasuje i czy nie lepszy były Kanban.

  2. Adam

    Super podcasty!
    U mnie akurat jest tak, że cel sprintu pojawia się już na koniec planowania jako próba podsumowania wszystkich story wrzuconych do backlogu, a i tak często to co finalnie zostało dostarczone nie pokrywa się z tym co było zaplanowane (ach, te must have z produkcji, które przychodzą dwa-trzy dni po rozpoczęciu sprintu).

    Mam też pytanie:
    jak zapatrujecie się na certyfikację Scrum Mastera? robienie i zdawanie „PSM I” i dalej (certyfikaty ze scrum.org) uważacie za niezbędne, podobnie jak np. z ISTQB w pewnym momencie kariery przestają się liczyć, bo doświadczenie jest ważniejsze czy jest to najzwyklejsze marnowanie pieniędzy i niezależnie od doświadczenia nie warto?

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *