#060 – Efektywność Zespołu Scrumowego

35:57
 
Udostępnij
 

Manage episode 289363582 series 2440361
Stworzone przez Porządny Agile, odkryte przez Player FM i naszą społeczność - prawa autorskie są własnością wydawcy, a nie Player FM, a dzwięk jest przesyłany bezpośrednio z ich serwerów. Naciśnij przycisk Subskrybuj, aby śledzić aktualizacje Player FM, lub wklej adres URL kanału do innych aplikacji podcastowych.

Jak poprawiać efektywność Zespołu Scrumowego? Temat do rozmowy podsunęła nam nasza słuchaczka Karolina, wielkie dzięki! Dowiesz się, jak my rozumiemy efektywność i czym ona jest. Mamy kilka sprawdzonych porad, które pomogą Ci na nią wpłynąć. Dorzucamy do tego jeszcze różne, konkretne praktyki, aby temat efektywność zamknąć kompleksowo.

Zobacz wersję wideo:

Dyskusje o efektywności Zespołu Scrumowego.

O czym usłyszysz w odcinku?

  • 01:48 – Definicja efektywności
  • 05:20 – Ustal, po co robisz dany element Backlogu Produktu
  • 08:08 – Czego Scrum Master nie powinien robić w procesie Refinementu
  • 11:15 – Dekompozycja Backlogu Produktu
  • 14:11 – Dążenie do realizacji konkretnego celu produktu
  • 17:45 – Stosowanie nawykowo miar produktowych na Review Sprintu i porządkowanie Backlogu Produktu
  • 20:27 – Skupienie się na zmniejszaniu odległości developerów od Użytkownika
  • 24:30 – Bazowanie na faktycznej zespołowości
  • 28:13 – Częste dokonywanie refleksji
  • 31:27 – Polecane praktyki i techniki wzmacniające efektywność

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

Daj nam znać co sądzisz o tym odcinku

TRANSKRYPCJA

Kuba: W dzisiejszym odcinku opowiemy o efektywności Zespołu Scrumowego. Temat zaproponowała Karolina w odpowiedzi na nasz newsletter. Dzięki Karolina za całą listę propozycji. Spośród nich wybraliśmy to konkretne pytanie, czy tę konkretną propozycję. Pozwól, że przeczytam całą treść tego pytania, bo tutaj jest ważny smaczek. Pytanie brzmi. Jak wypełniać i realizować, jakimi narzędziami poza wielu velocity, capacity i tym podobne, odpowiedzialność za efektywność teamu w roli Scrum Mastera.

Jacek: Plan na dzisiejszy odcinek jest taki, że na początku definiujemy, czym jest efektywność. Następnie podzielimy się naszymi poradami, jak można wpłynąć na efektywność. I na koniec dołożymy do tego już bardzo konkretne praktyki, które mogą pomóc Ci w tym temacie. To Kuba, jak jest z tą efektywnością w Scrumie?

Kuba: I to jest dobre pytanie, bo ta efektywność pojawia się w najnowszej aktualizacji Scrum Guide’a. Opowiadaliśmy w 51. odcinku o tym, jak zmienił się Scrum Guide, czy jak się zmieniły wytyczne scrumowe w najnowszej wersji. I tam m.in. pojawia się bardzo jasno wprost powiedziane, że to Scrum Master jest accountable, czyli odpowiedzialny, ale w tym istotnym zniuansowanym znaczeniu, jest odpowiedzialny za to, żeby Zespół Scrumowy był efektywny. I tutaj musimy zacząć od takiego trochę językowego kawałka, czyli tej definicji, o której Jacek powiedział w planie odcinka. Bo tutaj dwa smaczki są. Jedna sprawa to jest właśnie ta odpowiedzialność Scrum Mastera. Czyli Scrum Master sprawia, że te rzeczy się dzieją. Natomiast oczywiście wspierany jest przez cały Zespół. Natomiast jeszcze ważniejsze niuans jest, w definicji czy w rozumieniu słowa efektywność. Intuicyjnie, bez zaglądania w definicje żadne, możemy mieć czasami złe wyobrażenie i często się z tym spotykam w różnych Zespołach, że to znaczenie słowa efektywność kojarzy się bardziej z produktywnością, z realizacją jak największej ilości pracy. Natomiast to nie jest tak, efektywność to nie jest właśnie ilość pracy, którą wykonujemy, tylko to jest wartość tego, co dostarczamy. Stąd, jeśli byśmy tutaj rozebrali tą definicyjną część efektywności czy odpowiedzialności za efektywność Zespołu Scrumowego, no to Scrum Master sprawia czy doprowadza, wspiera do tego, żeby wartość pracy, którą wykonuje cały Zespół Scrumowy, była jak no najlepsza. Przede wszystkim jakaś konkretna, ale też najlepiej jak najbardziej rosnąca.

