Zarządzający na Przeglądzie Sprintu

Co możesz zrobić, żeby zainteresować zarządzających Przeglądem Sprintu? Sprawdź listę naszych pomysłów. Mamy dla Ciebie garść wskazówek, żeby podejść do tematu porządnie.

Kiedy i dlaczego warto zaprosić osoby z zarządu na Przegląd Sprintu? Jak zachęcić top management do udziału w tym wydarzeniu scrumowym i jakie mamy dla Ciebie wskazówki związane z organizacją takiego spotkania.

Do rozmowy na ten temat zainspirowali nas uczestnicy warsztatów Prawdziwe Przypadki Scrumowe. Wątek obecności zarządu na Sprint Review wywołał ciekawą dyskusję z masą różnych przemyśleń i wniosków. Postanowiliśmy rozwinąć go tutaj, gdyż mamy poczucie, że więcej z Was może chcieć skorzystać z naszych doświadczeń i wskazówek w tym obszarze.

Mówiąc o zarządzających mamy na myśli szeroką grupę osób, która w zależności od struktury organizacji może przybierać różną formę. Czasem jest to faktyczny zarząd firmy, kiedy indziej są to dyrektorzy zarządzający, a innym razem to tzw. leadership team lub top management. Bez względu na nazewnictwo, chodzi nam o osoby będące na najwyższych szczeblach w organizacji.

Osoby na tych stanowiskach zwykle mają dużo obowiązków i spotkań, dlatego, aby zechcieli pojawić się na Przeglądzie Sprintu, warto ich do tego odpowiednio zachęcić i zainteresować wydarzeniem. 

Jak zorganizować Sprint Review, który zainteresuje zarządzających?

1. Wybierz właściwy moment na zaproszenie

Kontekst tego, co aktualnie robimy, ma ogromne znaczenie, jeśli chodzi o zapraszanie zarządu na Przegląd Sprintu. Nie zawsze jest sens to robić. Przykładowo, jeżeli dopiero zaczynacie pracę i nie macie jeszcze nic konkretnego do pokazania, to osoba z zarządu nie będzie miała się do czego odnieść. 

Dlatego osoby z zarządu warto zapraszać na Sprint Review, gdy faktycznie mamy już coś wyprodukowane i można o tym podyskutować oraz otrzymać jakąś wartościową informację zwrotną. 

Z drugiej strony, nie ulegajcie też pokusie, aby zarządzających zaprosić, dopiero gdy cały produkt jest gotowy. Lepiej otrzymać feedback we wcześniejszych fazach tworzenia produktu, a nie na sam koniec.

2. Zadbaj o to, żeby zarządzający wiedzieli, czym jest Przegląd Sprintu

Osoba, która na co dzień nie ma do czynienia z podejściem zwinnym, zwłaszcza jeśli dopiero wdrażacie je do organizacji, ma prawo nie wiedzieć, czego powinna się spodziewać, czego będzie się od niej oczekiwało i po co w ogóle ma się pojawić na danym spotkaniu. 

Ponadto Przegląd Sprintu ma pewną specyficzną formułę, nietypową dla takich klasycznych spotkań zarządczych. Dlatego, aby osoby z zarządu mogły czuć się komfortowo, a także nie utrudniały przebiegu przeglądu przez swoje nawyki z innego typu spotkań, powinniśmy im przekazać króciutką instrukcję z praktycznymi wskazówkami. Można w niej zawrzeć nie tylko informację o tym, czym jest Przegląd Sprintu, ale również czego od nich oczekujemy, jakie interakcje są wskazane i czego lepiej, aby nie robili.

3. Przygotuj ich, na to, co zobaczą na Przeglądzie Sprintu

Ponieważ Przeglądy Sprintu odbywają się w trakcie tworzenia produktu, to często prezentowany na nich wynik Waszej pracy to niedokończony jeszcze produktu, bez wszystkich funkcjonalności. Osoby z zewnątrz powinny mieć tego świadomość, że będą oglądać pewien etap jego rozwoju, produkt niedoskonały, niepełny. Ponadto czasie prezentacji może też pojawić się jakiś niespodziewany błąd, może się okazać, że o czymś zapomnieliśmy.

Dlatego, aby otrzymać właściwą informację zwrotną i uniknąć sytuacji, że zarząd zbuduje sobie błędne wrażenie o słabej jakości naszej pracy, miejmy odwagę otwarcie z tymi osobami porozmawiać i przygotować ich na to, co zobaczą.

4. Dopasuj prezentację do odbiorcy

Porada ta jest oczywiście zawsze prawdziwa, bez względu na interesariuszy zaproszonych na wydarzenie czy prezentację. Jednak w naszej opinii, osoby z wyższych szczebli organizacji, mogą potrzebować troszkę bardziej dopasowanego do nich podejścia. 

Przykładowo, zarządzający niekoniecznie muszą znać koncepcję wytwarzania oprogramowania, a sformułowania, którymi posługujemy się na co dzień, mogą być dla nich całkowicie obce i niezrozumiałe. To może wywołać w nich negatywne emocje, bo mało kto lubi czuć się niekompetentny, kiedy oczekuje się od niego jakiejś informacji zwrotnej.

Dlatego warto zadbać o wyjaśnienie technicznych pojęć, których nie jesteśmy w stanie uniknąć, a także pomyśleć jak to przedstawić bardziej opisowym językiem. Jednakże pamiętajcie również o zwięzłości wypowiedzi. Zarządzający zwykle dysponują małą ilością czasu i schodzenie na duży poziom detalu z wieloma wątkami pobocznymi, może nadmiernie wydłużyć spotkanie, przez co nie otrzymamy tego, po co ich zaprosiliśmy. Nim dojdzie do dyskusji i feedbacku, to osoby z zarządu opuszczą spotkanie, aby zdążyć na kolejne, jakie mają w kalendarzu.

Pamiętajcie także o dopasowaniu prezentacji z perspektywy technicznej. Odpuście pokazywanie całego back endu, czy struktury bazy. To zupełnie nie interesuje zarządu.

5. Zaangażuj zarządzających w spotkanie

Aby wyciągnąć jak najwięcej ze spotkania, na którym pojawią się osoby z zarządu, warto zadbać o wartościowe interakcje, np. poprzez zadawanie odpowiednich pytań, które przygotujecie sobie wcześniej. 

Z drugiej strony zachęcajcie też zarząd do zadawania pytań z ich strony, bo mogą one zapoczątkować ciekawe dyskusje, których sami byście nie rozpoczęli. 

