Retro nie usprawnia Twojego zespołu? 🤔 Sprawdź nasz webinar, jak robić porządną Retrospektywę 🔥

Zarządzający na Przeglądzie Sprintu

Co możesz zrobić, żeby zainteresować zarządzających Przeglądem Sprintu? Sprawdź listę naszych pomysłów na to, jak sprawić, żeby Zespół Scrumowy i zarządzający byli usatysfakcjonowani udziałem w wydarzeniu scrumowym. Mamy dla Ciebie garść wskazówek, żeby podejść do tematu porządnie.

Co poruszamy w tym materiale?

Kogo mamy na myśli pisząc Zarządzający na Sprint Review?

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óżne nazwy. Czasem jest to faktyczny zarząd firmy, w innych organizacjach 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 danej 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?

  • Wybierz właściwy moment na zaproszenie
  • Zadbaj o to, żeby zarządzający wiedzieli, czym jest Przegląd Sprintu
  • Przygotuj ich, na to, co zobaczą na Przeglądzie Sprintu
  • Dopasuj prezentację do odbiorcy
  • Zaangażuj zarządzających w spotkanie
  • Prezentacje prowadź od ogółu do szczegółu
  • Pokaż rezultaty i efekty, a nie to, ile włożone zostało wysiłku
  • Pokaż dalsze plany

Poniżej rozwijamy bardziej szczegółowo powyższe punkty.

1. Wybierz właściwy moment na zaproszenie

Kontekst tego, co aktualnie robi Twój zespół, ma ogromne znaczenie, jeśli chodzi o zapraszanie zarządu na Przegląd Sprintu. Nie zawsze jest sens to robić. Przykładowo, jeżeli zespół dopiero zaczyna pracę i nie ma jeszcze nic konkretnego do pokazania, to osoba z zarządu nie będzie miała się do czego odnieść. Jej obecność może być stratą czasu i okazji. 

Dlatego osoby z zarządu warto zapraszać na Sprint Review, gdy faktycznie masz już coś wyprodukowane. Będziecie razem mogli o tym podyskutować oraz otrzymać wartościową informację zwrotną. 

Z drugiej strony, nie ulegaj ze swoim zespołem 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, może mieć problem ze zrozumieniem swojej roli na Sprint Review. Może tak być zwłaszcza w sytuacji, gdy agile jest dopiero wdrażany do organizacji. W takiej sytuacji osoba zarządzająca 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 klasycznych spotkań zarządczych. Dlatego, aby osoby z zarządu mogły czuć się komfortowo, przekaż 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 oczekujesz. Wskaż wprost jakie interakcje są wskazane i czego lepiej, aby nie robili. Być może unikniesz nieprzyjemnej sytuacji utrudniania przebiegu przeglądu przez nawyki zarządzających z innego typu spotkań

Przegląd Sprintu jest spotkaniem innym niż stereotypowe spotkania zarządu, dlatego warto przygotować „gościa”, na to czego może się spodziewać. Zanim taka osoba zostanie zaproszona, odpowiedz sobie na te pytania:

Czego oczekujemy od udziału takiej zaproszonej osoby?
Po co chcemy, żeby ta osoba uczestniczyła?
Czego się spodziewamy od jej udziału i jakie interakcje są wskazane?

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 pokazuje niedokończony jeszcze produkt. Osoby z zewnątrz powinny mieć świadomość tego, że np. nie będzie zawierał wszystkich funkcji. Będą oglądać pewien etap jego rozwoju i będzie to produkt niedoskonały, z pewnością niepełny. Dodatkowo może w czasie prezentacji pojawić się niespodziewany błąd jakościowy albo może się ujawnić się błąd komunikacyjny.

Aby otrzymać właściwą informację zwrotną i uniknąć błędnego wrażenia o jakości pracy zespołu, przygotuj 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ć podejścia bardziej dopasowanego do ich potrzeb. 

Przykładowo, zarządzający niekoniecznie muszą znać koncepcję wytwarzania oprogramowania. W związku z tym sformułowania, którymi zespoły zwinne posługują się na co dzień, mogą być dla nich obce i niezrozumiałe. To może wywołać w nich negatywne emocje. Mało kto lubi czuć się niekompetentny, kiedy oczekuje się od niego informacji zwrotnej lub komentarzy czy pytań.