Jacek: Czyli tutaj generalnie, no na pewno rozczarujemy osoby, które ucieszył ten zapis w najnowszym wydaniu Scrum Guide’a, że Scrum Master teraz będzie, przerysuję oczywiście, stał nad ludźmi i powodował, że będą szybciej pracować. No nie o taką efektywność chodzi. Bardziej chodzi nam o to, żeby Zespół robił nie tyle szybko rzeczy, co żeby robił rzeczy właściwe. Czyli takie rzeczy, które przybliżają nas do osiągania konkretnych celów biznesowych.

Kuba: I zwróćmy uwagę, że tutaj w tych osiąganych celach biznesowych nie ma słowa o velocity, czy capacity, więc tutaj jednak zrobimy korektę do tego pytania oryginalnego, które zainicjowało, czy zainspirowało nas do nagrania, że akurat na przykład velocity liczona jako Story pointy dostarczane przez Zespół, albo ilość ficzerów dostarczana przez Zespół, czy jakakolwiek miara przewidywalności Zespołu, realizacji Celu Sprintu, to wszystko nie są miary efektywności. To są miary też istotne. To są miary procesowe pokazujące, jak Zespół pracuje. Natomiast to nie są miary efektywności. I de facto można nawet, by powiedzieć, że nie mają z efektywnością w sumie nic wspólnego. Tylko żebyśmy nie mieli tutaj złego skojarzenia. Te rzeczy związane z wydajnością procesu, przewidywalnością procesu też są istotne. No bo jeśli na przykład Product Owner, czy firma, czy sam Zespół nie może polegać zupełnie na swoim procesie, Zespół czasem coś robi, czasem czegoś nie robi, czasem robi więcej, czasem robi zupełnie nic, albo bardzo mało. No to tutaj to też jest duży kłopot i on może czasami być jeszcze bardziej fundamentalny, niż to, jak wartościowe jest to, co ostatecznie wreszcie prędzej czy później ten Zespół zrealizuje. Tylko ten odcinek nie będzie o przewidywalności wydajności czy właśnie tego typu kwestiach. Chcemy się stricte skupić na efektywności Zespołu Scrumowego.

Jacek: No dobrze. Czyli co Scrum Master mógłby konkretnie zrobić, żeby w jak najlepszy sposób wypełnić swoją odpowiedzialność za efektywność Zespołu, rozumianą jako robienie właściwych rzeczy, które przybliżają nas do konkretnych celów biznesowych?

Kuba: Zacznę od czegoś zupełnie banalnego, zupełnie, prostego. Taka pierwsza rzecz, która mi przychodzi w tym temacie do głowy, to jest ustalenie, po co robimy dany element Backlogu Produktu? Zadawanie sobie tego pytania na każdym kroku przez cały Zespół, czy wprowadzenie takiej kultury, czy nawyku przez Scrum Mastera do swojego Zespołu. I to jest pytanie, które się zadaje Product Ownerowi, Interesariuszom. To jest pytanie, które wraca na Przeglądzie Sprintu. To jest pytanie, które też towarzyszy całemu Zespołowi w czasie pracy przy budowaniu i doskonaleniu Backlogu Produktu. Na początku pewnie Scrum Master musi w ogóle wyjaśnić i pokazać, że to ma sens, takie pytanie. Może kilka odmian tego pytania. Po co? Dlaczego? Z jakich przyczyn? Co ma nam to dać? Jest pewnie wiele synonimów. Nie musimy ujeżdżać tylko jednego jedynego tego wariantu, po co. Ale chodzi o to, żebyśmy całym Zespołem Scrumowym zadawali sobie to pytanie, odpowiadali na nie i na tej bazie wyciągali pewne wnioski. Bo to też nie jest pytanie, które ma powiedzieć po co. Czyli mam tezę, że to jest Ci niepotrzebne. Samo w sobie ćwiczenie też może mieć sens, ale bardziej mi chodzi jednak o ten wymiar. Upewnijmy się, jaką to ma wartość, co ma nam to dać. Jaki będzie rezultat końcowy? Jaki będzie efekt? I dopiero, jak wiemy, jakie to będzie, to też będziemy mogli na tej bazie budować ewentualne dalsze, czy to usprawnienia, lepsze decyzje, motywację, zaangażowanie. To też są ważne rzeczy, ale oprócz tego po prostu pewną selekcję czy taką refleksję, co jest wartościowe w tym. Gdzie jest wartość w tym, co robimy. I bez tego porozmawiania po co, wiele innych bardzo bardziej promowanych technik, może po prostu nie zadziałać.