Dynamiczne Przeglądy Sprintu, niosą ze sobą pewne ryzyko (np. pojawiające się trudne pytania), jednak mimo wszystko dają większą wartość i bardziej kompletny feedback, niż nudne spotkania, z małą ilością interakcji między uczestnikami. Oczywiście bądźcie uważni i jeśli rozmowa zbytnio się rozwleka lub za bardzo wchodzicie w detale, to reagujcie odpowiednio do sytuacji, np. parkując temat i zapisując go do listy tematów rozwojowych.

Nie bójcie się też bezpośrednio zadawać pytań i wywoływać do odpowiedzi, jeśli osoby z zarządu nie wchodzą w dyskusję i siedzą cicho. Może być tak, że nie wiedzą, kiedy mogą wejść w dyskusję, kiedy mogą zareagować i poruszyć interesujące ich kwestie.

6. Prezentacje prowadź od ogółu do szczegółu

Zwłaszcza jeśli zarząd jest obecny na spotkaniach tylko od czasu do czasu, to ważne jest, aby zacząć prezentację od jakiegoś ogólnego poziomu, np. zdefiniowania celu całego produktu, przedstawienia etapu, na którym jesteśmy, czy Celu Sprintu, jaki mieliśmy. To lepiej pozwala zrozumieć kontekst, w jakim się poruszamy. 

Osoby, które są obecne na każdym Przeglądzie Sprintu, mają poczucie kontynuacji i całego tła tworzenia produktu, natomiast interesariusze uczestniczący w spotkaniach od czasu do czasu, tej łączności już nie mają i mogą nie rozumieć, co się dzieje. To z kolei pociąga za sobą ryzyko, że feedback, jaki otrzymamy, nie będzie trafny i np. będzie dotyczył kolejnych etapów projektu, które są dopiero przed nami.

7. Pokaż rezultaty i efekty, a nie ile się napracowałeś

Prawda jest taka, że zarządu nie interesuje to, ile się napracowaliście, tylko to, co zrealizowaliście i co już mamy zrobione. 

Spotykamy się z sytuacją, gdzie dużą część przeglądu zajmuje blok, gdzie zespół po kolei pokazuje błędy, które zostały usunięte czy bardzo szczegółowe zmiany w produkcie, które mogą być istotne z perspektywy zespołu, ale w rzeczywistości to kropelka w morzu, jeśli patrzymy na to z szerszej perspektywy. 

Aby osoby z zarządu miały poczucie, że faktycznie warto pojawiać się na Przeglądach Sprintu, kiedy ich zapraszacie, to mocniej akcentujcie rezultaty i korzyści biznesowe, jakie uzyskujecie, a nie kwestie bardzo niskopoziomowe, jak kto co zrealizował lub ile zadań zamknęliście.

8. Pokaż dalsze plany

Ostatnia wskazówka związana z dobrze zorganizowanym Sprint Review z udziałem zarządzających jest przedstawienie kolejnych rezultatów, jakie chcemy uzyskać. 

Mamy tu na myśli coś więcej niż tylko kolejny Cel Sprintu czy dwa nowe ficzery, które dodamy w następnym Sprincie. Pokażcie parę kroków w przód, zwłaszcza jeśli osoby z zarządu pojawiają się dopiero za kilka przeglądów. Powiedzcie, jaki jest cel produktu, gdzie jesteście w jego realizacji, co będzie, jak go zrealizujecie? Możecie też rzucić okiem na Road Mapę rozwojową czy na jakieś wymiary projektowe, jeśli tak realizujecie swoją pracę. Być może warto poruszyć temat realizacji ustalonego zakresu lub budżetu przeznaczonego na ten projekt. Czy terminy istotne dla projektu są bezpieczne, czy może musimy wdrożyć jakieś działania naprawcze?

Wskazówki i przestrogi dotyczące Przeglądu Sprintu z udziałem zarządu

Teraz podzielimy się z Tobą kilkoma wskazówkami i przestrogami, na które warto zwrócić uwagę, jeśli zdecydujecie się zaprosić zarządzających na Przegląd Sprintu.

1. Bądźcie świadomi plusów z obecności zarządzających na Sprint Review

W zależności od kultury organizacyjnej oraz od dotychczasowych doświadczeń w interakcjach z osobami z zarządu lub braku tych doświadczeń, w Zespole Scrumowym mogą pojawić się pewne obawy czy wątpliwości związane z obecnością zarządu na spotkaniu. 

Dlatego warto, aby każdy członek zespołu miał świadomość, że jest to dla Was dodatkowa szansa na feedback. To też szansa na uzyskanie ważnych podpowiedzi, co do kierunku rozwoju produktu czy też planowanych zmian w firmie, które mogą mieć wpływ na waszą pracę. 

Nawet jeśli informacja zwrotna, którą uzyskacie, nie będzie pozytywna, to lepiej usłyszeć ją wcześniej, niż później. Z kolei z doświadczenia i z rozmów z wieloma zespołami wiemy, że strach ma zwykle wielkie oczy i zwykle obecność zarządu jest wspominana jako bardzo pomocna.

2. Nie organizuj takich wizyt z zaskoczenia

Zarówno zarząd, jak i zespół, powinien mieć czas, aby przygotować się do Przeglądu Sprintu. Tak jak zaproszenie zarządu z wyprzedzeniem wydaje się oczywiste, tak samo zespół powinien być poinformowany odpowiednio wcześnie o obecności osób zarządu na przeglądzie. To pozwoli się wszystkim oswoić z tą informacją, a także przemyśleć czy to nie będzie dobra okazja do poruszenia kilku dodatkowych tematów, na które wcześniej nikt nie potrafił odpowiedzieć, a management może mieć wiedzę na ten temat.

3. Użyj wsparcia sojuszników, żeby zaprosić właściwe osoby

Jak już wcześniej wspominaliśmy i jak pewnie sam dobrze wiesz, osoby z zarządu mają często zaplanowana każdą minutę. Dlatego warto poszukać wsparcia u osób, które mają częstszy kontakt z zarządem, aby pomogły nam w pokazaniu, że ich obecność będzie dużym wsparciem dla rozwoju produktu czy też samej zwinności w firmie.

Takim sojusznikiem może być np. szef IT lub inna osoba, która odpowiada za transformację zwinną. Może to być też przełożony Product Ownera, który będzie umiał ze swojego poziomu dobrze uargumentować, obecność osób, na których nam zależy. 

Nie wychodźcie z założenia, że jeśli Product Owner wysłał zaproszenie, a asystentka prezesa je odrzuciła, to już nic nie da się zrobić. Zastanówcie się, kto może was wesprzeć w tym temacie i wykorzystajcie taką możliwość.

4. Zaakceptuj, że skład spotkań będzie zmienny 

