Scrum istnieje od ponad 25 lat jako prosta struktura efektywnej współpracy zespołowej nad złożonymi produktami. Choć jest lekki i łatwy do zrozumienia, może być trudny do skutecznego zastosowania. Seria Zapytaj Profesjonalnego Trenera Scrum na Scrum.org prezentuje Profesjonalnych Trenerów Scrum (PST) w sesjach na żywo, odpowiadających na najistotniejsze pytania dotyczące wyzwań i sytuacji, przed którymi stoją zespoły Scrum.
W tej sesji Zapytaj Profesjonalnego Trenera Scrum, Joanna Płaskonka i Magdalena Kucharska odpowiedziały na pytania dotyczące Scrum Mastera, estymacji, historyjek użytkownika, miar, wydarzeń Scrumowych i nie tylko!
Transkrypcja
Lindsay Velecina 0:03
Witajcie w podcaście społeczności Scrum.org, podcaście prosto ze świata Scruma. W naszym podcaście profesjonalni trenerzy Scrumowi oraz inni eksperci Scruma, dzielą się swoimi historiami i doświadczeniami, abyście mogli uczyć się na przykładach innych.
Ten odcinek to zapis jednego z naszych na żywo spotkań z cyklu "Zapytaj profesjonalnego trenera Scrum", podczas którego publiczność miała okazję zadawać pytania doświadczonym trenerom Scruma. Mamy nadzieję, że ten odcinek przypadnie Wam do gustu. Dzień dobry! Dobry wieczór! Dziękujemy, że dziś do nas dołączyliście. Zapraszamy na dzisiejsze spotkanie z cyklu "Zadaj pytanie profesjonalnemu trenerowi Scruma". Nazywam się Lindsay Velocina i dzisiaj, reprezentując Scrum.org, będę waszym moderatorem. Na dzisiejszym spotkaniu towarzyszą mi dwie Profesjonalne Trenerki Scruma (PST) – Joanna Płaskonka i Magdalena Kucharska. Serdecznie witam! Obydwie panie pochodzą z Polski. Oto kilka szybkich wskazówek na start
Mikrofon będzie wyciszony przez cały czas trwania spotkania. Jednakże, ponieważ spotkanie ma charakter sesji pytań i odpowiedzi, bardzo liczymy na Waszą aktywność i pytania. Dlatego zachęcamy do korzystania z dedykowanego okna do pytań i odpowiedzi, które znajdziecie w prawym dolnym rogu Waszego ekranu. To tam możecie wpisywać wszystkie swoje pytania i wątpliwości. Jeśli natomiast napotkacie jakieś problemy techniczne, prosimy o używanie funkcji czatu. Ale proszę, nie zadawajcie tam pytań do Magdy – w takim przypadku użyjcie wspomnianego już okna pytań. Spotkanie będzie zapisywane i udostępnione jako podcast w ciągu 24 godzin, więc spodziewajcie się powiadomienia e-mail.
Zacznijmy od kilku słów o scrum.org – to my jesteśmy domem Scruma, założonym przez Kena Schwabera w 2009 roku. Naszym zadaniem jest pomoc osobom i zespołom w pokonywaniu złożonych wyzwań. Oferujemy kursy, certyfikacje oraz możliwości ciągłego doskonalenia się w obszarze profesjonalnego Scruma. Ten webinar to część naszej edukacyjnej oferty i serdecznie zachęcamy do korzystania z wielu dostępnych za darmo materiałów na naszej stronie internetowej.
A teraz oddaję głos Magdzie i Joannie, które się przedstawią i rozpoczną sesję.
Magdalena Kucharska 2:15
Bardzo dziękuję, Lindsay. Witam serdecznie. Nazywam się Magda Kucharska. Jak wspomniała Lindsay, obecnie zamieszkuję w Polsce. Jestem Professional Scrum Trainerem od niecałego roku. Przed tym doświadczeniem, przez ponad 10 lat pracowałam w różnorodnych branżach, takich jak bankowość, hazard, IT, czy lotnictwo - naprawdę szeroki zakres sektorów. Mam nadzieję, że moje doświadczenie będzie pomocne w dzisiejszym udzielaniu odpowiedzi na wasze pytania.
Joanna Płaskonka 2:46
Dziękuję.Nazywam się Joanna Płaskonka, pewnie już wiecie, że również mieszkam w Polsce. Jestem związana z PST od około dwóch lat. Moje wykształcenie to inżynieria, a na początku mojej kariery zajmowałam się zarządzaniem i konfiguracją oprogramowania. Dość szybko zainteresowałam się Scrumem i Agile, starając się wydobyć z nich to, co najlepsze. Większość mojej zawodowej ścieżki to rola trenera Scruma, wsparcie dla organizacji w różnorodnych sektorach - od bankowości, przez software house'y, po firmy oferujące oprogramowanie jako usługę. Miałam również okazję pracować w startupie z branży robotyki, co wiąże się z moim wykształceniem, ponieważ jestem inżynierem. Specjalizuję się w robotyce i inżynierii sterowania.
Lindsay Velecina
Świetnie, że jesteście z nami. Czas więc na pytania. Dziękuję za przedstawienie. Dla tych, którzy właśnie dołączyli, przypominam: proszę korzystać z funkcji pytań i odpowiedzi, którą znajdziecie na dole ekranu. Nie wahajcie się zadawać swoich pytań.
Oto pierwsze pytanie. Czy programiści mogą samodzielnie usuwać i dodawać elementy do Backlogu Sprintu w trakcie sprintu?
Joanna Płaskonka 4:32
To rzeczywiście ciekawe pytanie. Rozumiem, że mówiąc o "elementach", odnosisz się do elementów Backlogu Sprintu, tak? Ogólnie rzecz biorąc, podzielam to podejście. Mówiąc wprost, Backlog Sprintu w Scrumie nie jest postrzegany jako zobowiązanie absolutne. Jest to raczej nasza prognoza, krótkoterminowy plan działania, mający na celu dodanie wartości do produktu. Dlatego, jeśli programiści nie zmieniają Celu Sprintu i ich działania nadal są zgodne z jego realizacją, modyfikacja elementów Backlogu Sprintu jest dopuszczalna. Niemniej jednak, z punktu widzenia przejrzystości, która jest jednym z filarów Scruma, uważam, że warto omówić wszelkie zmiany w Backlogu Sprintu z Właścicielem Produktu. To kwestia współpracy w zespole. Jeśli przedstawisz Właścicielowi Produktu, że jest to najlepsza ścieżka działania, jestem pewna, że wyrazi na to zgodę.
Magdalena Kucharska 5:41
Właśnie, warto dodać, że zwykle, gdy rozważamy dodanie czegoś do Backlogu Sprintu, nasuwa się pytanie, co w zamian powinniśmy z niego wykreślić. Wynika to z faktu, że w trakcie Sprintu możemy zrealizować tylko ograniczoną ilość pracy. Ostatecznie więc wszystko sprowadza się do rozmowy o Celu Sprintu.
Lindsay Velecina 5:59
Dobrze, a teraz kolejne pytanie, które się tu nasuwa. Kto więc decyduje o wydaniu przyrostu?
Magdalena Kucharska 6:05
To Właściciel Produktu decyduje, kiedy i w jakich okolicznościach produkt lub jego część powinna zostać udostępniona klientom. Ważne jest, aby do końca Sprintu mieć gotowy wartościowy i przydatny fragment Produktu. Jednak to, kiedy Właściciel produktu zdecyduje się go wydać, może zależeć od różnych czynników, w tym od sytuacji na rynku. Czasem może okazać się, że lepiej jest dokonywać wydań rzadziej niż po każdym Sprincie. Innym razem natomiast najlepszą strategią będzie jak najszybsze udostępnienie produktu. Decyzja ta zatem zależy od wielu różnych aspektów związanych z rozwojem produktu.
Lindsay Velecina 6:38
Dzięki za to. Przechodzimy do kilku pytań o rolę Scrum Mastera. Macie jakieś rady dla Scrum Mastera, który zaczyna pracować z zespołem, który jeszcze nie jest w pełni zwinny i korzysta z mieszanki Waterfall i Agile?
Magdalena Kucharska 7:01
Nie wpadaj w pułapkę wodospadu. Pamiętam, że kiedy zaczynałam jako Scrum Master, jedną z kluczowych lekcji było obserwowanie mojego zespołu. Spojrzenie na to, nad czym pracują, jakie napotykają trudności, jak wygląda ich komunikacja i współpraca. Czy są w stanie dostarczać kolejne części produktu? Czy istnieją jakieś zależności, które mogą wpływać na pracę? Moim zadaniem było dostrzeganie tych wszystkich aspektów, identyfikowanie problemów, w których mogłam jako Scrum Master pomóc i inicjowanie rozmów na temat naszych procesów. Tak właśnie postępowałam. A ty, Joanno, jakie miałaś doświadczenia na początku swojej ścieżki jako junior scrum master?
Joanna Płaskonka 7:52
Ojej, to było już jakiś czas temu. Gdybym miała wrócić do moich wczesnych dni, radziłabym skupić się na zasadach, ponieważ zgadzam się, że zmiany nie zachodzą z dnia na dzień. Uczenie się jest częścią bycia zwinnym. Ale jeśli chodzi o zasady, każdy Sprint daje szansę na naukę i zarządzanie ryzykiem. Czy wykorzystujecie te możliwości? Czy jest coś, co mogłoby wspierać zespół w tej pracy? Dążymy do tworzenia użytecznych przyrostów w każdym Sprincie. Czy wasz zespół jest w stanie to osiągnąć? Jeśli nie, co byłoby pierwszym krokiem, który moglibyście podjąć jako zespół?
Z perspektywy zasad Scrum, mamy do czynienia z samodzielnie zarządzającym się zespołem profesjonalistów, który jest również wielofunkcyjny. Stąd pojawiają się kolejne pytania. Czy wasz zespół jest naprawdę wielofunkcyjny? Czy dysponuje wszystkimi potrzebnymi umiejętnościami? To może być świetny punkt wyjścia do dyskusji, który pomoże zidentyfikować braki, a nawet może zainicjować dialog z liderami czy decydentami w organizacji na temat tego, co można zrobić, aby naprawdę zaimplementować samozarządzanie i uczynić zespół wielofunkcyjnym.
Magdalena Kucharska 9:19
Pamiętaj również, że pełnisz kluczową rolę – jesteś Scrum Masterem. To oznacza, że czasami musisz zainicjować dyskusję o powodach, dla których odbywają się poszczególne spotkania Scrumowe. Twoim zadaniem jest także edukowanie, nauczanie i rozumienie – dlaczego odbywają się te wydarzenia, jakie są ich cele i oczekiwane rezultaty? Warto też skupić się na zapewnieniu, że każdy w zespole wie, nad czym pracuje. Czy Cel Sprintu jest jasny dla wszystkich? Czy Cele Produktu są zrozumiałe? Czy praca jest transparentna dla zespołu?
Wszystkie te elementy są ważne, ale, jak wspomniała Joanna, zmiana wymaga czasu. Niektóre wprowadzane przez ciebie usprawnienia mogą zająć więcej czasu. Dlatego ważne jest, by iść do przodu małymi krokami, regularnie dokonując inspekcji i adaptacji, oraz utrzymywać ciągłą pętlę informacji zwrotnej. W Scrumie chodzi o empiryzm i ciągłą naukę, by każdy kolejny Sprint był lepszy i by nasz produkt się rozwijał.
Jako Scrum Master, co możesz zrobić, aby to osiągnąć? To pytanie otwarte, zachęcające do refleksji nad własną rolą i możliwościami wpływu na zespół oraz proces pracy.
Lindsay Velecina 10:35
To wspaniale, dziękuję. Ok, mieliśmy jeszcze jedno pytanie dotyczące Scrum Masterów. Megan zadała pytanie: Czy uważasz, że Scrum Master musi posiadać techniczne wykształcenie?
Joanna Płaskonka 10:48
To pytanie bardzo mi się podoba. Brałam udział w podobnych dyskusjach i mogę podzielić się swoją opinią, która nie zmieniła się od kilku lat. Uważam, że nie jest konieczne, aby Scrum Master posiadał głęboką wiedzę techniczną lub specjalistyczną wiedzę z danej dziedziny. Jednak dla mnie kluczową zasadą jest ciągłe uczenie się, co dotyczy nas wszystkich, w tym Scrum Masterów. Najlepsi Scrum Masterowie, z którymi miałem przyjemność pracować, również poświęcali czas na naukę produktu i interesowali się opiniami użytkowników. Kiedy masz otwarte oczy i uszy, kiedy słuchasz i pomagasz w ułatwianiu pracy, ucząc się przy tym, stajesz się lepszym Scrum Masterem. Możliwe, że dziś nie zdajesz sobie sprawy z posiadanej wiedzy. Ale po roku czy dwóch możesz zauważyć, że zgłębiłeś techniczne aspekty. To nie znaczy, że zaczniesz programować czy budować roboty, jeśli waszym produktem jest robot, ale na pewno nauczysz się więcej i staniesz się lepszym członkiem zespołu Scrumowego, bo przecież jako Scrum Master jesteś jego integralną częścią.
Magdalena Kucharska 12:09
Powiem tak, obie świetnie nadajemy się do odpowiedzi na to pytanie. Joanna ma techniczne zaplecze, a ja - nie, ukończyłam studia pedagogiczne, więc moje wykształcenie wiąże się z edukacją, co stanowi zupełnie inną specjalizację. Jednak całkowicie zgadzam się z Joanną, że kluczowe jest poznanie produktu, nad którym pracujecie, i że twoja chęć do nauki rośnie w miarę upływu czasu. Jeśli chcesz lepiej zrozumieć, co się dzieje, możesz stać się bardziej kompetentnym Scrum Masterem. Dodam jeszcze, że kiedy zadasz pytanie Scrum Masterowi, czy potrzebna jest znajomość techniczna, często usłyszysz "tak" od osób technicznych i "nie" od tych nietechnicznych. Tak więc odpowiedź faktycznie zależy od twojej osobistej drogi.
Lindsay Velecina 12:57
Świetnie. Dziękuję. To świetna rada. Wspaniale jest poznać dwa różne doświadczenia w tym temacie.
Magdalena Kucharska 13:05
Możliwe, że da się to zrobić. Spójrz na nas.
Lindsay Velecina 13:11
W porządku, mamy więc różne doświadczenia. Przechodzimy zatem do następnego pytania, dotyczącego roli Scrum Mastera, a potem możemy nieco zmienić temat. Jak więc mogę, jako Scrum Master, zbudować dobrą relację z Właścicielem Produktu, jednocześnie wyznaczając odpowiednie granice między naszymi rolami? Otrzymałam więcej kontekstu odnośnie tej sytuacji, więc pozwólcie, że się nim podzielę:
Przygotowuję się do objęcia nowego zespołu i dowiedziałem się od poprzedniego Scrum Mastera, że w zespole dochodziło do mieszania ról i obowiązków między nim a Właścicielem Produktu. Szczerze mówiąc, chciałbym tego uniknąć. Chcę skupić się na roli Scrum Mastera, w której czuję się kompetentny, nie chcę mieszać ról. Macie jakieś porady dotyczące tego, jak podejść do tej trudnej rozmowy?
Tak naprawdę mamy tutaj dwa pytania. Pierwsze z nich dotyczy budowania dobrych relacji z Właścicielem Produktu, przy jednoczesnym zachowaniu właściwych granic między rolami.
Joanna Płaskonka 14:04
Może zacznę od tego, że polecam uniwersalne narzędzie do dialogu, jakim są umowy robocze. Ale nie myśl o nich tylko w kontekście godzin pracy. To więcej niż to. Możemy w nich umieścić różne kwestie, na przykład jak postępujemy w przypadku konfliktów czy nieporozumień. Co możemy od siebie oczekiwać, kiedy możemy powiedzieć "nie", i że jeśli coś uzgodnimy, to stanowi to naszą wspólną umowę. To warto zrobić. Jest to szczególnie przydatne, gdy tworzy się nowy zespół lub zachodzą w nim zmiany, aby wszystko było jasne, żeby zarządząć oczekiwaniami. Inną sprawdzoną metodą jest bezpośrednia rozmowa z Właścicielem Produktu i zapytanie, jak mogę pomóc, aby nasza współpraca przebiegała płynnie. Moje oczekiwanie jest więc takie, że z perspektywy Scrum Mastera stosuję tu przywództwo służebne i chętnie wysłucham twoich problemów. Jakie wyzwania obecnie stoją przed tobą? Jak mogę ci pomóc? Jak mogę cię wspierać? Jednocześnie, uważam za całkowicie normalne powiedzenie, że nie będę zajmować się zarządzaniem produktem, bo to nie moja specjalność.
Jako Scrum Master jestem ekspertem w dziedzinie Scrum i chcę wykorzystać moją wiedzę, aby wspierać cię najlepiej, jak potrafię. Jeśli czujesz się przytłoczony, być może jest to jedna z hipotez, to moja rola jako Scrum Mastera może polegać na ułatwieniu rozmów o tym, co możemy zrobić jako zespół. Może powinniśmy poprosić innych o wsparcie. Bo prawda jest taka, że zarządzanie produktem to ciężka praca.
Magdalena Kucharska 16:08
Myślę, że kluczowe, by zrozumieć, co za tym stoi. Czyli, kiedy Właściciel Produktu chce, dajmy na to, przekazać pewne uprawnienia czy obowiązki, które leżą w jego zakresie, Scrum Masterowi, trzeba się zastanowić, dlaczego tak się dzieje. Być może jest przytłoczony. A może brakuje mu odpowiedniej wiedzy o zarządzaniu produktem, albo po prostu nauczył się złych praktyk, może przywykł do tego, że ktoś inny wykonuje te zadania za niego. I być może nigdy nie zdawał sobie sprawy, że ma umiejętności, by zająć się tym samodzielnie. Bazując na przykładzie zarządzania Backlogiem Produktu - nie oznacza ono po prostu zmieniania kolejności zadań w JIRA z góry na dół czy od jednej historii użytkownika do innej. To nie takie zarządzanie Backlogiem Produktu, które może być realizowane przez kogokolwiek z zespołu programistów.
Więc problem może tkwić w zagłębianiu się w zbyt wiele detali, na przykład przy zarządzaniu Backlogiem Produktu, być może ktoś nie chce zajmować się zadaniami, które również mogą należeć do programistów. Przypomina mi to sytuację, z którą zetknęliśmy się w jednym z zespołów. Podczas Retrospektywy każdy z nas dostał kartkę papieru podzieloną na dwie części. Jedna część dotyczyła zadań, za które chcielibyśmy być odpowiedzialni w pracy. Druga część miała dotyczyć tego, czego inni oczekują od nas. Każdy z nas wpisywał, za co chciałby odpowiadać i przekazywał swoje myśli reszcie zespołu. Dzięki temu, każdy mógł wyrazić oczekiwania wobec konkretnej osoby, jej roli lub zakresu odpowiedzialności. Na zakończenie retrospektywy dysponowaliśmy pełną listą. Kiedy później przeprowadziliśmy moderowaną dyskusję, udało nam się zdefiniować nasze wspólne rozumienie roli każdego w zespole od tego momentu, ponieważ nawet jeśli tylko jedna nowa osoba dołącza do zespołu, cała dynamika pracy ulega zmianie. Dlatego warto regularnie rewidować „umowę” czy też ustalenia dotyczące zakresu obowiązków i odpowiedzialności każdego z członków zespołu. W moim przypadku to się sprawdziło.
Lindsay Velecina 18:12
To cudowne. Bardzo dziękuję za podzielenie się tym doświadczeniem. Mam nadzieję, że to, co powiedziałaś, okaże się pomocne. Co do następnych kilku pytań, skupione są one głównie na deweloperach i dotyczą metod pracy, narzędzi, estymacji, historyjek użytkownika itf. Oto pytanie od Roberta: jakie metody lub narzędzia stosujesz, aby deweloperzy mogli dzielić duże elementy Backlogu roduktu na mniejsze części?
Magdalena Kucharska 18:49
Szukasz konkretnych nazw narzędzi czy tylko ogólnego podejścia?
Lindsay Velecina 18:55
Może podzielisz się kilkoma podejściami. Jeśli są narzędzia, które polecasz, to też jest w porządku, ale skupmy się na podejściu. Robert, jeśli nie jest to zgodne z twoim pytaniem, daj mi znać na czacie.
Magdalena Kucharska 19:13
To, co robię podczas pracy z developerami, to traktowanie podziału elementów jako zadania dla całego Zespołu Scrumowego. Nie ograniczałabym tego wyłącznie do programistów, ponieważ Właściciel Produktu również ma świadomość końcowej wartości, którą chcemy dostarczyć. To jeden z aspektów, dotyczące estymacji, ale na ten moment nie będę tego tematu rozwijać. Skupiam się głównie na dyskusji o wartościach. Czym one są? Koncentrujemy się na pytaniu o wartość – jaka jest najmniejsza rzecz, która dostarcza nam wartość i którą możemy zrealizować w ciągu Sprintu? Zastanawiamy się również, które z zadań, które ukończyliśmy w poprzednim Sprincie, spełnia definicję "Done", ponieważ wiemy, że Przyrost musi spełniać określoną definicję ukończenia, abyśmy mogli go dostarczyć naszemu klientowi. To prowadzi nas do takich narzędzi jak technika "hamburgera". Chodzi o to, że umieszczasz elementy produktu (PBI) w różnych "warstwach" hamburgera, a następnie składasz je w całość, aby ostatecznie coś dostarczyć. To jedna z technik, którą stosuję w swojej pracy.
Joanna Płaskonka 20:16
Bardzo spodobała mi się dyskusja na temat wartości. Zgadzam się z Magdą, że to bardzo ważne pytanie. Również zadaję je całemu zespołowi Scrumowemu, włączając w to Właściciela Produktu - jaką najmniejszą wartość możemy dostarczyć? Pomaga nam to skupić się na tych naprawdę małych elementach, które możemy wykonać w trakcie Sprintu. Aby dowiedzieć się, jak dzielić zadania, korzystam z technik, które być może Właściciel Produktu już zna, albo mogę go ich nauczyć. Bardzo lubię tworzenie map wpływu i mapowanie historii użytkownika. Takie narzędzia pomagają nam zrozumieć podróż klienta, na przykład przez tworzenie person. To świetny sposób, ponieważ pozwala nam kreować różne scenariusze, a następnie dzielić je na mniejsze zadania, które użytkownicy będą wykonywać z naszym produktem. Następnie określamy, jaką małą część możemy zrealizować w tym Sprincie i jaką wartość to przyniesie. Jeśli w rozmowie dużo mówimy o użytkowniku, możemy użyć historyjki użytkownika jako dodatkowego narzędzia. W ten sposób wyrażamy nasze zadania jako historie, opisując, co się stanie i jaką wartość przyniesie to użytkownikom. Myślę, że to podejście działa naprawdę dobrze.
Magdalena Kucharska 21:54
Również z perspektywy deweloperów, pamiętam, jak będąc początkującym Scrum Masterem, wracałam do nich z pytaniem: Co mogę zrobić? Jakie znacie techniki, które pozwolą podzielić historyjki na mniejsze części? Nie tylko same historyjki, ale ogólnie elementy Backlogu Produktu? Wyjaśnili mi o istnieniu techniki zwanej event storming. Dlatego wróciłabym do deweloperów z zapytaniem o event storming, ponieważ dotyczy on podziału pracy z perspektywy architektonicznej. Chodzi tutaj o architekturę systemu, skupiamy się na oprogramowaniu. Zatem musi istnieć jeszcze jakaś metoda, której warto poszukać.
Joanna Płaskonka 22:33
Widziałam pytanie dotyczące person. Dziękuję za nie. Zawsze, gdy poruszamy temat czegoś nowego dla was, proszę, dajcie nam znać, co o tym myślicie. Odnośnie person, to są one rodzajem reprezentacji naszych użytkowników. Pozwalają zespołowi na lepsze zrozumienie i empatyzowanie z potencjalnymi użytkownikami, których przedstawiają. W moich zespołach zazwyczaj nadajemy im imiona, tworzymy dla nich wizualizacje, czyli jakieś zdjęcia. Zapisujemy ich problemy, punkty bólu, zachowania. Dzięki temu możemy lepiej dostosować naszą pracę do potrzeb konkretnego użytkownika. Skupiamy się na tym, aby nasze działania pomagały tej właśnie osobie, reprezentującej grupę naszych użytkowników, w rozwiązaniu ich problemów. To sprawia, że gdy piszemy kod, organizujemy spotkania, nie myślimy już tylko o tworzeniu produktu. Zamiast tego możemy sobie wyobrazić, że gdzieś tam jest osoba taka jak Jessica, dla której nasza praca ma ogromne znaczenie, bo staramy się uczynić jej życie lepszym. Persony mogą służyć również jako narzędzie motywacyjne, ponieważ to, co robimy, nie sprowadza się tylko do pracy. To pomoc dla kogoś, kto gdzieś na świecie zmaga się z problemami, a prawdopodobnie takich osób jest więcej. Dlatego tworzymy persony, aby reprezentowały naszą grupę docelową.
Lindsay Velecina 24:22
Tak. Super. Dziękuję. Więc kolejne pytanie. Ta osoba zadała trochę inne pytanie dotyczące estymacji. Czy estymacja obejmuje zarówno pracę QA (kontroli jakości), jak i pracę programistyczną? Czy wskazuje, że zespoły nie są wielofunkcyjne? Jakie są wasze przemyślenia na ten temat? Może macie jakieś rady, jak zbudować wielofunkcyjny zespół?
Magdalena Kucharska 24:53
Ogólnie rzecz biorąc, chodzi o to, że kiedy estymujemy coś w naszym backlogu, powinniśmy estymować wszystko albo nic. Estymowanie tylko niektórych zadań, a pomijanie innych, nie daje nam kompletnego obrazu. Brak pełnych danych uniemożliwia nam podejmowanie świadomych decyzji czy prognozowanie przyszłości naszych produktów, ponieważ dysponujemy niekompletnymi informacjami. Dlatego, jeśli dokonujemy szacunków w naszym zespole, oceniamy całą pracę i robimy to wspólnie jako zespół, aby uzyskać pełne zrozumienie sytuacji. Może to być wyzwanie na początku, pamiętam, jak sama uczyłam estymacji. Najwięcej obaw mieli testerzy, twierdząc, że nie chcą estymować, bo nie rozumieją kodu. Przeprowadziliśmy obszerną dyskusję na temat tego, do jakiego stopnia muszą rozumieć pracę, by móc dokonać odpowiednich szacunków. Zajęło nam to trochę czasu, nie zostało to załatwione w jednej sesji, lecz wymagało kilku spotkań i udoskonaleń, aby wnikliwie przeanalizować nasze elementy Backlogu Produktu i osiągnąć wspólne zrozumienie, które pozwoli ocenić je jako zespół. Więc właśnie o to mi chodzi, wraz z walidacją pracy.
Joanna Płaskonka 26:12
Słyszałam również o problemach związanych z wielofunkcyjnością zespołów. Więc moje pytanie brzmi: jeśli twój zespół nie jest wielofunkcyjny, jak tworzycie Przyrost Produktu? Może to dobry punkt wyjścia, ponieważ jeżeli nie posiadacie wszystkich potrzebnych umiejętności i specjalistycznej wiedzy, jak możecie zapewnić sobie możliwość uczenia się i zbierania informacji zwrotnych w każdym Sprincie? To może być zmiana, ogromna zmiana, a nawet punkt zwrotny w waszym procesie. Zrobienie wszystkiego co możliwe, aby zespół mógł stać się wielofunkcyjny.
I druga część, Magdalena podzieliła się pomysłem, że zamiast estymować niektóre elementy, lepiej estymować wszystko. Ponieważ inaczej możecie przegapić ważne dane i mieć problem z oceną, co jest możliwe, a co nie. Alternatywą jest nie estymacja, lecz używanie danych historycznych. Jest to zgodne z zasadą empiryzmu - uczenia się na podstawie doświadczenia i wniosków z przeszłości, aby podejmować jak najlepsze decyzje na przyszłość. Jeśli więc wykorzystacie. informacje o ilości elementów Backlogu Produktu, które udało się zrealizować w poprzednich Sprintach albo korzystacie z tak zwanych Wskaźników Przepływu, Przewodnik Kanban dla zespołów Scrum może być dla was inspiracją. Czasami nie musimy koncentrować się na podawaniu konkretnych estymacji np. w Story Points, lepiej zadać inne pytania: jakie są ryzyka, nieznane, niejasności? Jaka jest najgorsza rzecz, która może się wydarzyć? Taka rozmowa pozwoli ocenić, w jaki sposób dobrze przygotować Backlog Refinement (Doskonalenie Backlogu) na nadchodzące Sprinty oraz spojrzeć w kierunku historii. Ponieważ dobra wiadomośc jest taka, że to, co już się wydarzyło, jeśli macie przejrzystość w swoim Backlogu, jest prawdą. Wówczas wasze decyzje będą oparte na rzeczywistych danych, na historii, a nie na przewidywaniu przyszłości.
Magdalena Kucharska 28:40
Myślę, że zeszliśmy na temat tego, jakie dane moglibyśmy wykorzystać zamiast miary "velocity" - “prędkości”, ponieważ zazwyczaj Story Points prowadzą nas do "prędkości" na wykresie spalania. Jest to tzw. Vanity Metric (metryka próżności). Daje nam pewien obraz prędkości zespołu, ale nie dostarcza informacji o samym produkcie. Jak zauważyła Joanna, istnieje wiele innych wskaźników, inne dane, które możemy zbierać. Na przykład, moglibyśmy zbierać informacje o satysfakcji klienta, próbować mierzyć czas cyklu realizacji, jakość naszej pracy, jakość pokrycia kodu, którą jesteśmy w stanie zmierzyć, moglibyśmy też zbadać wskaźnik zadowolenia w naszych zespołach, a potem zobaczyć, co z tego wynika. Czyżbyśmy trochę odeszli od początkowego wątku dyskusji?
Lindsay Velecina 29:23
Bez obaw, dziękuję za to. Teraz, zmieniając nieco temat. Mamy sporo pytań, węc jeśli nie odpowiem na twoje pytanie, nie przejmuj się. Podzielę się nimi z Joanną i Magdą, a one znajdą sposób, aby odpowiedzieć. Proszę więc o trochę cierpliwości. A teraz kolejne pytanie. Czy któraś z was miała styczność z pracą w zespołach Scrum, które nie zajmowały się tradycyjnym tworzeniem oprogramowania, ale np. z analizą danych, gdzie dużo wysiłku i pracy ma charakter eksploracyjny i może nie przynosić bezpośrednio dodatkowej wartości na koniec Sprintu? Skupienie się na tworzeniu wartości w takich sytuacjach bywa wyzwaniem.
Joanna Płaskonka 30:14
A może warto zmienić sposób patrzenia na to? To świetne pytanie. Osobiście, kiedy prowadzę moje zajęcia ze Scruma, nie przedstawiam Scruma jako narzędzia, które bezpośrednio pomaga w dostarczaniu lub rozwijaniu produktu. Zamiast tego mówię, że Scrum to narzędzie służące maksymalizacji procesu uczenia się oraz zarządzania ryzykiem. Rozumiem Twoje trudności, ponieważ miałem rozmowę z jednym z liderów, który zauważył, że jego zespół wykonuje dużo pracy – to dotyczyło robotyki. Implementacja nowego algorytmu AI była wyzwaniem. Sztuczna inteligencja nie jest przecież czymś, co pojawiło się wczoraj; studiowałam to już dawno temu. Wprowadzając nowy algorytm, nowe podejście do AI i nowy sprzęt, ryzyko, że coś może pójść nie tak, jest znaczne. Ważne jest, by omówić, co faktycznie udało się zrobić, jakie ryzyka zostały zidentyfikowane i jak zostały one zaadresowane. Na przykład, podczas przeglądu Sprintu zaczęliśmy dyskutować o wartości procesu uczenia się, a dostarczanie i rozwój produktu pojawiły się jako naturalna konsekwencja tego uczenia się i zarządzania ryzykiem. Myślę więc, że w kontekście pracy R&D, ważne jest, by uczynić te aspekty przejrzystymi. Prowadź rozmowy z interesariuszami i pokazuj, co robisz w zakresie uczenia się i łagodzenia ryzyka. To może być zmiana perspektywy, która ułatwi prowadzenie bardziej owocnych dyskusji.
Lindsay Velecina 32:12
O, super. Dziękuję. Rozumiem. Kolejne pytanie dotyczy pracy zdalnej. Pracuję z zespołem zdalnie i napotykam trudności w zachęcaniu programistów do aktywnego udziału w rozmowach podczas Retrospektywy Sprintu i Planowania Sprintu. Czy są jakieś sposoby, aby pobudzić większe zaangażowanie wśród tego zespołu? Próbowałem różnych metod na rozładowanie atmosfery i poruszałem ten temat podczas Retrospektyw, ale niestety żadne z tych działań nie przyniosły większych zmian.
Magdalena Kucharska 32:38
Przepraszam, muszę się uśmiechnąć, rozumiem, przez co przechodzisz, czuję ten ból. Przejdę od razu do pomysłów i rozwiązań, które okazały się skuteczne w moim przypadku, być może równiez Joanna podzieli się swoimi doświadczeniami. Gdy zauważam, że ludzie są niezaangażowani, niezależnie od tego, czy to w kontekście online, czy offline – a problem ten występował już przed erą online, jeśli ludzie nie dostrzegali wartości w danym wydarzeniu. Weźmy na przykład Retrospektywę: jeśli po każdym Sprincie wychodzimy z pomysłami i działaniami, ale nie wdrażamy ich w życie, z czasem zauważamy, że dyskusje nie prowadzą do żadnych zmian w naszej pracy – nie ma inspekcji ani adaptacji, nasza praca nie ulega poprawie, nie uczymy się na błędach.
W takim przypadku samo wydarzenie traci na wartości, nie przynosi nam żadnych konkretnych wyników ani efektów. To, co pomogło moim zespołom, to zapytanie ich: Co możemy zrobić razem, aby to wydarzenie było dla Was bardziej wartościowe? Co musi się stać? Czy jest jakaś konkretna zmiana, która musi nastąpić, aby wydarzenie miało dla Was sens? Mam pewne przeczucia, ale to tylko hipoteza, że być może mamy do czynienia z rodzajem zombie Scrum, gdzie odbywają się wszystkie rytuały, są artefakty i zobowiązania, ale coś nie funkcjonuje. Dlatego warto wrócić do podstaw: po co istnieje każde z tych wydarzeń? Jak one się łączą? Co dzieje się z efektami tych spotkań? Jeśli tworzysz plan i masz cel Sprintu, czy codziennie dyskutujecie o tym celu? Czy regularnie sprawdzacie, jak się do niego zbliżacie? Czy faktycznie osiągacie zamierzone rezultaty dzięki tym wydarzeniom? To byłaby moja sugestia.
Joanna Plaskonka 34:37
To naprawdę świetne pytanie. Dziękuję, Magdo, za podzielenie się tą perspektywą. To jeden z możliwych scenariuszy. Wyobrażam sobie, że niektóre osoby mogą po prostu nie lubić wypowiadania się w większym gronie. Jeśli kiedykolwiek prowadziłeś większe spotkanie, pewnie zauważyłeś, że zwykle aktywnie uczestniczy tylko garść osób, kiedy padają pytania. Dlatego właśnie w zeszłym roku opublikowaliśmy na stronie scrum.org roczny kurs poświęcony temu zagadnieniu. Kluczowym słowem, które Cię powinno zainteresować, jest "facylitacja". Polecam poszukać zasobów na scrum.org związanych z facylitacją, znajdziesz tam mnóstwo użytecznych informacji. Istnieją techniki, które pomogą Ci zwiększyć zaangażowanie uczestników.
Może się jednak okazać, że niektóre osoby nie będą chciały mówić na głos w większej grupie. Ale jeżeli udzielają wartościowych odpowiedzi na piśmie, ich głos jest w ten sposób obecny, i można na tej podstawie wypracować wyniki spotkania. Myślę więc, że ważne jest także okazanie szacunku do tego, że nie wszyscy chcą wypowiadać się publicznie. Dlatego polecam także tę ścieżkę. Chciałabym również podzielić się moim niedawnym doświadczeniem. Prowadziłam grupę 12 świetnych studentów, którzy, kiedy dostawali zadania do wykonania, prezentowali fantastyczne wyniki. Ale kiedy do nich mówiłami, ich wszystkie kamery były wyłączone. Jest to wyzwanie dla prowadzącego, bo brak wizualnych wskazówek utrudnia współpracę. Podczas drugiego dnia szkolenia, jedna ze studentek zadzwoniła wcześniej i zaczęliśmy rozmowę. Powiedziałem jej, jak bardzo żałuję, że nie mogę widzieć jej twarzy. Odpowiedziała, że nie chce być pierwsza. Zachęciłem ją, mówiąc, że może być liderem, może dawać przykład. Ostatecznie włączyła kamerę i pozostała z nią przez resztę szkolenia, co zachęciło innych do zrobienia tego samego. Pokazuje to, że w każdym zespole są różni liderzy, którzy mogą inspirować pozostałych do zmian.
Magdalena Kucharska 37:23
Parafrazując: znajdź osobę, która będzie motorem zmian w twoim zespole, w twojej grupie, kogoś po twojej stronie i próbuj stopniowo, krok po kroku, wprowadzać zmianę.
Joanna Plaskonka 37:35
Mam jeszcze jedną opowieść, którą spróbuję wam zwięźle przedstawić. Istnieje specjalna metoda facylitacji przydatna podczas Retrospektywy Sprintu, zwaną techniką "skrzynki". Używa się fizycznej lub wirtualnej skrzynki, do której wszyscy wrzucają pomysły, które chcieliby omówić. I przy każdym temacie, przy każdym pytaniu, inna osoba przejmuje rolę facylitatora. W ten sposób prosisz swój zespół o aktywny udział nie tylko w dyskusji, ale również w prowadzeniu, co może pomóc zbudować silniejsze poczucie odpowiedzialności za spotkania.
Magdalena Kucharska 38:19
Jeśli chodzi o retrospektywę, chciałabym dodać jeszcze jedną kwestię. Wiele osób błędnie zakłada, że to Scrum Master powinien prowadzić retrospektywę. W rzeczywistości każdy jest w stanie się tym zająć. Rola Scrum Mastera sprowadza się do zapewnienia, że spotkanie się odbywa, przynosi oczekiwane efekty i angażuje wszystkich uczestników. Jednakże, można wprowadzić system rotacyjny, dzięki któremu różne osoby będą pełnić rolę facylitatora. To świetna propozycja, Joanno. Dziękuję.
Lindsay Velecina 38:44
Świetnie, dziękuję. Kolejne pytanie. Czy możecie podzielić się jakimiś wskazówkami na temat formułowania Celów Sprintu? W naszym projekcie zadania często wyglądają jak długa lista rzeczy do wykonania. Czy macie jakieś proste przykłady, które mogłyby pomóc?
Magdalena Kucharska 39:01
Jak przykład dobrego celu sprintu?
Lindsay Velecina 39:03
tak
Magdalena Kucharska 39:10
Oto przykład celu Sprintu: użytkownicy mają możliwość logowania się przez Facebooka na naszej stronie. Jest to zwięzłe, każdy rozumie o co chodzi. Cel jest sformułowany z punktu widzenia użytkownika, jest jasne, jak to osiągnąć. Kiedy myślicie o Celu Sprintu, jako zespół możecie łatwo określić, kiedy zadanie zostanie ukończone. Znacie wpływ, jaki ma ono wywrzeć, i jakie rezultaty chcecie zobaczyć na koniec Sprintu. Wiecie, na co zwracać uwagę. Przy komponowaniu Backlogu Sprintu, wszystko staje się dla wszystkich zrozumiałe i przejrzyste, a wy wiecie, które elementy Backlogu Produktu pomogą w realizacji Celu Sprintu. Pamiętajcie, że nie wszystkie zadania w Backlogu Sprintu muszą być bezpośrednio związane z Celem Sprintu. Może to być jeden element Backlogu Sprintu, może być dziesięć to nie ma znaczenia, byle były one powiązane z celami sprintu, które wy sobie wyznaczyliście. Więc tak w skrócie odpowiadam.
Joanna Plaskonka 40:16
Mam też dłuższą odpowiedź. Kiedy ktoś pyta mnie, czy mogę stworzyć Cel Sprintu? Moja typowa odpowiedź brzmi tak. Ale wiesz co? Czy mógłbyś mi powiedzieć, jak nazywa się twój produkt? A może nawet wcześniej, czy mógłbyś mi powiedzieć, czym jest twój produkt?
Magdalena Kucharska 40:32
Po co to robisz?
Joanna Plaskonka 40:35
Dokładnie, kim jest twój użytkownik? To moja osobista rekomendacja, aby zacząć właśnie od tego. I dodam coś jeszcze. Jaki jest twój produkt? Kim są twoi użytkownicy? Jaki jest cel twojego produktu? A także, jakie jest obecne stadium rozwoju twojego produktu? Może posiadasz więcej niż jeden produkt, być może znajdują się one na różnych etapach rozwoju? Pytam o to, ponieważ Scrum nie jest wszechstronnym rozwiązaniem na wszystkie problemy. Jeśli zajmujesz się tylko pracami konserwacyjnymi, jak ja kiedyś, Scrum nie sprawdził się idealnie. Odczuwaliśmy, że nasza praca nie wymaga tak wielu spotkań. Zamiast tego, skoncentrowaliśmy się na pracy zgodnie z przepływem. Więc może istnieją inne narzędzia, które pomogą ci znaleźć najlepsze możliwe podejście. Jako PST, z Scrumem w nazwie, powiem, że jest w porządku nie używać Scruma, jeśli to nie jest najlepsze narzędzie dla ciebie. Jednakże zauważyłam też trudność w formułowaniu Celu Sprintu, który powinien być mniejszym krokiem w kierunku większego, bardziej elastycznego celu, ale tak jak Magda pokazała na naszym przykładzie, powinien także pomagać zrozumieć, dlaczego to robimy. Jaka jest wartość? To powinno być łatwe do zrozumienia dla wszystkich zaangażowanych. Dlaczego Zespół Scrumowy nad tym pracuje. Więc zacznij od zadawania tych pytań sobie, swojemu zespołowi, swojemu właścicielowi produktu, ponieważ te pytania mogą prowadzić do całkiem interesujących wniosków.
Magdalena Kucharska 42:28
I również w Scrumie, bez jasno określonego celu, prawdopodobnie nie będziecie wiedzieć, do czego dążycie, nie będziecie wiedzieć, co dokładnie inspektować i co dostosowywać na końcu. Wasze codzienne spotkania będą się sprowadzać jedynie do przeglądania JIRA, zadanie po zadaniu, bez konkretnego punktu skupienia. Dlatego tak ważne jest, aby wszyscy mieli wspólne zrozumienie Celu Sprintu jako kroku na drodze do osiągnięcia waszego większego celu produktowego.
Lindsay Velecina 42:55
To świetna porada, dziękuję. Teraz pytanie od Craiga, który chciałbyśmy, abyśmy trochę pogłębili nasze doświadczenia. Czy możecie podzielić się niektórymi z najlepszych lub najbardziej wymagających interakcji, jakie mieliście z liderami i interesariuszami? Craig szuka wskazówek lub specyficznych technik, których używacie, aby interesariusze dostrzegli realny wpływ wdrażanych zmian.
Magdalena Kucharska 43:26
To trudne pytanie. Najgorsza sytuacja.
Joanna Plaskonka 43:36
Mogę zacząć, ponieważ uważam, że każda taka rozmowa jest wyzwaniem ze względu na stres i odpowiedzialność, które odczuwam. Miałam okazję pracować z różnymi liderami, w tym z osobami na stanowiskach C-level. Myślę, że ważne jest, aby zwrócić uwagę na pewne rzeczy. Jeśli korzystasz tylko z, jak to ujmujemy, "ogólników", czyli mówisz, że musimy to zrobić, bo to jest dobre, bo to jest miłe, bo wszyscy mówią, że Scrum jest świetny dla złożonych problemów, to rozmowa może zakończyć się pytaniem: "Dlaczego mi to mówisz? Nie chcę, abyś mnie rozpraszał, mam dużo na głowie". Lepszym podejściem, moim zdaniem, jest zapytać o konkretne problemy, które ich dręczą. Co ich niepokoi? O czym myślą, kiedy zaczynają pracę rano? Jeśli chcesz dobrze współpracować z liderami, przedstaw się jako partner. Dla mnie kluczem było prowadzenie otwartych i szanujących rozmów o problemach, pomaganie liderom w prowadzeniu trudnych dyskusji. Jedną z najtrudniejszych dyskusji, jaką prowadziłam, było spotkanie z CEO, CTO i bardzo wartościowym, doświadczonym deweloperem. Było napięcie, wewnętrzny konflikt. Pomogłam im, korzystając z wartości i zasad Scruma, kierować dyskusję we właściwym kierunku. Starałam się parafrazować to, co mówili, na przykład: "Magdo, czy chciałaś podkreślić, że dbasz o swoją pracę?" "Tak, dokładnie o to mi chodziło." Okazało się, że to był problem komunikacyjny. Pomogło nam to znaleźć właściwe pytania: "Co chcemy osiągnąć? Jaka jest twoja perspektywa?" Byliśmy w stanie prowadzić rozmowę do końca. Choć ostatecznie ten programista zdecydował się opuścić firmę, czułam, że zakończyliśmy na dobrych warunkach, z dużym szacunkiem. To, moim zdaniem, jest esencją Scruma - wartości, zaufanie, szacunek. Mam nadzieję, że to pomoże. Nie skupiaj się na przedstawianiu wspaniałych pomysłów, może zmień perspektywę: "Jak mogę ci pomóc? Jakie masz problemy?" Wykorzystaj swoje umiejętności, aby im pomóc. Budujesz wtedy partnerstwo. I wtedy mogą cię zapytać: "Moniko, jak mogę ci pomóc? Czy ty też masz jakieś wyzwania?" I oto otwiera się droga do świetnych rozmów z kluczowymi decydentami w firmie.
Magdalena Kucharska 46:54
Co również sprawdza się u mnie podczas rozmów z menedżerami i liderami, to zadawanie pytania, dlaczego na samym początku zdecydowaliście się na wprowadzenie podejścia zwinnego lub Scruma. Jakie problemy staraliście się rozwiązać? Jeśli waszym wyzwaniem był na przykład czas dostaw, chcieliście go skrócić lub poprawić coś innego dla waszych klientów, to właśnie na tym powinniśmy się skupić i budować wokół tego nasze cele - Cele Produktu lub Cele Sprintów. Ale nie można za jednym razem rozwiązać wszystkich problemów. Bo jeśli wszystko jest ważne, to tak naprawdę nic nie jest ważne, prawda? Więc warto wrócić do pierwotnych przyczyn, dla których zdecydowaliście się na ten krok. Co więcej, pomocna okazuje się być jedna z ostatnich zasad w Przewodniku Scruma, mówiąca, że choć możesz stosować niektóre elementy Scruma, aby w pełni wykorzystać moc inspekcji, adaptacji i przejrzystości, musisz przyjąć Scrum w całości. Możesz mieć wydarzenia, artefakty i zobowiązania, ale jeśli zrezygnujesz z któregokolwiek z nich, nie osiągniesz oczekiwanej wartości. Jeśli więc chcesz tej wartości, musisz zastosować się do całości i uczyć się na bieżąco. To jest istota empiryzmu. To naprawdę pomaga.
Inną kwestią, którą często poruszam, jest budżet, pieniądze, bo przecież celem firmy jest dostarczanie klientom tego, czego potrzebują i chcą, a także generowanie zysku. Więc jeśli podejmujecie jakieś działania, zastanówcie się, jak wpłyną one na zysk waszego produktu. Jeśli na przykład decydujecie się na mikrozarządzanie swoim zespołem, zajmuje wam to dużo czasu, który można by wykorzystać na bardziej wartościowe działania dla firmy i produktu, niż na mikrozarządzanie. Jeśli zauważycie jakieś działania, takie jak mikrozarządzanie, które mogą zakłócać pracę zespołu Scrumowego, spróbujcie również zrozumieć przyczyny takiego zachowania. Może jest jakiś mały krok, który możecie podjąć. Istnieje narzędzie zwane "Delegation Poker", które pokazuje, że istnieje więcej niż jeden poziom delegowania obowiązków. Są to różne poziomy delegacji, i przejście od pełnej kontroli do większej swobody może być znaczącym krokiem. Radziłabym więc przyjrzeć się temu narzędziu. Narzędzie "poker delegacji" może być przydatne do prowadzenia dyskusji z waszym menedżerem na temat tego, jakie obowiązki jest gotowy/a przekazać.
Joanna Plaskonka 49:53
Tak, ponownie wracamy do jednego z fundamentów, jakim są wartości oparte na zaufaniu. Możesz skorzystać z pokera delegacji, by poruszyć temat zaufania, bo bez niego trudno wyobrazić sobie, aby profesjonalne stosowanie Scruma przynosiło oczekiwane rezultaty.
Lindsay Velecina 50:15
Dziękuję wam obu za to, naprawdę świetna sprawa. Więc teraz kolejne pytanie. Zarząd uważa, że Przegląd Sprintu trwa za długo. Spotkanie zajmuje dwie godziny, podczas których prezentujemy demo, pokazujemy, co udało się osiągnąć i dyskutujemy o tym, co będzie dalej. Jest pięć zespołów, które dokonują przeglądu, inspekcji i dostosowań. A w tych dwóch godzinach, każda informacja zwrotna jest ograniczana do zaledwie 30 sekund, więc ludzie nie mają możliwości dostarczenia pełnej informacji zwrotnej. Co możemy zrobić, aby to zmienić?
Magdalena Kucharska 50:50
Spróbuję odpowiedzieć, choć brakuje mi nieco szczegółów. Ważne jest, aby wiedzieć, czy te zespoły pracują nad tym samym produktem. To kluczowa kwestia, ponieważ jeśli tak jest, to zespoły nie powinny prezentować swojej pracy oddzielnie. Skoro pracują nad jednym produktem, całość ich pracy, ich przyrosty, tworzą łączny przyrost produktu. W takim przypadku powinni omawiać i zbierać informacje zwrotne wspólnie, wokół jednego przyrostu, a nie indywidualnie. Jeśli jednak te pięć zespołów pracuje nad różnymi projektami, prawdopodobnie mają różnych interesariuszy i różne cele. Wtedy zbieranie się wszystkich razem na jednym spotkaniu nie ma sensu, bo nie każdy będzie zainteresowany każdą prezentacją.
Dodatkowo, jeśli interesariusze uważają, że spotkanie trwa zbyt długo, to może to wskazywać na problem z dostrzeganiem wartości. Trzeba zastanowić się, czy spotkanie przynosi im wartość, czego potrzebują, jakich informacji szukają, jakiego rodzaju informacje zwrotne są dla nich ważne. Czy interesariusze wiedzą, jaki jest cel tego spotkania? Może przed Przeglądem Sprintu warto zorganizować rozmowę między Scrum Masterem a Product Ownerem, aby określić, co jest dla nich ważne.
Kiedy mam kilka zespołów pracujących nad różnymi aspektami szerokiego produktu, każdy skierowany do innej grupy docelowej, na każdym Przeglądzie Sprintu dostarczamy agendę, podkreślając, nad którymi elementami pracowaliśmy w ostatnim czasie. Zapraszamy tylko te osoby, które są zainteresowane danym tematem i mogą dostarczyć wartościowe informacje zwrotne. W końcu Przegląd Sprintu to sesja zbierania informacji zwrotnych, co umożliwia inspekcję i dostosowanie działań w kierunku rozwoju produktu.
Jeśli używacie słowa "demo", a spotkanie ma formę prezentacji bez interakcji, uczestnicy mogą czuć się niezaangażowani. Jeżeli jest to produkt software'owy, pozwólcie im samodzielnie go przetestować. Zaangażowanie poprzez interakcję może znacznie poprawić jakość i użyteczność informacji zwrotnych.
Przepraszam, miała to być krótka odpowiedź, ale trochę się rozwinęła. Joanna, teraz Twoja kolej.
Joanna Plaskonka 53:21
Powiedziałaś już wiele wartościowych rzeczy, Magda. Dziękuję za to. Jednym z najlepszych Przeglądów Sprintu, jakie miałam okazję obserwować, nie była typowa prezentacja. Warto pamiętać, że Scrum wcale nie mówi o demo jako takim. Chodzi bardziej o pokazanie działającego produktu, pracę nad przyrostem i inspekcję tego, co udało się osiągnąć. Najlepsze sesje, jakie widziałam, to te, podczas których CEO samodzielnie siedział przed laptopem i korzystał z produktu. Widok potencjalnego użytkownika testującego produkt na własne oczy był dla wszystkich ogromnym zaskoczeniem. To była naprawdę wartościowa sesja współpracy i zbierania informacji zwrotnych.
Warto też pamiętać, że informacja zwrotna to nie tylko słowa. Jak pokazują badania, rozmowa to tylko część procesu. Najważniejsze jest zrozumienie, w jaki sposób ludzie rzeczywiście używają twojego produktu. To kluczowy element informacji zwrotnej w Przeglądzie Sprintu.
Tak jak Magda wspomniała, warto zastanowić się, co można zmienić, aby interesariusze odczuli większą wartość z tych spotkań. W jednej z moich sytuacji wprowadziliśmy regularne, krótkie ankiety informacji zwrotnej, zachęcając do wprowadzania zmian i wyrażania opinii. Podczas każdego Przeglądu Sprintu dokonywaliśmy drobnych korekt, a różnica między pierwszym a ostatnim Przeglądem była zaskakująca. Drobne, regularne zmiany, inspekcje i czasami kroki wstecz, aby móc pójść do przodu, robią ogromną różnicę.
Jeśli macie portfel produktów, nie uważam, aby dwugodzinna sesja była czymś złym, to raczej kwestia tego, jak dobrze ją zorganizować. Istnieją różne techniki na Przegląd Sprintu, które można wykorzystać. Można na przykład użyć pokoi dyskusyjnych z określonymi tematami do omówienia. Moje zespoły również wysyłają do wszystkich interesariuszy oficjalne informacje po Planowaniu Sprintu, określając Cel Sprintu. To bardzo bezpośredni sposób komunikacji naszych zobowiązań i celów. Więc oczekujcie wartości właśnie w kontekście tych celów.
Magdalena Kucharska 56:13
Pamiętajcie, że mówiąc o interesariuszach, mamy na uwadze również klientów czy nowych użytkowników. Czasami bowiem w firmach za interesariuszy uznaje się osoby wewnątrz organizacji, takie jak menedżerowie projektów czy dyrektorzy, którzy nigdy faktycznie nie korzystają z waszego produktu. Przegląd Sprintu ma także na celu zdobycie informacji zwrotnych od waszych klientów i użytkowników. Kiedy pracowaliśmy w branży medycznej, po prostu zabieraliśmy nasze laptopy i udawaliśmy się do poczekalni, prosząc pacjentów czekających na wizyty, aby przetestowali nasz nowy system. I muszę powiedzieć, reakcje programistów były bezcenne, wyrażały coś w stylu: "O nie, tam nie klikaj!". Jednak dla pacjentów te działania były intuicyjne, choć niekoniecznie zgadzały się z tym, jak programiści przewidzieli użycie systemu. To była jedna z najlepszych form informacji zwrotnej, jaką uzyskaliśmy - poprzez poproszenie przypadkowych pacjentów w ośrodku medycznym o interakcję z naszym produktem.
Lindsay Velecina 57:03
Fantastyczna dyskusja dzisiaj. Bardzo dziękuję wam obu. Niestety, nasz czas dobiega końca. Ta godzina niesamowicie szybko minęła, a przed nami jeszcze wiele nierozwiązanych pytań. Jak już wspomniałem, przekażę te pytania Joannie i Magdzie i będziemy wspólnie szukać sposobów na odpowiedzenie na pozostałe kwestie. Organizujemy takie sesje około raz w miesiącu, więc proszę śledzić nasze spotkania. Pragnę przypomnieć, że na stronie scrum.org znajdziecie ścieżki uczenia się i wiele bezpłatnych materiałów, więc zachęcam do korzystania z tych zasobów. Nasze webinary również są wymienione na stronie. Zachęcam do utrzymywania kontaktu zarówno ze mną, jak i z Janą oraz Magdą. Magdo i Joanno, jeśli chcecie podzielić się z publicznością informacjami, jak najlepiej się z wami skontaktować, byłoby fantastycznie.
Magdalena Kucharska 57:54
Tak, dziękuję bardzo. Dzięki, Lindsay. Dziękuję wszystkim za aktywny udział i za wszystkie pytania. Wydaje mi się, że moglibyśmy tak dyskutować dzień albo i dwa bez przerwy. Najłatwiejszą drogą, by się ze mną skontaktować, jest poprzez LinkedIn, więc serdecznie zachęcam do nawiązania ze mną tam kontaktu. Widzę, że Joanna również się zgadza, więc LinkedIn wydaje się być najlepszym sposobem, aby nawiązać z nami kontakt. Co się tyczy pytań, postaramy się opublikować na nie odpowiedzi w serii wpisów na blogu na stronie Scrum.org. Tak więc wasze pytania na pewno nie zostaną zapomniane i będziecie mieli możliwość zapoznania się z nimi w dowolnym momencie.
Lindsay Velecina 58:26
Brzmi fantastycznie. Bardzo dziękuję wam obu za podzielenie się dzisiaj swoimi doświadczeniami i za pomoc naszej publiczności w rozwiązaniu ich wątpliwości. Wasz wkład był niezmiernie cenny. To była naprawdę świetna sesja i mam nadzieję, że wszyscy miło spędziliście czas. Kontynuujcie scrumowanie.
Joanna Plaskonka 58:41
Bardzo mi się podobało. To było wspaniałe doświadczenie. Dziękuję Wam, Panowie. Ale przede wszystkim, ogromne podziękowania dla wszystkich uczestników za poświęcony czas, bo czasem jest to jedna z najcenniejszych rzeczy, jakie posiadamy – nasz czas, a Wy zdecydowaliście się spędzić go dzisiaj z nami. Szczególnie to doceniam.
Lindsay Velecina 58:59
Dziękuję wszystkim. Trzymajcie się.