Jacek: Myślę, że warto tutaj dodać taką wskazówkę, żeby wprowadzić Zespół, że w ogóle takie pytanie będzie zadawane, na zasadzie, dlaczego to robimy? Czyli tak trochę na drugim poziomie. Po co zadajemy pytanie, po co. Mianowicie sam doświadczyłem wielokrotnie sytuacji, gdzie takie pytanie zadane bez tego wprowadzania, bez kontekstu, no było odbierane jak atak, jak jakaś taka prowokacja. No i dawało zupełnie odwrotny efekt, niż można było się spodziewać. Dlatego spokojne wytłumaczenie, co stoi, jaka jest intencja zadania tego pytania, a może też wręcz wprowadzenie przed spotkaniem, na przykład z osobą biznesową, na przykład z Product Ownerem tego tematu. Czyli, że w ogóle będziemy o tym rozmawiać. I to jest ok, że takie pytania padną, może być prostą techniką, która obniży stres, który może pojawić się na takim wydarzeniu. Idąc dalej kolejna nasza rekomendacja, to jest rekomendacja, żeby zapewnić głębokie Refinementy, czyli, żeby ten czas, kiedy spędzamy na lepszym zrozumieniu tego, co jest do wykonania, ten czas, który spędzamy na porządkowanie Backlogu Produktu, czas, który spędzamy na dzieleniu dużych elementów na mniejsze i tak dalej. Żeby ten czas był wykorzystany w sensowny sposób. I teraz, co to znaczy w sensowny? Uważałbym tutaj na to, żeby nie podejść do tematu tylko w taki mechaniczny sposób, czyli przyjmując, że to, co dostało się w jakiś sposób do Backlogu Produktu, no jest po prostu rzeczą do zrobienia, którą po prostu powinniśmy jako Zespół posiadający odpowiednie umiejętności, przerobić na produkt. Zdecydowanie tutaj zachęcałbym do zrozumienia potrzeby, która stoi za jakąś konkretną jakąś konkretną zmianą, czy za jakimś konkretnym wymaganiem, które pojawia się w zespole. Czyli, to co bym tutaj konkretnie zarekomendował, to takie empatyzowanie z Użytkownikiem. Czyli próba zrozumienia, jak czuje się nasz Użytkownik, jakie ma problemy? Co powoduje, że pojawia się jakaś konkretna potrzeba? Jak wygląda dzień takiego Użytkownika? Jak wyglądają jego zadania? I tak dalej. Po to, żeby dobrze najpierw zrozumieć, jaka jest potrzeba i dopiero potem zastanawiać się, w jaki sposób możemy to rozwiązać. Tych sposobów na rozwiązanie konkretnej potrzeby zwykle jest więcej niż jeden. Natomiast nieprzeprowadzenie takiej rozmowy, i nieprzeprowadzenie tego ciągu myśliwego, może powodować, że automatycznie wpadnie jakieś konkretne rozwiązanie, które być może, nie jest wcale najbardziej optymalne, czy najlepsze dla tego konkretnego problemu, czy potrzeby.