Często słyszymy od zespołów, że mają poczucie, że w oczach zarządu nie robią nic istotnego, bo kiedyś prezes lub inna osoba z top managementu przychodziła na przeglądy i nagle przestała. 

Miejmy jednak z tyłu głowy, że te osoby mają naprawdę napięte harmonogramy i spory obszar odpowiedzialności, dlatego nawet mimo szczerych chęci nie mogą pojawić się na wszystkich spotkaniach, na które są zapraszane. Zwłaszcza jeśli mają pod sobą kilka czy kilkanaście zespołów organizujących Przeglądy Sprintu. Pamiętajcie o tym i nie oczekujcie, że zawsze będą obecne na Waszym Sprint Review.

5. Rozważ dedykowane spotkanie poza cyklem Sprintowym

Nawiązując do poprzedniej rady, jeśli osoba z zarządu z jakiejś przyczyny nie może pojawić się na Przeglądzie Sprintu, a zarówno Wam, jak i jej bardzo na tym zależy, to warto rozważyć dodatkowe, krótkie spotkanie, nawet jeśli nie będzie to zgodne z frameworkiem Scruma. 

Od wszystkiego mogą być wyjątki, zwłaszcza jeśli możemy uzyskać wartościowy feedback od osób z wyższych szczebli organizacji. 

6. Skorzystaj z okazji do wskazania potrzebnych usprawnień na poziomie organizacji

Ostatnia wskazówka, jaką dla Ciebie mamy to wykorzystanie okazji spotkania z zarządem do poruszenia wątków związanych z optymalizacją procesów wykraczających poza zespół czy konkretny projekt, w którym bierzecie udział. 

Być może zmagacie się z jakimiś ograniczeniami systemowymi czy kooperacją między zespołową, przez co jakieś elementy produktu są opóźnione. Tego typu tematy warto wcześniej ustrukturyzować i dobrze przemyśleć, aby mieć zarówno argumenty za tym, że warto coś zmienić, jak i może propozycje takich zmian. Bądźcie konkretni, jasno przekazujcie swoje potrzeby i pokażcie korzyści z zaproponowanych zmian. Bądźcie też gotowi na szereg pytań, jak również na odłożenie tematu na inny okres. 

Bez względu na rezultat takiej dyskusji, zasygnalizujecie problem i pokażecie, że potraficie nie tylko narzekać, ale także szukać rozwiązań.

To już wszystkie nasze wskazówki dotyczące organizacji Przeglądu Sprintu, na który zapraszany jest zarząd. Być może dodałbyś/dodałabyś coś od siebie? Chętnie poznamy Twoje doświadczenia w tym obszarze.

TRANSKRYPCJA

Kuba: Dzisiejszy odcinek będzie o zarządzających na Przeglądzie Sprintu. Do tematu zainspirowała mnie grupa z Prawdziwych Przypadków Scrumowych, które skończyły się kilka dni temu. No i jak zwykle różnorodna grupa miała wiele wątków, wiele dyskusji, to i tak nie jestem w stanie przekazać, jak fajne wydarzenie to było. Ale jedną z jednym z punktów, który właśnie wywołał sporą dyskusję i sporą różnicę przemyśleń i podpowiedzi, to był właśnie temat, jak ściągnąć zarząd, czy top management na Przegląd Sprintu. I tutaj trochę odtworzę treści z Jackiem, tego, co wydarzyło się na Przypadkach Scrumowych, ale też dodamy od siebie parę punktów, które wtedy na sali się nie pojawiły. Więc nawet osoby, które pozdrawiam, które były na tamtym wydarzeniu też dostaną dodatkową porcję wiedzy. Załóżmy, że porcję od Jacka. 

Jacek: Struktura dzisiejszego odcinka będzie następująca. Na początku w ogóle zdefiniujemy kogo mamy na myśli, mówiąc o zarządzających. Następnie opowiemy o tym, jak zrobić Przegląd Sprintu, które zainteresuje osoby zarządzające. No i standardowo na koniec podzielimy się przestrogami, wskazówkami, jak zrobić to porządnie. 

Kuba: Zanim zaczniemy, przypominamy, że jeśli chcesz pogłębić wiedzę jeszcze bardziej niż robimy to w podcaście, to znajdziesz nasze płatne produkty na stronie porzadnyagile.pl/sklep

Jacek: Gdy mówimy o zarządzających, to mamy na myśli dość szeroką grupę osób, która może w różny sposób być określana w zależności od organizacji. Czasem to może być faktyczny zarząd firmy, czasem to mogą być dyrektorzy zarządzający. Czasem występują pod nazwą Leadership Team. Czasem mówimy na nich „headzi”, tak bardzo po staropolsku. Czasem jest to top management. Tak więc na pewno chodzi nam w tym odcinku o tą faktycznie taką warstwę, która jest umocowana, bądź na samym szczycie struktury, bądź powiedzmy sobie jeden poziom niżej. 

Kuba: I przechodząc do naszych zasadniczych porad. Jak zorganizować Sprint Review, które zainteresuje zarządzających. 

Jacek: Przede wszystkim wybierz właściwy moment na zaproszenie. Kontekst  tego, co aktualnie wykonujemy, może być dosyć istotny. Jeżeli rozwijasz konkretny produkt albo realizujesz jakiś większy projekt, czy jakąś większą inicjatywę, to nie każdy moment na zaproszenie osób zarządzających może być sensowny. Przykładowo, jeżeli to jest bardzo początkowa faza, gdzie jeszcze niewiele można pokazać, to wszystko jest jeszcze w powijakach, no może być tak, że osoba zarządzająca przyjdzie i tak do końca nie będzie miała się do czego odnieść, więc warto by było taką osobę zaprosić. W momencie, kiedy czujemy, że to, co faktycznie mamy już wyprodukowane nadaje się do przedyskutowania, nadaje się, żeby obrócić to w jakąś sensowną informację zwrotną.

Kuba: Dla równowagi powiem, że jest też czasem taka pokusa, żeby zarządzających ściągnąć na Review, na którym jest już wszystko gotowe i nic, tylko uzyskać potwierdzenie. To może być fajne i obiecujące, bo faktycznie wtedy już jest sporo gotowe. Ale może być też tak, że wtedy, jeśli uzyskamy jednak jakąś informację zwrotną, która jest ważna dla produktu, to ta sytuacja może być bardzo, bardzo nerwowa. Więc pewnie warto pomyśleć, żeby jednak nie zostawić tego na ostatnią możliwą chwilę. Może dać sobie szansę krok wcześniej, dwa kroki wcześniej i tych zarządzających, jeśli nie możemy mieć ich regularnie, bo to jest trochę teza z tej porady, to chociaż zadbajmy o to, żeby się pojawili w takim momencie, gdzie mamy coś, co pokazać, ale też mamy szansę coś zrobić z feedbackiem, który dostaniemy. Oczywiście najważniejszy będzie ten, którego się w ogóle nie spodziewaliśmy, no bo on może wpłynąć na nasze plany.