Dlatego warto zadbać o wyjaśnienie technicznych pojęć, których najczęściej nie da się uniknąć. Pomyśl też jak trudne koncepcje techniczne przedstawić bardziej opisowym językiem. Jednocześnie pamiętaj również o zwięzłości wypowiedzi. Zarządzający zwykle dysponują małą ilością czasu i schodzenie na duży poziom szczegółu z wieloma wątkami pobocznymi może nadmiernie wydłużyć spotkanie. Z tego powodu możesz nie otrzymać tego, po co ich zapraszasz na Review. Nim dojdzie do dyskusji, osoby z zarządu opuszczą spotkanie, aby zdążyć na kolejne, jakie mają w swoim obłożonym kalendarzu.

Pamiętaj także o dopasowaniu prezentacji z perspektywy technicznej. Zachęć zespół do tego, by odpuścić szczegóły rozwiązania od strony systemowej (np. pokazywanie całego back-endu czy struktury bazy). Taki poziom rozwiązania najczęściej 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. Możesz to uzyskać na przykład poprzez zadawanie odpowiednich pytań, które przygotujesz sobie wcześniej. 

Z drugiej strony zachęcaj zarząd do zadawania pytań z ich strony, bo mogą one zapoczątkować ciekawe dyskusje. Niektórych tematów sami (z perspektywy zespołu) 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 osoba prowadząca spotkanie musi być uważna. Jeśli rozmowa zbytnio się rozwleka lub uczestnicy za bardzo zagłębiają się w detale, reaguj odpowiednio do sytuacji. Na przykład parkuj tematy i zapisuj je na listę tematów wymagających dodatkowej dyskusji.

Nie bój się też bezpośrednio wywoływać do wypowiedzi, jeśli osoby z zarządu nie wchodzą w dyskusję z własnej inicjatywy. Może być tak, że wybrane osoby nie wiedzą, kiedy jest właściwy moment, gdy mogą zareagować i poruszyć interesujące ich kwestie.

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

Jeśli Zarząd jest obecny na spotkaniach tylko okazjonalnie, to ważne jest, aby zacząć prezentację od najbardziej ogólnego poziomu. Może to być przywołanie zdefiniowanego Celu Produktu i przedstawienia etapu, na którym jest w danej chwili zespół. Możesz też przypomnieć Cel Sprintu, jaki zespół podjął ostatnio. To lepiej pozwala zrozumieć kontekst, w jakim odbywa się całe spotkanie. 

Osoby, które są obecne na każdym Przeglądzie Sprintu, będą miały poczucie kontynuacji i całego tła tworzenia produktu. Interesariusze uczestniczący w wybranych spotkaniach tylko od czasu do czasu, tego kontekstu już nie mają. Bez dania im jakiegokolwiek wstępu mogą nie rozumieć, co się dzieje. To z kolei pociąga za sobą ryzyko, że feedback, jaki otrzyma twój zespół, nie będzie trafny. Na przykład może będzie dotyczył kolejnych etapów projektu, które są dopiero przed Wami.

7. Pokaż rezultaty i efekty, a nie to, ile włożone zostało wysiłku

Zarządu nie interesuje to, ile zespół się napracował, tylko to, co jest zrealizowane i jakie to da efekty. 

Spotykamy się w swojej praktyce konsultantów z sytuacją, gdzie dużą część Przeglądu Sprintu zajmuje pokazywanie błędów, które zostały usunięte. Często pokazywane są też bardzo szczegółowe zmiany w produkcie, które mogą być istotne z perspektywy zespołu. W rzeczywistości całego produktu czy całej firmy to kropelka w morzu, dobranie zbyt drobnego przybliżenia dla całości obrazu. 

Aby osoby z zarządu miały poczucie, że warto pojawiać się na Przeglądach Sprintu, mocniej akcentuj korzyści biznesowe, jakie uzyskuje zespół.

8. Pokaż dalsze plany

Częścią dobrze zorganizowanego Sprint Review z udziałem zarządzających jest przedstawienie kolejnych rezultatów, jakie zespół chce uzyskać w następnych iteracjach. 

Niech to będzie coś więcej niż tylko kolejny Cel Sprintu czy dwa nowe feature’y, które zespół doda do produktu. Pokaż perspektywę paru kroków w przód, zwłaszcza jeśli można założyć, że osoby z zarządu pojawiają się dopiero za kilka przeglądów. Powiedz, jaki jest Cel Produktu, gdzie zespół znajduje się w jego realizacji. Przywołaj czego można się spodziewać, gdy ten Cel będzie już zrealizowany. Pokaż najistotniejszy fragment Backlogu Produktu.