Kuba: I tutaj, co konkretnie Scrum Master może z tym zrobić, to też zacznę od trochę negatywu. Na pewno Scrum Master nie powinien być w procesie Refinementu takim strażnikiem rutyny. No to dzisiaj Refinement jak zawsze, albo teraz najpierw upewnijmy się, że jest User Story, a potem polecimy wyceny w Story Pointach. Tu Scrum Master przede wszystkim warto, żeby robił pół kroku lub cały krok w tył i rzucił okiem na to, czy ten proces przebiega według tych wytycznych, które już zdążyliśmy powiedzieć, a jeszcze kolejne mamy w zanadrzu. I też eksperymentować z formą. Szukać możliwych alternatyw. Zastanawiać się, jak tutaj poprawić ten aspekt właśnie głębokości Refinementu, współpracy z odbiorcą i tak dalej. I te wszystkie kwestie mogą wpływać na jakość procesu w Zespole. Czyli w skrócie, no nie bądźmy tutaj strażnikiem nawyków, jakie do tej pory nam się w Zespole wybudowały, a wręcz właśnie bądźmy takim ciągle nienasyconym inspiratorem. Osobą, która przynosi konkretne kolejne techniki. Zachęca zespół do spróbowania tego. Zachęca zespół do wykorzystania tego czasu, który na Refinement jest poświęcany jeszcze lepiej. W jeszcze lepszy sposób jeszcze bardziej kreatywny. I to, co powiedziałem, że w zanadrzu są jeszcze kolejne techniki, to następna rzecz, która ma spory wpływ na efektywność Zespołu Scrumowego, to jest podejście do dekompozycji elementu Backlogu Produktu i selekcji spośród tych zdekomponowanych elementów, jak najbardziej wartościowych kawałków. Czyli parafrazując, takie założenie, że wszystko, co realizujemy, może być podzielony na mniejsze kawałki i w tych mniejszych kawałkach mamy wymieszane rzeczy, które mają wartość i rzeczy, które tej wartości mają mniej lub nie mają jej w ogóle. No i tutaj z tym założeniem jest taka naturalna pułapka, że w wielu Zespołach jest pewna niechęć do dzielenia zadań dużych. Na zasadzie, że jest to żmudny proces, że to w sumie wymaga pewnego wysiłku. To może zróbmy cały ten proces. Zróbmy całą tę tabelkę, zróbmy cały ten ekran naraz. Opiszmy go jakoś pobieżnie i po prostu zabierzmy się do roboty. No i później się okazuje, że zespół faktycznie utyka, te zadania są duże, no ale odcinek jest o efektywności. Ja najbardziej się obawiam wtedy, że wśród rzeczy, które miały wartość wysoką, poutykane czy poprzylepiane były też takie cząsteczki pracy, które po prostu tej wartości nie miały w ogóle, a skonsumowały czas. Skonsumowały energię całego Zespołu, żeby wykonać ten kawałek produktu.

Jacek: Przykład, którym bardzo często dzielę się z Uczestnikami szkoleń, kiedy rozmawiamy o dekompozycji, to jest przykład stworzenia strony logowania. Strona logowania to jest takie fajne pojemne określenie na pewne funkcje, które chcielibyśmy mieć na tej stronie. I one niestety bardzo często w praktyce są poddawane pod dyskusję. Kiedy rozbierzemy sobie taką stronę logowania, okazuje się, że masa najróżniejszych takich domyślnie przyjętych wymagań, czy funkcji, takich jak przypominanie hasła, czy możliwość logowania przy użyciu Facebooka, czy Googla. Dbanie o to, żeby zmieniać hasło, na przykład raz na miesiąc. Dbanie o to, żeby to hasło zmieniane było różne od hasła, które ustaliliśmy miesiąc wcześniej. Jakieś dynamiczne grafiki w tle i tak dalej. Można by tutaj było długo o tym rozmawiać. To są takie rzeczy, które można podzielić na pojedyncze elementy. Możemy się zgodzić w trakcie takiej dyskusji, że wiele z tych takich domyślnych funkcji dostępnych na stronach logowania, nie jest nam potrzebne, albo nie jest nam potrzebne w tym momencie, albo nie chcielibyśmy tego robić w tym momencie. I ta dyskusja o na zwykle jest bardzo ciekawa, ale możemy do niej dojść, dopiero kiedy podzielimy sobie taki duży kawałek, który mamy do zrobienia na mniejsze części, bo dopiero wtedy pojawia się optyka, która pozwala nam powiedzieć OK. To jest konieczne. To zrobimy teraz, a część z tych rzeczy, które wyszły nam na skutek dekompozycji, no po prostu albo mogą poczekać, albo tak naprawdę wcale ich nie potrzebujemy. Kolejną wskazówką jest dążenie do realizacji konkretnego celu produktu, a nie podążanie za jakimiś zdefiniowanego projektem czy inicjatywą. Co mam na myśli? Mam na myśli wspieranie Zespołu w pamiętaniu o tym, co tak naprawdę chcemy osiągnąć. Zakładając, że mamy przygotowaną wizję produktu. Cel produktu jest dla nas takim, nazwijmy to krokiem, który doprowadza nas do realizacji tej wizji. Zwykle taki cel produktu jest definiowany biznesowo. No i on nam przypomina, co tak naprawdę chcemy osiągnąć. Podążanie za już takim dobrze zdefiniowane projektem, czy podążanie za już złożonym Backlogiem Produktu, może spowodować, że wpadnie w pułapkę realizowania pewnych funkcji, realizowania pewnych wymagań, implementowania najróżniejszych części produktu, które de facto wcale nie wspierają naszego celu produktowego. Tak więc trzymanie uwagi zespołu na celu produktu jest bardzo prostą techniką, która pozwala nam się upewnić, że rzeczy, które robimy, faktycznie przybliżają nas do założonego wcześniej celu.