Kuba: Druga wskazówka, zapewnij, że zarządzający wiedzą, czym jest Przegląd Sprintu. Z moich obserwacji takich sytuacji, o których mówimy w tym odcinku, może się ujawnić takie zagrożenie, że przychodzi jakiś członek zarządu na spotkanie. Spotkanie, które być może jest dla tej osoby nowością, zwłaszcza jeśli mówimy tu o organizacji, która dopiero zaczyna wykorzystywać metody zwinne. Może to jest dopiero pierwszy zespół pilotażowy, w którym Scrum jest stosowany? Taki Przegląd Sprintu jednak ma pewną specyficzną formułę, formułę nietypową dla takich klasycznych spotkań zarządczych. Więc tutaj cała ta sfera wiedzowa czy taka, taka wręcz może aż definicyjna, no ale bardzo praktyczna, ona musi być tutaj przekazana. I tutaj znajdźmy sposób, niech to będzie może Scrum Master, może będzie to Product Owner, a może jeszcze ktoś inny, kto przekaże takiej osobie, która po raz pierwszy przychodzi na nasz przegląd Sprintu, czego oczekujemy od udziału takiej zaproszone osoby? I to jest akurat to miejsce, które, ta rada jest bardzo generyczna, bo tak w ogóle to każdy zaproszony gość na Przegląd Sprintu powinien dostać taką króciutką instrukcję, czym jest to wydarzenie. Może to jest początek spotkania, a może to jest coś, co się dzieje w zaproszeniu, czy w toku zapraszania? Po co chcemy, żeby ta osoba uczestniczyła? Czego się, czego się spodziewamy też od ich udziału i jakie interakcje są wskazane, żeby tutaj ta osoba przychodząca wiedziała, jak się zachować. To na dwoje babka wróżyła. Może czasami ktoś się zawahać i na przykład nie dać feedbacku, bo on nie wie, że tego od tej osoby oczekujemy. No, a zarządzający pewnie mają mniej takich dylematów i mogą czasami po prostu w zespół wejść trochę mocniej, niż byśmy tego potrzebowali, albo na przykład storpedują nam zaplanowaną strukturę i ten styl pracy, taki powiedzmy, jaki stosujemy na Przeglądzie Sprintu. 

Jacek: I miałem o tym, jak to zrobić, dyskusję na ostatnim zamkniętym szkoleniu, które prowadziłem. No i z grupą się zgodziliśmy, że jest to dosyć kontekstowe. Na takiej zasadzie, że jeżeli wiemy, że dopraszamy jedną, dwie osoby, które są nowe, natomiast reszta organizacji rozumie czym jest to wydarzenie, to warto to zrobić po prostu na zasadzie jakiejś wcześniejszej rozmowy. Jeżeli na przykład, dopiero zaczynamy pracę, tu akurat mówimy o jakiejś formie Scruma, czy sporą grupę nowych interesariuszy zarządzających zapraszamy na takie wydarzenie, to może to być wręcz taki stały punkt przez pewien cykl. Na zasadzie punktu, czy takiego komentarza na początku. Czym jest przegląd Sprintu? Czego oczekujemy? Z czym byśmy chcieli z tego spotkania wyjść?

Jacek: Kolejna porada, przygotuj zarządzających na to, co zobaczą na Przeglądzie. Taki sensownie realizowany rozwój produktu charakteryzuje się tym, że produkt wyłania się na skutek pracy zespołu. Może to powodować, że to co będziemy pokazywać na takim Przeglądzie, będzie niedokończone, nieperfekcyjne, niedoskonałe, niewypolerowane. Pewne rzeczy być może będą jeszcze jakoś tam imitowane. Nie będzie to działało tak jak powinno. Nie wszystkie ścieżki będą realizowane. Jakieś konkretne pytanie? A co jeśli X? Być może nie będziemy mieli jeszcze dobrej, ani odpowiedzi, ani nie będzie co pokazać. Więc warto, tak jak mówiliśmy o tym, że dobrze jest przygotować grupę do spotkania, tak samo warto opowiedzieć trochę o tym, co może się wydarzyć i z czym się wiąże to, że produkt rozwijamy krokowo tak, żeby nie było szoku, że ktoś się spodziewał, że zobaczy idealny, perfekcyjny produkt. A my mu pokazujemy coś, co może być odebrane, że to jest jakiś prototyp, albo coś, co w ogóle pewnie wyląduje jeszcze w koszu. Kuba: I broń Boże, nie sugerujemy, żeby na Sprint Review pokazywać rzeczy bardzo słabe jakościowo. Jakby tutaj nie od tej strony używamy tych przymiotników o niedoskonałościach, tylko raczej o tym, że to rozwiązanie jest jeszcze częściowe. Niektóre ficzery są niezbudowane. Chociaż nawet z tą jakością bywa różnie, bo tutaj się z grupą warsztatową trochę pośmialiśmy, że jak ma się coś zdarzyć niespodziewanego, to się właśnie zdarzy w najmniej odpowiednim momencie. Czyli tu też na takiej części prezentacyjnej może się zdarzyć tak, że jakiś niespodziewany błąd albo jakaś awaria środowiska może nam wyskoczyć. No i w zależności od tego oczywiście z kim rozmawiamy, to być może z tą osobą też można wyprzedzająco już chwilę porozmawiać, że jesteśmy w środku developmentu i mogą się zdarzyć pewne niedoskonałości, żeby tutaj nie wyciągać wniosków. Lub alternatywnie, jeśli coś takiego się wydarzy, to też gdzieś z gracją i bardzo szczerze powiedzieć, że wydarzyło coś, co się wydarzyło. Żebyśmy też nie zbudowali bardzo błędnego wrażenia o słabej jakości naszej pracy albo o tym, że byliśmy nieprzygotowani. Bo to też może bardzo złą opinię ostatecznie zbudować u takiej osoby wizytującej dany zespół. Więc tutaj wartości scrumowe muszą zadziałać. Bądźmy otwarci, bądźmy odważni w tym, żeby powiedzieć dokładnie, jak jest  i odważnie też się ewentualnie skonfrontować z wyobrażeniem, które zbudowaliśmy świadomie lub niestety się przez przypadek tak zdarzyło, że coś tam wyskoczyło. 