Możecie też wspólnie (zespół i Zarządzający) rzucić okiem na Roadmapę rozwojową lub założenia projektowe. Być może warto poruszyć temat aktualności ustalonego zakresu lub budżetu przeznaczonego na dany projekt lub etap rozwojowy produktu.

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

Jak dobrze przeprowadzić Sprint Review z udziałem Zarządzających?

  • Uświadom zespołowi plusy z obecności zarządzających
  • Nie organizuj takich wizyt z zaskoczenia
  • Użyj wsparcia sojuszników, żeby zaprosić właściwe osoby
  • Zaakceptuj fakt, że skład spotkań będzie zmienny
  • Rozważ dedykowane spotkanie poza cyklem Sprintowym
  • Skorzystaj z okazji do wskazania potrzebnych usprawnień na poziomie organizacji

Rozwinięcie powyższych rekomendacji w punktach poniżej.

1. Uświadom zespołowi plusy z obecności zarządzających

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 Zespołu dodatkowa szansa na feedback. To też szansa na uzyskanie ważnych podpowiedzi, co do kierunku rozwoju produktu. Mogą też się pojawić ważne informacje na temat planowanych zmian w firmie, które mogą mieć wpływ na ich pracę. 

Nawet jeśli informacja zwrotna, którą uzyskacie jako zespół, 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 najczęściej 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 Sprint Review. To pozwoli się wszystkim oswoić z tą informacją. Może również pozwolić przemyśleć czy takie spotkanie nie będzie dobrą okazją 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

To truizm ale i tak warto to przywołać – 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 Tobie 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/a Product Ownera, który/a będzie umiał/a ze swojego poziomu dobrze uargumentować, dlaczego potrzebna jest obecność osób, na których zależy Tobie i zespołowi. 

Nie wychodź z założenia, że sam fakt, iż Product Owner wysłał zaproszenie, a asystentka prezesa je odrzuciła, to już koniec możliwości działania. Zastanów się, kto może wesprzeć twój zespół w tym temacie i wykorzystaj takie środki.

4. Zaakceptuj fakt, ż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. 

Miej 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ętaj o tym i nie oczekuj, że zawsze będą obecni na Sprint Review twojego Zespołu. Przypominaj też o tym członkom zespołu, jeśli pojawiają się wskazane wyżej pretensje.

5. Rozważ dedykowane spotkanie poza cyklem Sprintowym

Jeśli osoba z zarządu z jakiejś przyczyny nie może pojawić się na Przeglądzie Sprintu, a wszystkim 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 zespół może uzyskać wartościowy feedback od osób z wyższych szczebli organizacji. 

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

Warto rozważyć wykorzystanie spotkania z zarządem do poruszenia wątków związanych z optymalizacją procesów wykraczających poza zespół. 

Przykładem tego może być sytuacja, w której zespół zmaga się z istniejącymi ograniczeniami systemowymi, przez co wybrane elementy produktu są opóźnione. Tego typu tematy przed przywołaniem w gronie wyższych zarządzających warto wcześniej ustrukturyzować i dobrze przemyśleć. Mogą się przydać zarówno argumenty za tym, że potrzebne są zmiany, jak i same propozycje takich zmian. Zadbaj o to, by zespół konkretnie, jasno przekazał swoje potrzeby i pokazał korzyści z zaproponowanych zmian. Przygotuj też członków zespołu na szereg pytań, które mogą się pojawić. 

Bez względu na rezultat takiej dyskusji, zasygnalizuj problem i pokaż, że jako zespół potraficie nie tylko narzekać, ale także szukać rozwiązań. I potrzebujecie pewnych zmian, by uzyskać wyższą efektywność swojej pracy.

Obejrzyj nasze webinary!

Rozbuduj wiedzę, którą przekazujemy w podcastach.
Zobacz nasze materiały premium:

Transkrypcja podcastu „Zarządzający na Przeglądzie Sprintu”

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. Niekiedy występują pod nazwą Leadership Team. Czasem mówimy na nich „headzi”, tak bardzo po staropolsku. A 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 prowadź od ogółu do szczegółu. Zwłaszcza jeśli ten zarządzający pojawił się po raz pierwszy albo pojawia się okazjonalnie. Tu 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? Jak często 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. A 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 Review, 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 naszych 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

← Older
Newer →

One Reply to “Zarządzający na Przeglądzie Sprintu”

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *

Wordpress Social Share Plugin powered by Ultimatelysocial