Kuba: W poprzednim punkcie Jacek podawał przykład strony logowania. A w takim wątku podążania za realizacją celu, a nie z góry określonego zakresu, przypomina mi się przykład przebudowywana na przykład procesu zakupionego w jakimś serwisie e-commerce. I w wielu firmach, w wielu zespołach dosyć łatwo wchodzą takie tematy – przebudowa kompletna layoutu, albo zbudowanie całkowicie od nowa całego procesu. I zespół już na dzień dobry jest w procesie, czy w jakimś takim toku prac, które są z automatu wielomiesięczne. Natomiast gdybyśmy zaczęli od celu i na przykład tym celem byłaby lepsza konwersja albo większa sprzedaż, wyższa wartość pojedynczego koszyka. To może się okazać, że pojedyncze małe zmiany i to dosłownie drobne zmiany, obaj z Jackiem mamy takie mocne doświadczenie, że dosłownie lepsze formatowanie pewnych nagłówków i lepsza organizacja pewnego krytycznego ekranu, może zrealizować cały ten cel, który był zakładany względem jakiegoś gigantycznego projektu, który by skonsumował mnóstwo czasu energii i też zablokował moce przerobowe całego zespołu na długi czas. Więc tutaj niezależnie od tego, czy zaczynamy od projektu, czy nie to i tak bym najpierw całym Zespołem uruchomił wątek jako Scrum Master. Ok. Fajnie, że mamy ten pomysł na duży epic, na projekt, na jakąś wielką inicjatywę. To, jaki jest cel tego czegoś? I czy znamy jakieś alternatywne opcje? Czy mamy jakieś pomysły na coś mniejszego niż ten wielki projekt? Co zrealizuje nam cel lub nas do niego zbliży? I cała taka rozmowa, ona czasami podobnie jak z tym „Start with why”, od którego zaczęliśmy, ona może być dosyć ciężka. Ona może być odebrana jako atak. Ale jeśli tylko w cywilizowany sposób ją przeprowadzimy, to może się okazać, że zespół znajdzie lepsze tańsze, a może nawet bardziej wartościowe rozwiązanie, niż to, które zostało w jakiś sposób podyktowane, czy predefiniowane, czy z góry wymyślone. Już nieważne czy przez Product Ownera, czy przez Interesariuszy, czy jakoś tak samo się zrodziło. Bo to w różnych firmach bywa różnie z tym. Następna rzecz, która jest też powiązana z tym celem produktu, to wprowadzenie do Zespołu całej koncepcji stosowania nawykowo miar produktowych na Review Sprintu i porządkowanie Backlogu Produktu. I tutaj mam na myśli coś takiego, żeby w ogóle uruchomić rozmowę na ten temat. Co jest miarą naszego produktu? Często to będzie więcej niż jedna rzecz. Więc może to jest cały zestaw miar. I wracanie do tych miar. Zadawanie pytań na Review. Gdzie jesteśmy z naszymi miarami? Jak wyglądają aktualne stany tych wyników, czy jakichś wskaźników? Rozmowa też na planowaniu przy formułowaniu Celu Sprintu, bo może ten Sprint poprawia jakąś konkretną miarę i tak dalej i tak dalej. Scrum Master może doprowadzić do tego, że w ogóle ten temat nie jest tabu, że jest znany. Czasami w niektórych organizacjach to będzie trochę większa czynność, żeby w ogóle odszukać kogoś, kto tej miary w ogóle stosuje, ma. Wyciągnięcie tych danych, może doprowadzenie do tego, że te dane są na zawołanie dostępne dla wszystkich członków Zespołu. Może to jest kwestia jakichś dostępów albo dash boardów. No, ale sprawienie, że Zespół w razie, gdyby miał ochotę, to ma te miary. No i w drugim kroku też pokazanie Zespołowi, że warto w to zaglądać. Warto się tym przejmować. To wszystko wspiera te wszystkie dotychczasowe już wymienione porady. Że jakby tworzymy w Zespole taką kulturę patrzenia na to, jak nasz produkt działa. Jak się sprawdza. Jak się usprawnia, a może też jak się pogarsza. Jeśli mamy taką akurat sytuację.