Kuba: Czwarta porada,  dopasuj prezentację do odbiorcy. Ta porada jest oczywiście generyczna, ale zawsze prawdziwa do wszystkich interesariuszy, ale zwłaszcza ci wyżsi zarządzający mogą potrzebować troszkę inny rodzaj przedstawienia tego, nad czym pracujemy. Chodzi mi tu o to, że porównując do takiego typowego interesariusza, być może musimy uwzględnić i skorygować trochę język, w którym mówimy, bo być może nasz wyższy zarządzający nawet niekoniecznie w ogóle zna koncepcję wytwarzania oprogramowania, więc tutaj wiele takich słów, sformułowań, które będą jasne na poziomie tej grupy osób, z którymi pracujemy na co dzień między zespołem a interesariuszami, no to ten język fachowy, taki na przykład język wytwarzania oprogramowania, ale to też może być język rozwoju produktu. To może nie być do końca jasne i na wszelki wypadek nie zaszkodzi pół zdania więcej z odrobiną definicji tego, co mamy na myśli. Dla równowagi z drugiej strony warto też zadbać o zwięzłość. Byłem świadkiem wielu takich Przeglądów Sprintów, w których zespół schodził na duży poziom detalu, w dużą ilość jakiś takich wątków pobocznych. To wszystko powodowało, że spotkanie się wydłużało. No ale tutaj możemy od razu z góry założyć, że tacy wyżsi zarządzający dysponują małą ilością czasu. Jeśli już udało nam się ich zaprosić na to spotkanie, to też skorzystajmy z tej okazji, żeby sprawnie przekazać to, co mamy my do przekazania i zostawić miejsce na to, żeby fajnie ze sobą porozmawiać, popracować nad tym, co mogłoby z takiej interakcji wyjść. I kwestia też dopasowania prezentacji z perspektywy technicznej. Tutaj zespoły czasami mają pokusę pokazania zbyt niskopoziomowo wykonywanej pracy, zbyt niskopoziomowo wykonanego produktu. Te kwestie dla wybranych wyższych zarządzających, nawet nie to, że nie są zrozumiałe. One po prostu nie będą interesujące. Tutaj może przyjmijmy założenie, że po prostu wyżsi zarządzający oczekują, że zrobimy to dobrze i nie musimy pokazać całego back endu albo całej struktury bazy, co niestety w niektórych zespołach się zdarza, nawet przy takich wyższych zarządzających. 

Jacek: Następna porada zaangażuj zarządzających w spotkanie. Gdy uda się nam już zaprosić osoby zarządzające na Przegląd Sprintu. Warto zadbać o to, żeby doszło między nami do wartościowych interakcji. Interakcje mogą przybrać bardzo różną formę. Czasem to mogą być po prostu pewne pytania wprost, które bądź my możemy zadawać, chcąc uzyskać feedback do pewnych konkretnych aspektów produktu, który prezentujemy. Ale możemy też się spodziewać, że takie pytania padną w drugą stronę i to mogą być pytania, których się nie spodziewaliśmy. Z drugiej strony jest to super okazja, żeby usłyszeć szeroko rozumianą informację zwrotną do tego, co widać, do tego, co pokazujemy, jeśli prezentujemy jakieś konkretne, wybrane aspekty naszego produktu. Warto zachęcać do takich interakcji, żeby one się wydarzały w trakcie samego wydarzenia. Żeby uniknąć sytuacji, że ktoś przez 30 minut biernie tylko siedzi, konsumuje to, co prezentuje zespół. No i w pewnym sensie tak sztucznie trochę parkujemy, że czas na pytania będzie na końcu. Osobiście jestem fanem Przeglądów Sprintu, które są dynamiczne. Zwykle panuje tam zasada, że jeżeli jest jakieś pytanie w trakcie, to od razu je zadajemy, od razu je rozbrajamy. Oczywiście mając z tyłu głowy, że jeżeli rozmowa się jakoś tam zbytnio rozwleka, albo za bardzo wchodzimy w detale, to oczywiście z prawem do zaparkowania takiej dyskusji i do pójścia dalej.

Kuba: No i ten punkt jest bardzo powiązany z punktem, o którym już wspomnieliśmy, czyli jasnym wyjaśnieniu uczestnikom, czego od nich oczekujemy. Tutaj jest kontynuacja. Jeśli zapowiedzieliśmy, że będziemy oczekiwali np. informacji zwrotnej, to czy to Scrum Master, czy Product Owner, czy ktoś z zespołu, kto prowadzi jakiś moment. Moim zdaniem dostaje też pełne prawo do tego, żeby wręcz imiennie wywołać. W zależności od tego, jak mamy kulturę organizacyjną. Panie prezesie albo Michał, co o tym sądzisz? No, żeby właśnie uruchomić pewną rozmowę. Uwzględnimy też to, że zwłaszcza w tych organizacjach, w których ta kultura jest taka bardziej miękka, to ta druga strona, czyli ci zarządzający, mogą też mieć wahania czy zastanawiać się, jak zareagować, kiedy jest właściwy moment, kiedy jest już ten moment. Więc tutaj nie bójmy się bardzo otwartego angażowania, uruchamiania pewnych tematów, uruchamiania pewnych rozmów czy pytań. I nie bójmy się nawet tych pytań celowanych, pytań z tezą. Jak to odbierasz? Co Twoim zdaniem jeszcze powinniśmy zrobić? Jak Ci się to podoba? Te pytania mogą, one mają tezę, ale one też są bardzo konkretnie nakierowane na to, czego potrzebujemy. 

Kuba: Następna porada, prezentacje prowadzi od ogółu do szczegółu. Zwłaszcza jeśli ten zarządzający pojawił się po raz pierwszy albo pojawia się okazjonalnie. To bardzo, bardzo potrzebne jest to, żeby zacząć od jakiegoś ogólnego poziomu, być może zdefiniowania celu całego produktu, który aktualnie realizujemy. Etapu, na którym jesteśmy, Celu Sprintu, jaki mieliśmy. Po co w ogóle to zrobiliśmy? Może tu jest miejsce na takie bardzo wyróżnione, na to, żeby Product Owner uruchomił też jakąś taką krótką opowieść o tym, dlaczego w ogóle takie elementy realizujemy. Zanim przejdziemy np. do pokazania konkretnych ficzerów, które albo w ostatnim Sprincie, albo w kilku ostatnich Sprintach były przedmiotem prac. Odwrotność tego coś, co niestety widuję dosyć często, to to, że w zasadzie w drugiej minucie Przeglądu już jesteśmy na poziomie poszczególnego pojedynczego, drobnego przycisku na trzeciej zakładce, a tak naprawdę trochę nie wiemy, w jakim kontekście tutaj się znajdujemy, czy jesteśmy. I ten przypadek nie jest taki bolesny, jeśli nasz interesariusz jest z nami co Sprint i tak naprawdę śledzi razem z nami wydarzenie i ma jakąś tam łączność, czuje się jak w serialu w sezonie, który ma wiele odcinków i po prostu jest pewna kontynuacja. No ale osoba, która pojawi się u nas okazjonalnie tej łączności nie ma i po prostu nie rozumie co się dzieje, albo nie jest odpowiednio wtajemniczona. To trochę nam grozi, że feedback, który dostaniemy będzie może niedobrze wycelowany, albo pojawi się pewne niezrozumienie czy może nawet lekka frustracja, że nie wiem co się dzieje, A jak nie wiem co się dzieje, to mogę się zachować dziwnie. 

Jacek: I myślę, że to też jest dobra okazja, żeby zweryfikować albo upewnić się, że potrafimy sensownie opowiedzieć o produkcie wysokopoziomowo, a nie tylko zejść na poziom ficzerów. Myślę, że jeśli coś opowiemy nieperfekcyjnie, niedoskonale, to możemy się spodziewać jakiegoś komentarza, być może wyrównującego wiedzę, a może komentarza, który daje dodatkowy kontekst. Więc zdecydowanie warto taką próbę podejmować. 

Jacek: Przedostatnia porada. Pokaż rezultaty i efekty. Porada, która ma na celu zaakcentowanie tego, że tak naprawdę nie chodzi nam o to, żeby pokazać jak bardzo się na pracowaliśmy, tylko żeby pokazać, co ten konkretny Sprint pomógł nam osiągnąć, do czego nas przybliżył, co udało nam się zrealizować. Bardzo często widzę, że zespoły mają taką pokusę, żeby nawet wyrażaną słownie, że tyle rzeczy zrobiliśmy, chcemy to wszystko pokazać. I przykładowo rozpoczyna się cały długi blok, gdzie po kolei pokazywane są błędy, które zostały zrealizowane, albo jakieś takie bardzo precyzyjne zmiany w produkcie, które być może są istotne z perspektywy zespołu. Ale jeżeli trochę to mówiąc metaforycznie kamerę oddalimy, żeby zobaczyć nasz produkt z szerszej perspektywy, to jest to po prostu jakaś tam kropelka w morzu. Tak więc w szczególności kiedy mówimy dzisiaj o Przeglądzie Sprintu, na którym mamy osoby zarządzające, to mimo wszystko bym tą kamerę ustawił tak, żeby mocniej akcentować te faktyczne rezultaty, korzyści biznesowe, które uzyskujemy, a niekoniecznie niskopoziomowy produkt. 

Kuba: I zamieniając tę radę na bardzo konkretną podpowiedź, no to myślę, że wyższych zarządzających niekoniecznie będzie interesowała lista zadań, które zrealizowaliśmy, pokazana w narzędziu elektronicznym. Co też się niestety dosyć często zdarza. Pokażmy produkt i niekoniecznie wszystkie szczególiki, które zrobiliśmy. Jirę pokazujemy, jeśli pracujemy w Atlassianie, podobnie Trello i wszystkie inne narzędzia elektroniczne pewnie byłyby właściwym przedmiotem Przeglądu Sprintu, jeśli rozwijamy właśnie Jirę. Natomiast to pytanie, żeby pokazać rezultaty i efekty, ono może w ogóle otworzyć inną rozmowę. Czy my w ogóle pamiętamy o tym poziomie? Czy zwracamy na to uwagę? Czy mamy coś do powiedzenia w tym temacie? No i dobry Przegląd Sprintu mówi właśnie raczej o tym, gdzie jest nasz produkt, a nie kto wykonał które zadania albo ile tych zadań zrealizowaliśmy. 

Kuba: I ostatnia wskazówka w temacie zorganizowanie lepszego Sprint Review interesującego dla zarządzających, to pokaż dalsze plany. Czyli tak jak w poprzedniej radzie rozmawialiśmy o uzyskanych rezultatach, to pokażmy też jakie kolejne rezultaty chcemy uzyskać. I mam na myśli tutaj coś więcej niż tylko Cel Sprintu na najbliższy krok. Albo dwa ficzery, które jeszcze dorobimy, co by ewidentnie nawiązywało do tej prezentacji, którą zrealizowaliśmy. Ale zwłaszcza jeśli ci zarządzający wiemy, że się pojawili teraz i przez jakieś kilka Sprintów nie mamy co liczyć, że się pojawią ponownie, co jest taką powiedzmy realistyczną postawą czy nastawieniem. No to pokażmy też te parę kroków w przód. Jaki mamy cel produktu? Gdzie jesteśmy w jego realizacji? Kiedy czujemy, że to będzie już wystarczająco dobre, żeby podjąć jakiś następny cel produktu? Co to będzie, jak już skończymy? Może jakiś rzut oka na Road Mapę taką właśnie rozwojową, teraz, w kolejnym kroku, w następnych krokach. Jeśli realizujemy pracę projektowo, jeśli nasza organizacja też tego wymaga, no to może też rzut oka właśnie na jakieś takie wymiary projektowe. Jeśli jest jakiś zakres, to gdzie jesteśmy z realizacją zakresu? Jeśli jest budżet, to gdzie stoimy z realizacją budżetu? A jeśli jest jakiś termin, z jakiegoś powodu ważny dla projektu, to jak się do tego terminu odnosimy? Czy się czujemy OK z terminem? Czy może czujemy, że jesteśmy lekko w plecy? Tu bardzo rzetelnie, bardzo szczerze warto takie rzeczy mówić. To w efekcie może spowodować bardzo konkretną dawkę informacji, która jest ważna dla zarządzających, pokazująca im rzut oka na pewne większe całości. No i z drugiej strony dający też okazję do tego, żeby być może z tego też coś fajnego wyszło. Zwłaszcza jeśli w zespole są pewne kłopoty, albo trzeba podjąć pewne większe decyzje. To tutaj tak naprawdę uruchamiamy też taką pewną rozmowę. Co dalej z tym, jakie decyzje muszą zapadnąć? Za jakimi my, jako Zespół Scrumowy decyzjami lobbujemy, żeby tutaj faktycznie coś uzyskać korzystnego? 

Jacek: I przejdziemy teraz do jeszcze paru konkretnych takich przestróg, wskazówek, rzeczy, na które warto, żebyś zwrócił bądź zwróciła uwagę, gdy już z zespołem zdecydujecie się, że warto zarządzających na taki Przegląd Sprintu zaprosić.