Jacek: Wielokrotnie spotykam się z pytaniem od kadry menedżerskiej o rekomendacje, co zrobić, żeby zwiększyć zaangażowanie Zespołu?. To, co Kuba przed chwilą odpowiedział, no to jest bardzo proste, tak relatywnie patrząc sposób na, to żeby budować zaangażowanie w Zespole. Czyli pokazać konkretnie, co jest istotne. Pozwolić Zespołowi śledzić te miary. I bardzo często widziałem, jak reagowały zespoły, kiedy jakieś konkretne miary produktowe, bądź leciały w dół, albo się podnosiły po wprowadzeniu jakiejś konkretnej zmiany w produkcie. No zwykle to, nawet jeśli to były zmiany na minus to jednak Zespół reagował. A było widać, że zależy i że zaczynają się zastanawiać, co mogą z tym zrobić. Te wszystkie fajne rzeczy, o których mówię, mogą się wydarzyć, jeśli Zespół rozumie, co tak naprawdę jest istotne w kontekście produktu, który rozwijają. Kolejna porada, którą chcieliśmy się z Tobą podzielić, to porada, żeby skupić się na zmniejszaniu odległości deweloperów od Użytkownika. I oczywiście mówiąc deweloperzy mam tutaj na myśli osoby, które mają różne kompetencje do wytwarzania produktu. Moja obserwacja jest taka, że zwykle im większa jest organizacja, tym ta odległość do Użytkownika jest coraz większa. Coraz więcej jest warstw pośrednich pomiędzy osobą, która faktycznie pracuje nad rozwojem produktu, a tymi osobami, które z tego produktu korzystają. Czasem to jest tylko Product Owner. Czasem to jest Product Owner, Product Manager i analityk. Czasem pomiędzy tym wszystkim pojawia się jakieś Customer Service, Customer Support, partnerzy. No i ta informacja na temat tego, kim faktycznie jest Użytkownik, jak korzysta z Produktu, co go boli, jest filtrowania na tylu warstwach, że do Zespołu właściwie dociera już bardzo konkretne wymaganie. Czyli coś, co mamy zrobić, no bo ktoś, gdzieś tam, coś tam zbadał, usłyszał czy zebrał jakieś informacje. Tak więc im mniejsza ta odległość, tym większa empatia, tym lepsze zrozumienie potrzeb. I to powoduje ten efekt, o którym mówiłem przed chwilą, czyli kiedy osoby, które wytwarzają produkt, mają kontakt z Użytkownikiem. No to wytwarza się też takie poczucie pewnej odpowiedzialności. Czyli musimy dostarczyć ten produkt w jakiejś konkretnej jakości. No bo po prostu nie chcemy, żeby było nam wstyd przed osobami, które poznaliśmy, przed osobami, z którymi pracowaliśmy. No bo trochę zaczynamy wtedy lepiej rozumieć, że to jest produkt, którego ktoś na przykład używa na co dzień przez 8 godzin. No i po prostu po ludzku chcielibyśmy, żeby używanie tego produktu było jak najbardziej przyjemne.