Kuba: Pierwsza wskazówka to jasne postawienie sobie sprawy w całym Zespole Scrumowym, że taka obecność zarządzających to dodatkowa szansa na feedback. W zależności od kultury organizacyjnej, od dotychczasowych doświadczeń w interakcjach z takimi osobami lub braku tych doświadczeń, bo to też może być nawet taka sytuacja, mogą się pojawiać pewne obawy, pewne wątpliwości. Też może taka dyskusja na argumenty, czy to w ogóle ma sens, żeby takiego zarządzającego zaprosić? To zdecydowanie powinno być nakierowane właśnie na okazję do uzyskania informacji zwrotnej, do uzyskania jakichś bardzo ważnych podpowiedzi. I szczerze mówiąc, nawet w takim podejściu, że może pójdzie coś nie tak, to lepiej, żeby poszło nie tak szybko. Czyli trochę takie hasełko z Agile’a – fail fast. Czyli gdyby nawet ten zarządzający miał ochotę nam zainterweniować w to, co realizujemy, to lepiej dowiedzmy się o tym wcześniej niż później. Co wraca trochę do tej też wskazówki, żeby nie odkładać wizyty takich osób na sam koniec, albo postawić ich przed faktem dokonanym, bo wtedy może być bardzo gorąco. Jeśli zaangażujemy takie osoby odpowiednio wcześnie, ten feedback być może też będzie możliwy do zaimplementowania też odpowiednio wcześnie. Natomiast coś, co na grupie ustaliliśmy w czasie warsztatów, to pomimo jakichś tam kilku historii traumatycznych, większość osób miała poczucie, że może strach ma wielkie oczy i było w sumie lepiej niż się wszyscy bardzo obawiali.

Jacek: Tak zwykle jest w praktyce. Kolejna porada nie organizuj takich wizyt z zaskoczenia. I o tyle, o ile wszystko to, co Kuba mówi, jest prawdą, to na pewno warto zadbać o to, żeby jednak zespół nie był postawiony przed faktem dokonanym. Myślę, że ta decyzja, że zapraszamy osoby zarządzające, powinna być przepracowana w zespole, tak żeby się też w pewnym sensie mentalnie oswoić z tą decyzją. Może przygotować, może to będzie szansa na wyciągnięcie naszego Przeglądu Sprintu na trochę wyższy poziom. W sumie nie widziałem nigdy, żeby zespół był zadowolony, że ktoś się pojawił znienacka. Zawsze jakiś taki mały niesmak pozostawał. Ja zdecydowanie jestem fanem tego, żeby jeżeli oczywiście mamy na to wpływ, żeby zespół do takiej wizyty mentalnie przygotować. 

Kuba: Trzecia wskazówka to, użyj wsparcia sojuszników, żeby zaprosić właściwe osoby. Kilka razy już w tym nagraniu użyliśmy takiej frazy, że uda się zaprosić albo że rzadko te osoby się pojawiają. To jest niestety taka rzeczywistość, że tutaj ci wyżsi zarządzający mający pod opieką zapewne dziesiątki albo setki osób w swoich strukturach, po kilka bardzo ważnych inicjatyw, o których być może część to nawet nie wiemy, że się nimi zajmują. To są osoby bardzo zajęte. Jeśli zależy nam na tym, żeby te osoby się u nas pojawiły, to być może musimy też wykonać pewną taką trochę pracę, zakulisową. Poszukać kogoś, kto nam pomoże te osoby zaprosić czy namówić na spotkanie. Mówię to z założeniem o tym, że być może jednak Product Owner nie ma aż takiego wejścia w te najwyższe poziomy zarządzających. Zwłaszcza w większych organizacjach, to to jest niestety rzeczywistość. Albo, nawet jeśli mamy dostęp, to jednak ta nasza argumentacja oddolna, zespołowa może być niewystarczająca. Więc takimi przykładowymi sojusznikami mogą być osoby, które np. angażują się w zwinność w organizacji. Może to jest jakiś szef IT, może to jest osoba, która odpowiada za transformację zwinną. Te osoby mogą czasami móc też się powołać właśnie na to, że oprócz tego, że zespół robi fajne rzeczy, to to też będzie ważny krok dla samej zwinności w organizacji. Żeby takie interakcje między zarządzającymi a zespołami uruchamiać. A z innej perspektywy, to może być też tak, że sojusznikiem będzie np. przełożony Product Ownera, który będzie umiał, jeszcze tak powiedzmy, ze swojego poziomu wyższego zarządzającego dobrze zaargumentować, żeby jeszcze kolejne osoby tutaj na to spotkanie zaprosić – te, na których nam bardzo zależy. Więc tutaj warto tę sytuację, nazwijmy to trochę zaplanować politycznie. Nie wychodzić z założenia, że Product Owner wysłał zaproszenie, asystentka prezesa odrzuciła. No to koniec sprawy. Myślę, że jest na to sposób. Tylko być może te osoby, które inicjują to zaproszenie, nie są tymi właściwymi osobami, bo tak akurat w tej firmie to funkcjonuje. Firmy są różne, w niektórych może być tak, w niektórych inaczej. Zastanówmy się kontekstowo, jak to w naszej firmie działa. Jak to się dzieje, że wyższych zarządzających niektórzy są w stanie zaprosić, a inni nie.

Jacek: Kolejna wskazówka. Zaakceptuj, że skład spotkań będzie zmienny. Często spotykam się z takim feedbackiem od zespołów, że kiedyś to było, bo prezes czy dyrektor, czy jakaś osoba zarządzająca przychodziła na nasze Przeglądy, a teraz tej osoby nie ma. I oczywiście rodzi się w głowach takie poczucie, że nie robimy nic istotnego albo że może w ogóle jesteśmy jakoś tam poza obszarem zainteresowania. Natomiast myślę, że warto mieć z tyłu głowy, że trochę w powiązaniu tego, co Kuba przed chwilą powiedziałeś. Zwykle te osoby mają spory obszar odpowiedzialności i trudno też oczekiwać, w szczególności, jeśli mamy kilka, a czasem też kilkanaście zespołów, które organizują Przeglądy Sprintu, że na każdym Przeglądzie Sprintu, jak w zegarku wszyscy będą się pojawiać. Więc urealniłbym sobie trochę te oczekiwania. Po prostu raz te  konkretne osoby zarządzające pojawią się na naszym spotkaniu. Czasem się nie pojawią i po prostu myślę, że warto być na to przygotowanym.