Kuba: Ja położę akcent na to, co w zasadzie powiedziałeś na samym końcu, czyli to rozumienie. Jeśli Zespół Scrumowy rozumie tę faktyczną perspektywę odbiorcy produktu, to też jest w stanie lepiej dopasować rozwiązanie, wybrać bardziej wartościowe, wybrać coś, co faktycznie rozwiązuje problem, czy otwiera jakąś nową możliwość dla odbiorcy końcowego. Tutaj każdy z pośredników pogarsza to zrozumienie, przeinacza je. Zachodzi zjawisko głuchego telefonu. I też no nawet już w końcu może doprowadzić do takiej trochę obojętności. Po prostu realizujemy z góry określony zakres. Nie ma tu pola manewru i tak nie mamy od kogo się dowiedzieć, czy te opcje alternatywne, które wymyśliliśmy, w ogóle mają sens. Więc tutaj to rozumienie daje dużo nowych możliwości. I te nowe możliwości wspomniałeś też zaangażowanym Zespole. Nowe możliwości mogą dać też okazję do tego, żeby Zespół włożył swój wkład kreatywnie. Wymyślił coś jeszcze lepszego, niż komukolwiek do tej pory, na tych wczesnych etapach przyszło to do głowy. Czyli żaden manager, żaden tutaj zlecający, żaden jakiś reprezentant, czy pośrednik może nie mieć tak dobrego pomysłu, jak Zespół który zawodowo zajmuje się wytwarzaniem produktu i wygenerowywaniem jeszcze lepszych rozwiązań. Ja myślę, że to jest szczególnie istotny aspekt w tej sferze takich najbardziej innowacyjnych rozwiązań, na przykład rozwiązań tutaj IT, gdzie może się okazać, że żadnemu Użytkownikowi, ani żadnemu pośrednikowi nawet do głowy mu nie przyjdą, jakie są możliwości dobrego, sprawnego, wartościowego rozwiązania jakiegoś problemu, czy realizacji jakiejś konkretnej potrzeby. I jak już wspominamy o Zespole, to jest jeszcze jedna rada, która nam przychodzi do głowy z Jackiem w tym punkcie. To jest bazowanie na faktycznej zespołowości. Już wspomniałem przed chwilą o tej kreatywności, natomiast ta kreatywność jest jeszcze lepsza, jeśli w zespole jest taka autentyczna otwartość na swoje perspektywy, na swoje kompetencje. I ludzie się, tak można powiedzieć wzajemnie nakręcają. Wzajemnie właśnie jeszcze bardziej inspirują do tego, żeby spróbować coś jeszcze bardziej wartościowego, jeszcze lepszego. Mam dużo bardzo fajnych wspomnień z takich momentów, gdy w zasadzie cały Zespół wytwarza jakąś całkiem kreatywną wizję, czy wpada na jakiś bardzo fajny pomysł. Jak się cofnie, czy spojrzy wstecz, to w zasadzie nie ma jednego autora tego pomysłu. To znaczy, żaden z indywidualnie zgłoszonych pomysłów nie był tak dobry, jak ta suma wszystkich jakby połączeń, tych poszczególnych specjalistów. I brzmi to chyba banalnie, albo bardzo oczywiste, ale niestety w takiej codzienności projektowej oczywiste nie jest. Za często widzę ludzi, którzy robią swoje od A do B. Dla wygody albo może dla nieuruchamiania pewnego procesu, lepiej się nie odzywać. Lepiej nie zgłaszać, lepiej nie wątpić, tylko po prostu zrobić swoje. I tutaj, no odcinek jest świetnym, co Scrum Master może z tym zrobić. Zdecydowanie być czujnym na to i obserwować ile razy zachodzi takie zjawisko. Pierwszy, o którym powiedziałem, czyli ludzie, którzy się wzajemnie nakręcają, podrzucają sobie pomysły. Być może nawet trochę za długo dyskutują, ale idąc w stronę najniższego bardziej wartościowego rozwiązania. A ile razy jest taki. Płaskie morze, taka cisza na okręcie, że po prostu wszystko robimy tak, jak nam zlecono i nikt się nie zastanawia.

Kuba: I tutaj używając terminologii scrumowej, to jest cały temat tego, czy te końce Sprintu, czy Przegląd Sprintu, czy Retrospektywa, czy to jest dla nas okazja do nierozłącznej pary, inspekcji i adaptacji, czy tylko inspekcji. I zwłaszcza myślę, Przeglądy Sprintu mogą bardzo łatwo wpaść w taki zwyczaj, że Zespół prezentuje, gdzie jest. Product Owner uzyskuje jakąś tam przejrzystość swojej pracy i kontynuują wcześniej objęty kurs. Czyli realizują dalej z góry założone wielosprintowy plan i nawet nie pojawia się pytanie, czy jest coś, co moglibyśmy skorygować. Nikt nie pyta o to Interesariuszy, nikt nie zadaje sobie pytania tego typu w samym Zespole Scrumowym. No i w efekcie kontynuujemy pierwotne plany, nawet nie dopuszczając sobie możliwości, czy nie zadają sobie tego pytania, czy na bazie zdobytej do tej pory wiedzy, mamy jakieś okazje, których do tej pory nie przewidywaliśmy. Więc tutaj Scrum Master może wprowadzić po prostu zwyczajowo jakieś takie cosprintowe pytanie, czy całą sekcję na Przeglądzie Sprintu, czy pojawiła się jakaś okazja, nawet szalona, nawet naiwna, nawet głupia. Ale, czy jest coś, co wcześniej nie widzieliśmy, a dzisiaj widzimy. Czego się nauczyliśmy? I czy na tej bazie możemy poprawić nasz sposób funkcjonowania. I tak jak Jacek mówi, to jest i procesowe i produktowe. Chociaż z tą efektywnością, to ja bym większy akurat w tym odcinku położył na tę stronę produktową. Czy nasze dotychczasowe plany, co do kolejnych Sprintów, co do kolejnych celów, co do Backlogu Produktu, czasami się nie zdezaktualizowały? Albo patrząc odwrotnie, czy nie pojawiła się jakaś lepsza okazja.

Słusznie pod odcinkiem o reorganizacji zespołów, odcinkiem 57. skomentował PiMa, że pokazaliśmy konkretną praktykę, czy konkretną technikę, która się nazywa „Delegation Board”, ale ani razu jej nie wspomnieliśmy. Więc teraz na koniec tego nagrania chcemy przywołać bardzo konkretne praktyki, konkretne techniki, które wspierają wszystko to, co powiedzieliśmy. W zasadzie tam, we wszystkich naszych rekomendacjach, zazwyczaj nie wspominaliśmy jakiejś konkretnej techniki, ale jeśli chcesz zasięgnąć jakiegoś konkretnego szablonu, wzorca, przeczytać jakąś konkretną jedną książkę, która poszerza któryś z tych wątków, to ta część jest dla Ciebie, ponieważ w tej chwili tak sprawnie wesprzemy wszystko to, co do tej pory powiedzieliśmy, konkretnymi rekomendowanymi materiałami lub technikami, które warto uwzględnić, żeby te wątki poszerzyć. I zaczynając od pierwszego wątku, czyli pytania – po co? Tutaj mocno rekomendujemy materiał Simona Sinka „Start with why”. Książka, ale też materiały online, które mocno pokazują, czy ugruntowują tę kwestię zaczynania od po co, czy zaczynania od dlaczego.

Jacek: Jeżeli z kolei chcesz prowadzić głębokie Refinementy i chcesz lepiej zrozumieć potrzeby Klienta, no to odsyłamy zdecydowanie do narzędzi z obszaru Product Discovery. W tym między innymi do różnych wariantów, szablonów, jak można lepiej zrozumieć Klienta. Czyli wszelkiego rodzaju mapy empatii, które pozwalają nam wejść w buty Użytkownika i lepiej zrozumieć jego potrzeby.

Kuba: Jeśli masz do podzielenia duże przedsięwzięcie na mniejsze kawałki, to bardzo przydać się może poprawne zastosowanie wzorca Story mapping.

Jacek: Jeżeli zależy Ci na technikach pomagających na dekompozycji i selekcji najbardziej wartościowych elementów Backlogu Produktu, to rekomendujemy Story slicing patterns, czyli takie wzorce dzielenia wymagań, czy wzorce dzielenia User Stories, które pomagają podzielić je na mniejsze kawałki.

Kuba: Technika, która bardzo mocno może przesunąć myślenie Zespołu z myślenia o zakresie rozwiązania na myślenie o osiąganiu celów, czy osiąganiu wpływu na produkt, nazywa się Impact mapping i mocno ją rekomendujemy.

Jacek: Jeżeli chodzi o zmniejszanie odległości deweloperów od Użytkowników, to tutaj zdecydowanie rekomendujemy zapoznać się z lekturą Lean UX.

Kuba: Jacek wspomniał, o tym, że może być wiele przyczyn, dla których w Zespole nie następuje bliska współpraca, nie następuje takie wzajemne nakręcanie się na kreatywne rozwiązanie. Jedną z rzeczy, na którą też bym zwrócił uwagę i zapoznał się z koncepcją, jest komunikacja, jaka występuje w Zespole. I tutaj mocno polecam całą koncepcję Non Violent Communication.

Jacek: Natomiast, jeżeli chodzi o narzędzie, które polega na refleksji procesowej i produktowej, to tutaj nie zaproponujemy jakiejś super popularnej techniki z Kubą. A bardzo konkretne pytanie, które nasz mentor od zwinności, mentor scrumowy wielokrotnie stosował, kiedy pracował z zespołami. Mianowicie takie pytanie, które brzmi „Co by się musiało wydarzyć, żebyśmy zaczęli dostarczać dwa razy więcej wartości w stosunku do tego, ile dostarczamy teraz.

Kuba: Zdecydowanie to pytanie pomogło przejść pewne trudne momenty na wczesnych etapach naszych karier scrumowych. Dobra, to na koniec mam jeszcze ważne ogłoszenie. Jeśli taki temat realizacji odpowiedzialności Scrum Mastera jest Ci bliski w praktyce, pełnisz tę rolę, chcesz się rozwijać zawodowo w jeszcze lepszym realizowaniu roli scrum masterskiej, zapraszam na kolejną edycję zdalnych warsztatów „Prawdziwe przypadki scrumowe”, które poprowadzę 19 i 20 maja. Więcej szczegółów i zapisy na stronie www.202procent.pl/przypadki-scrumowe. Zapraszam.

Jacek: Natomiast notatki do tego odcinka, z wyszczególnieniem tych wszystkich materiałów, które wyszczególniliśmy w tej ostatniej sekcji, a także transkrypcję plus zapis wideo, znajdziesz na stronie porzadnyagile.pl/60

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

Jacek: Dzięki Kuba.

Kuba: I do usłyszenia wkrótce.

The post #060 – Efektywność Zespołu Scrumowego first appeared on Podcast "Porządny Agile".

85 odcinków