Kuba: Kolejna wskazówka nawiązująca do tego, co Jacek powiedział, to rozważ dedykowane spotkanie, poza cyklem sprintowym. Czyli może być też tak, że na przykład nasz Przegląd Sprintu wypada akurat nieszczęśliwie i z jakiegoś powodu tym zarządzającym po prostu z logistycznych przyczyn nie będzie pasowało się u nas pojawić, ale za to chętnie by zobaczyli, co realizujemy. I być może, już nawet nie chcę tutaj dyskutować o tym, czy to jest zgodne z frameworkiem scrumowym czy nie, ale być może ma sens zrobić jakieś dedykowane, osobne, krótkie spotkanie. Jeśli zależy nam na informacji zwrotnej, jeśli zależy nam na tym, żeby ta osoba była też dobrze poinformowana, gdzie jesteśmy, dobrze wtajemniczona też w nasze pomysły, no to być może czy to Product Owner, czy to nawet jakaś reprezentacja zespołu mogłaby zrobić krótką wersję tego, co normalnie zrobilibyśmy na Sprint Rewiew, ale dedykowaną np. do całego zarządu albo do wybranych osób, na których nam szczególnie zależy. Gdyby się to miało utrwalić i jest jakiś piękny termin, w którym naprawdę cały zarząd może do nas się pojawić, to być może to jest właśnie podpowiedź, że to wtedy powinniśmy robić Sprint Review, nie w tym terminie, którym pierwotnie sobie to zaplanowaliśmy. Ale tutaj jakby nie bójmy się, czy jakby nie ograniczajmy się taką myślą, że jedyny moment, w którym feedback się w zespole pojawia, to jest moment Sprint Review z góry ustalone i co dwa tygodnie wypadający w piątek o 13:00. Bo być może ten feedback możemy zbierać też w środku Sprintu, między Sprintami, czy w jakichś takich fajnych wydarzeniach, które trochę specjalnie musimy jakby dodatkowo zorganizować, ale za to w nagrodę dostajemy te wszystkie pozytywy, jakie wynikają z koncepcji informacji zwrotnej w Scrumie. 

Jacek: I ostatnia wskazówka praktyczna. Skorzystaj z okazji do wskazywania potrzebnych usprawnień na poziomie organizacji. Może być taka sytuacja, że wizyta osoby czy osób zarządzających, stanie się pretekstem do wskazania, dlaczego na przykład jakieś elementy produktu są opóźnione. Być może wynika to z jakichś ograniczeń systemowych, być może wynika to z jakiejś konfiguracji zespołów. Być może wygląda to w ten sposób, bo nasz proces nie jest do końca sensownie zoptymalizowany i może być też tak, że to nie do końca jest w gestii, czy w możliwości zespołu, żeby to usprawniać. Więc w takim przypadku wizyta tych osób może być fajnym pretekstem do tego, żeby pokazać, że gdybyśmy w tym obszarze dokonali jakichś tam konkretnych usprawnień, to np. bylibyśmy w stanie skrócić czas od momentu, kiedy konkretna zmiana w produkcie jest gotowa, do momentu, kiedy użytkownicy faktycznie mogą z niej skorzystać.

Kuba: I to wskazanie potrzebnych usprawnień. Fajnie, żeby było bardzo dobrze ustrukturyzowane i dobrze przemyślane, żebyśmy tego nie zamienili tego w taką sesję wymówek albo taką sesję stękania, że świat byłby lepszy, gdyby coś tam. Tylko jednak, jeśli mamy jakieś konkretne przemyślenia, wynikające np. z poprzednich naszch Retrospektyw Sprintu, no to bardzo konkretnie skorzystajmy z okazji, że nie tylko ujawniamy, co realizujemy i wystawiamy się na informację zwrotną, ale nie bójmy się też powiedzieć, że mamy też pewne oczekiwania. Opisujmy sytuację, jaka następuje. Jaka jest konkretna nasza potrzeba. Jaka jest przewidywana korzyść z tego, że coś zrobimy. Jakie inne opcje też rozważyliśmy, ale z jakiegoś powodu tamte pozostałe odrzucamy, albo uważamy, że tą, którą chcemy, tą, o którą prosimy czy żądamy, wręcz, że ta jest nasza, preferowana. Więc tutaj osoba, która formułuje jakieś oczekiwanie, niech będzie taka bardzo rzetelna, bardzo konkretna i w takich punktach pach, pach, pach przekazuje czego oczekuje i też konkretnie nazywa akcję, którą oczekuje od tej osoby, do której się zwraca. Oczywiście zarządzający nie dadzą sobie w kaszę dmuchać, więc spodziewajmy się też otwartej rozmowy, że to nie tak, że coś inaczej, że mamy alternatywny pomysł. No ale bądźmy konkretni. Odbierzmy też konkretną reakcję od tamtej osoby. Jest spora szansa, że uzyskamy fajne rezultaty i to, co nas tam boli, to albo w jakimś stopniu zostanie zmienione, albo przynajmniej uruchomione zostaną pewne działania, że to zostanie zmienione za jakiś czas.

Kuba: Podsumowując cały odcinek. Jak zorganizować Sprint Review, które zainteresuje zarządzających? Wybierz właściwy moment na zaproszenie. Zapewnij, że zarządzający wiedzą, czym jest Przegląd Sprintu. Przygotuj ich na to, co zobaczą na Przeglądzie. Dopasuj prezentację do odbiorcy. 

Jacek: Zaangażuj zarządzających w spotkanie. Prezentację prowadzisz od ogółu do szczegółu. Pokaż rezultaty i efekty i pokaż dalsze plany. 

Kuba: Od kilku odcinków zapraszamy na nasz webinar o Dekompozycji elementów Backlogu Produktu. Samo nagranie jest już przygotowane i znajduje się w montażu, więc jesteśmy już na ostatnich metrach do tego, żeby je udostępnić do wszystkich chętnych. Natomiast w ramach takiego wydarzenia, też celebrującego ten moment chcemy zorganizować live’a. Live’y realizowaliśmy już parę lat temu, ale trochę zapomnieliśmy o tej praktyce. Zrealizujemy Live’a w formule Q&A, czyli pytania i odpowiedzi, dokładnie nacelowane na temat Dekompozycji elementów Backlogu Produktu. Live odbędzie się 24 listopada 22 go roku. Jest to czwartek o godzinie dwudziestej. Link do wydarzenia znajdziesz na porzadnyagile.pl/live. Dla pewności przeliteruję, L, I, V, E. Zrobimy tego live’a testowo na YouTubie. Poprzednie nasze live’y były na Facebooku, ale coś jesteśmy ostatnio nieprzekonani do tej platformy. Zobaczymy jak nam wyjdzie na YouTube. Bardzo ważne zastrzeżenie. Ten live będzie dostępny na żywo dla wszystkich chętnych. No ale samo nagranie, przypomnienie tej treści będzie dostępne wyłącznie dla osób, które wykupią cały webinar.

Jacek: Notatki do tego odcinka, artykuł, transkrypcja oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/98. 

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

Jacek: Dzięki Kuba. 

Kuba: I do usłyszenia wkrótce