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

Jak uniknąć pułapki Lessons Learned?

Lessons Learned jest narzędziem pracy powszechnie stosowanym w zarządzaniu projektami (bardzo popularnym u kierowników projektów). Dowiesz się, dlaczego naszym zdaniem ta koncepcja jest antywzorcem? W tej rozmowie usłyszysz o ciągłym doskonaleniu procesu i produktu wraz z listą rekomendacji, co można zrobić, żeby uniknąć pułapki zbyt późnych usprawnień.

Zapraszamy Cię do obejrzenia nagrania podcastu.

https://youtu.be/hz07UgKvSsA

Dodatkowe materiały

Obejrzyj nasze webinary!

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

Transkrypcja podcastu „Jak uniknąć pułapki Lessons Learned?”

Jacek: Opowiadałem ostatnio na konferencji, która dotyczyła tematu zbierania wymagań, o tym, dlaczego uważam, że koncepcja Lessons Learned jest antywzorcem. Temat wzbudził zainteresowanie uczestników konferencji, stąd pomysł, żeby podzielić się tą koncepcją w podcaście. 

Kuba: Spis treści tego odcinka. Zdefiniujemy, czym są w ogóle Lessons Learned. Potem opowiemy o ciągłym doskonaleniu procesu. Nawiążemy też do ciągłego doskonalenia produktu i na koniec podsumujemy listą naszych rekomendacji, co można zrobić, żeby było lepiej.

Kuba: I zaczniemy od definicji. Czym jest Lessons Learned? Lessons Learned jest to narzędzie pracy powszechnie stosowane w zarządzaniu projektami, znane jako narzędzie pracy kierownika projektu. Lessons Learned polega na tym, że podsumowuje się wnioski i ustala w zespole projektowym możliwe potrzebne zmiany w podejściu do pracy, czy to zespołu, czy do sposobu działania procesów, czy dostosowania narzędzi dla kolejnych projektów w przyszłości. Najczęściej polega to na jakiejś sesji podsumowania pracy po skończonym projekcie, po skończonym wdrożeniu, po zakończonych pracach projektowych, gdzie cały zespół projektowy zastanawia się przez chwilę, co można było zrobić lepiej. Spisuje to, najczęściej w postaci jakiegoś bardzo konkretnego szablonu dokumentu, albo jakiegoś konkretnego narzędzia, w którym się te rzeczy zbiera i wyciąga wnioski na to, jak działać lepiej w przyszłości.

Kuba: Koncepcja co do zasady jest niezła i zwłaszcza w scenariuszu takim alternatywnym, w którym w ogóle nic takiego się nie robi, no to już lepiej, że się to robi, niż się nie robi. No i wiele zespołów bardzo cierpi na tym, że właśnie wszyscy wiedzą, co można było zrobić lepiej, ale nikt tego na głos nie nazwał. Jest jakiś taki słoń w pokoju, nie uczymy się, czy członkowie zespołu nie zbierają nowych doświadczeń, nie ustalają, co poszło nie tak. Też czasami w projektach są kryzysy i z tych kryzysów też nikt w sumie nie wyciąga żadnych wniosków, więc w niektórych organizacjach, w których takich Lessons Learned w ogóle się nie robi, jest niestety takie poczucie odrobiny dnia świstaka, gdzie każdy kolejny projekt kończy się identycznymi kłopotami, czy ma kolejne podobne zawirowania, bo nikt na głos nie nazwał, że może wreszcie przestańmy robić X albo zacznijmy częściej robić Y. No i tutaj Lessons Learned jest częścią takiej koncepcji organizacji, która się uczy, częścią koncepcji też takiego rozwoju osobistego, gdzie każdy członek zespołu nabiera coraz lepszych doświadczeń na temat tego, co działa, co nie działa, jak robić to lepiej. Więc podsumowując, Lessons Learned jest narzędziem pracy i służy temu, żeby się doskonalić.

Jacek: I po tym dosyć pozytywnym wstępie Kuby, w praktyce trzeba powiedzieć, że tak jak my to obserwujemy, no to z implementacją tego podejścia bywa różnie. Bardzo często jest to pewien formalizm, a nie taka realna, szczera refleksja. I zwykle dzieje się to na końcu projektu, gdzie już odpalamy kolejne, już ludzie są gdzieś tam lokowani do nowych zadań. No i tak naprawdę ja zwykle obserwuję, że to jest coś w stylu – smutny obowiązek, a nie faktyczne wydarzenie, które pomoże nam na przyszłość. Druga sprawa, bardzo często obserwuję, że to jest częściej dokumentowanie pewnych wniosków i nacisk jest kładziony na to, żeby to dobrze spisać. Tak jak Kuba wspomniał, często w jakiejś takiej ustrukturyzowanej formie, niż akcent na faktyczne wprowadzanie zmian. Tych zmian często nie ma, kto do końca wprowadzić, no bo zespół w tym kształcie, w którym funkcjonował, być może będzie jakby już rozłożony gdzieś tam w innych częściach organizacji. No i ten taki, mówiąc po staropolsku, commitment, zobowiązanie, że coś zostanie zrealizowane, to się zwykle dosyć mocno rozwadnia. No i trzecia obserwacja jest taka, że zwykle skorzysta na tych naszych przemyśleń jakiś zupełnie inny zespół niż nasz. Więc tak naprawdę nie ma jakiejś super dużej motywacji, żeby zrobić to rzetelnie.

Kuba: No i najważniejsza czwarta obserwacja do naszych takich przemyśleń na temat Lessons Learned jako narzędzia pracy, dlaczego są realizowane tak późno, dlaczego dopiero na koniec. To przenosi nas do drugiego punktu tego odcinka, czyli ciągłego doskonalenia procesu.

Jacek: Ciągłe doskonalenie procesu jest trochę w kontrze do tej koncepcji Lessons Learned, którą opowiedzieliśmy, gdzie zaczynamy projekt, realizujemy go i dopiero na końcu projektu pojawia się ten moment refleksji. Podejście ciągłego doskonalenia procesu zachęca nas do takiego ćwiczenia umysłowego, co by było, gdybyśmy taką refleksję robili co dwa tygodnie, czy to co tydzień, w zależności od tego, w jakich iteracjach, cyklach, Sprintach, jakkolwiek sobie to nazywamy, funkcjonuje nasz projekt. Te przykładowe dwa tygodnie, czy tydzień, to oczywiście najczęściej takie występujące w przyrodzie okresy, co ile zespoły sięgają pod tą koncepcję. Natomiast oczywiście można robić to częściej, zdecydowanie, jeżeli to ma sens. 

Kuba: Koncepcja ciągłego doskonalenia osoby, które korzystają albo znają Scrum, bardzo mocno wiążą z Retrospektywami Sprintu, natomiast my w tym nagraniu chyba chcemy podnieść poprzeczkę jeszcze wyżej i zachęcamy do koncepcji, którą my znamy od Alistair’a Cockburn’a, czyli koncepcję nano-usprawnień. Nano, czyli takich naprawdę drobnych usprawnień. Więc ciągle się doskonalmy, ciągle poprawiajmy swój proces pracy, sposób działania zespołu, spotkania, które stosujemy, narzędzia, których używamy, metody działania w ramach zespołu. Co działa, co można wypróbować, to jest dosłownie króciutkie pytanie. Na koniec na przykład Daily, gdzie po skończonym codziennym spotkaniu zespołu można poprosić o to, żeby podsumować się, jak wartościowe to spotkanie jest, czyli co w nim działa, ale co jeszcze można by zrobić inaczej. Dosłownie 5 minut rozmowy dzień w dzień może sprawić, że w ciągu na przykład dosłownie kilku dni z rzędu można doprowadzić Daily do takiego stanu, który jest bardzo satysfakcjonujący dla zespołu. No i te koncepcje nano-usprawnień można w zasadzie przylepić do dowolnej czynności, do pojedynczego warsztatu z klientem, do jednego dnia pracy w zespole, do sesji planowania pracy, do sesji Refinementu Backlogu Produktu. Wszystkie elementy, wszystkie takie objawy zespołowe można też skończyć jakąś naprawdę króciutką sesją bez całej rozbudowanej struktury, bez rozgrzewki, bez zbierania punktów, bez głosowania kropkami, tylko po prostu krótka, szybka rozmowa w zespole. Czy jest coś, co możemy spróbować, czy coś, co chcemy zrobić inaczej, co nie zadziałało, co zadziałało i co decydujemy się jako zespół, tę jedną rzecz, niewielką, drobną rzecz, żeby wprowadzić to do następnego przypadku. Do następnego dnia, następnego etapu, następnego warsztatu czy spotkania, tak jak wymieniałem jako przykłady. Więc tutaj jesteśmy za tym, żeby się ciągle doskonalić. Czasami to będzie raz na dwa tygodnie poprawianie sposobu działania w Sprincie, ale można nawet jeszcze lepiej. Dosłownie codziennie, czy co parę godzin się usprawniać i działać ciągle coraz lepiej.

Jacek: Jest kilka ważnych powodów, dla których warto się usprawniać. Podzielimy się takimi pięcioma najważniejszymi. Przede wszystkim ciągłe doskonalenie procesu pozwala uniknąć popełniania tych samych błędów. Słyszę czasem taki komentarz z zespołów, że to, co jest frustrujące, to jest to, że mamy te same błędy i się na nich nie uczymy i nie ma usprawnień. Jeżeli chcemy zidentyfikować błędy, jeżeli chcemy je usprawnić, no to ciągłe usprawnianie procesu może być bardzo prostym, a jednocześnie skutecznym narzędziem, które te błędy wyeliminuje z naszego procesu.

Kuba: Ciągłe doskonalenie może też prowadzić do poszukiwania innowacyjnych sposobów wykonywania pracy. Możemy wykonywać swoje działania ciągle tak samo, ciągle rutynowo, albo możemy z naszym procesem pracy eksperymentować. Spróbować nowego podejścia, innej techniki, poprowadzić spotkania zupełnie inaczej, poukładać swoje działania jako zespół zupełnie inaczej. I to może być dosłownie tylko i wyłącznie jednorazowe. Tak dla śmiechu zróbmy to inaczej, ale często w takich przypadkach, jeśli zespół ciągle się doskonali, to takie okazje do tego, żeby coś zrobić inaczej, nawet po prostu w szalony sposób inaczej, albo spróbować innego podejścia niż zwykle, prowadzi do tego, że ten zespół działa trochę lepiej, trochę inaczej, albo działa bardzo lepiej i bardzo inaczej dla dobra całego zespołu.

Jacek: Warto się usprawniać również z tego powodu, aby pozostać konkurencyjnym na rynku i ciągle dążyć do doskonałości. My jako organizacja możemy podjąć decyzję, że tego nie robimy, natomiast pamiętajmy, że nasza konkurencja może działać kompletnie inaczej. Wyobraźmy sobie sytuację, gdzie konkretna firma usprawnia się, powiedzmy raz na tydzień w ramach jakiegoś projektu. To są 52 okazje w ciągu roku, żeby usprawnić proces. Myślę, że nie muszę dopowiadać dalszej części tej historii. Ja bym wolał być w tej firmie, która faktycznie te usprawnienia wymyśla. No i co ważne, oczywiście wprowadza w życie.

Kuba: Ciągłe doskonalenie też daje okazję do tego, żeby uzyskiwać ten sam efekt mniejszym kosztem. Czyli zadbać o wydajność procesu, sprawić, że zespół ma mniej marnotrawstwa, szybciej wykonuje pewne działania, usuwa jakieś blokady w procesie czy spowolnienia. Bardzo namacalny, często wręcz dosłownie policzalny finansowo efekt, ale też po prostu wygodny dla zespołu, gdzie praca łatwiej idzie. Tak mówiąc potocznie, gdzie może jest mniej stresująca czy mniej denerwująca, czy mniej zmienna w taki nieprzewidywalny sposób.

Jacek: I ostatni powód, którym chcemy się podzielić. Usprawnianie się poprawia motywację zespołu. Jest to taki miękki kawałek tej historii, którą tutaj przytaczamy. Natomiast wielokrotnie słyszę od liderów, managerów pytanie. Jak mogę wpłynąć, jak mogę poprawić motywację zespołu? No i dla mnie oczywistą pierwszą myślą jest to usuńmy przeszkadzajki, usuńmy blokady, usuńmy to wszystko z procesu, co powoduje, że ludzie się frustrują. Wielokrotnie doświadczałem tego na własne oczy, jak zmienia się podejście, jak zmienia się energia w zespole, w sytuacji, w której ludzie, którzy są częścią tego zespołu, zaczynają dostrzegać, że ich działania usprawniające powodują, że przestrzeń środowiska, w którym pracują, jest po prostu bardziej przyjazne, jest bardziej efektywne. Naprawdę to są często małe zmiany, które prowadzą do naprawdę fajnych rezultatów.

Kuba: Więcej o tym, dlaczego się usprawniać, co podlega usprawnieniom i jak przeprowadzić taką sesję usprawnieniową zgodnie z rozbudowaną strukturą znajdziesz w naszym płatnym webinarze Porządna Retrospektywa Sprintu, który jest pod adresem porzadnyagile.pl/retro.

Jacek: Dobrze, przechodzimy do kolejnego kawałka dzisiejszego podcastu, czyli do części, w której powiemy o ciągłym doskonaleniu produktu.

Kuba: Dla wielu naszych słuchaczy, zwłaszcza tych, którzy są z nami od paru lat, którzy praktykują zwinne podejście też w swoich zespołach, koncepcja ciągłego doskonalenia sposobu pracy zespołu jest dosyć oczywista. Najczęściej realizowana rutynowo poprzez regularne retrospektywy Sprintu, jeśli stosowany jest na przykład Scrum. Natomiast to nie koniec tego odcinka, bo ta sama logika, która mówi, że Lessons Learned na koniec projektu są antywzorcem, może być przeniesiona też na poziom zarządzania rozwojem produktu. I za dużo razy obserwujemy zespoły, w których jakkolwiek to nazwiemy, wdrożenie, projekt, inicjatywa, jest dopiero tak weryfikowana rynkowo, dopiero na koniec, gdy już jest trochę za późno. I wszystkie te wady, o których mówił na samym początku Jacek, mają zastosowanie, czy mają tutaj podobną analogię. Nie ma okazji do tego, żeby skorzystać z wniosków, nie ma okazji do tego, żeby coś jeszcze poprawić w ramach bieżącej inicjatywy. Często te wnioski już nikogo nie interesują, bo zespół się w jakiś sposób przesuwa do innych działań, a może w ogóle zmienia kształt, więc tak jak zachęcamy do ciągłego doskonalenia procesu, i to jest oczywiste, tak samo przestrzegamy przed unikaniem ciągłego doskonalenia produktu.

Jacek: Jest kilka wad, podejścia, o którym powiedział Kuba, czyli refleksja na temat produktu dopiero w momencie, kiedy ten produkt wydajemy czy pokazujemy światu. Przede wszystkim ten moment weryfikacji założeń biznesowych pojawia się bardzo, ale to bardzo późno w tym procesie. Być może te założenia zostaną już z nami na zawsze, jeżeli ograniczenia organizacyjne nie zakładają, że będziemy robić jakąś kolejną rundę usprawnień czy jakichś takich dodatkowych przyrostów do produktu naszego projektu. Więc wszystkie te błędne koncepcje, błędne założenia, one po prostu wyjdą na rynek, no i będziemy musieli, niestety, ze smutkiem obserwować, jak bardzo się pomyliliśmy, jak bardzo nie udało nam się ogarnąć złożoności. No i w tym najgorszym przypadku nie będziemy mieć szansy na to, żeby te błędne założenia skorygować, albo będzie to bardzo kosztowna zabawa, żeby to zrobić na tak późnym etapie procesu.

Kuba: Jak sobie to tym swobodnie mówimy, to może się wydawać takie oczywiste, no to po prostu trzeba to poprawić po wdrożeniu, ale smutna realia wielu organizacji i taka też jednocześnie druga wada, którą dorzucę do puli, to to, że poprawienie czegokolwiek w wielu organizacjach z powodów proceduralnych, formalnych, narzędziowych po prostu wymaga na przykład zgłoszenie nowego projektu, albo zgłoszenie w jakiś ukryty sposób obejścia procesów i procedur. Na przykład zgłoszenie błędów jako tak naprawdę nowej funkcjonalności, albo znalezienie jakiegoś takiego wejścia od tyłu do Product Ownera, żeby tak nam grzecznościowo jakieś usprawnienie zrobił. I to wszystko powoduje, że poprawienie czegokolwiek w niejednej organizacji jest po prostu prawie niemożliwe, albo wymaga bardzo dużych wysiłków, takich również nieformalnych, co powoduje, że albo te poprawki są zrobione tak bardzo byle jak, takim minimalnym możliwym kosztem, żeby się nie narażać, albo przechodzą ścieżkę zdrowia. Zgłoszenie od nowa business case’a, zgłoszenia od nowa na jakiś portfel, na jakiś komitet i różne tego typu rzeczy. I oczywiście te wymienione przeze mnie procedury mają mało wspólnego z agile’em, ale jednocześnie z tego co widzę są codziennością wielu organizacji, cały czas stosowane narzędzia, więc wtedy tym bardziej trudno jest usprawnić swój produkt.

Jacek: Trzecią wadą podejścia, gdzie odsuwamy na koniec wdrożenie rezultatów projektu, jest fakt, że wiedząc, że tak z założenia nie będziemy mieć iluś tam podejść, nie będziemy mieli przestrzeni, żeby iterować, czy pracować w przyrostowy sposób, no pojawia się duża chęć, bardzo idealistyczna, żeby zrobić po prostu wszystko dobrze i perfekcyjnie za pierwszym podejściem. Co oczywiście ma swoje wady, bo blokuje kreatywność, powoduje, że wpadamy we wszelkiego rodzaju paraliże analityczne no i może też powodować, że cały ten proces decyzyjny będzie się wydłużał.

Kuba: Dobrze, to już wymieniliśmy wady podejścia wdrożenia na koniec. Co proponujemy zamiast? No, Jacek już to trochę powiedział, zdecydowanie optujemy za podejściem iteracyjno-przyrostowym, z wczesnym wdrożeniem pierwszej wersji do klienta i częstymi wdrożeniami kolejnymi rozwijającymi produkt. Produkt rozwija się małymi krokami, zaczynając właśnie z jakiejś bardzo prostej wersji zaspokajającej bardzo podstawowe potrzeby klienta, może nawet tylko pewnej podgrupy docelowej klientów, ale już na wczesnych etapach trafia do tego odbiorcy docelowego, mamy okazję zebrać informację zwrotną i ewentualnie wyłapać te błędne założenia, o których mówił Jacek. Mieć okazję do tego, żeby poprawić ten produkt, o czym ja wspominałem, czy też może trochę zmniejszyć ciśnienie na to, żeby od razu mieć idealne rozwiązanie, bo mamy parę okazji do tego, żeby to rozwiązanie skorygować. I to, co mówię, jest absolutnie realne w tych nawet smutniejszych organizacjach, o których wspomniałem, bo nawet jeśli mamy komitet i mamy wielki projekt, jakiś budżet i jakieś duże koncepcje, to dalej szukajmy okazji do tego, żeby w ramach jakiegoś większego przedsięwzięcia podzielić to na mniejsze kroki i poszukać okazji do wdrożenia mniejszego etapu czy kroku, czy fazy wcześniej.

Jacek: Jest sporo korzyści takiego podejścia, które Kuba opisał. Przede wszystkim pracując w ten sposób, otrzymasz wcześniej informację zwrotną, co pozwoli ci udoskonalić Twoje rozwiązanie. 

Kuba: Korzyścią drugą jest to, że wcześniej dostarczysz część wartości na rynek. Jest spora szansa, że to pierwsze rozwiązanie, może w drugim, trzecim kroku, będzie już na tyle wartościowe, że rynek zacznie go doceniać, ludzie zaczną za to płacić, klienci zaczną kupować czy zamawiać naszą usługę i dzięki temu jeszcze w trakcie trwania prac rozwojowych już zacznie się pojawiać jakiś zwrot z tej inwestycji. W zależności od tego, jakie są realia produktowe, może się okazać, że ten zwrot jest naprawdę wartościowy i w zasadzie już zaczyna spłacać wszystkie koszty inwestycji, co najczęściej jest bardzo dobrą wiadomością dla organizacji.

Jacek: Kolejna korzyść, łatwiej oddzielisz wartościowe elementy tego, co wytwarzasz od tych mniej wartościowych. Oczywiście wiąże się to z tym, żeby w ogóle z takiego podejścia przyrostowo-iteracyjnego skorzystać, no to na pewno będziemy musieli się zaprzyjaźnić ze sposobami dzielenia produktu, ze sposobami dzielenia wymagań na mniejsze kawałki. W tym procesie dzielenia zobaczymy, że coś, co początkowo wydaje nam się czymś dużym, co musimy zrobić od A do Z, po podzieleniu może się okazać, że tak naprawdę z tych 10 kawałków, które mamy po podzieleniu, to tak naprawdę wartość przynosi 5 albo 6 albo 7 i być może ta pozostała część będzie odłożona na później. No, ale w wariancie, który często obserwuję w praktyce, być może te pewne elementy, które pierwotnie nam się wydawało, że są istotne, po prostu nie zostaną nigdy zrealizowane.

Kuba: Kolejną konsekwencją tego, co Jacek powiedział, jest to, że podczas dzielenia odkryjesz niuanse pracy do wykonania. Wiele zespołów, które idzie w scenariusz wielkiego wdrożenia, czyli zrobimy wszystko, zrobimy kombajn, zrobimy uniwersalne narzędzie, które robi kompletne zarządzanie całym procesem, często nie patrzy się w niuanse czy w szczegóły. Jacek mówił o oddzielaniu wartościowych i mniej wartościowych rzeczy, a ja bym dorzucił jeszcze do puli w ogóle zrozumienie istoty tego, co jest do zrobienia. Jeśli szukamy bardzo prostej wersji pierwszej, drugiej, trzeciej, to może się okazać, że też większą uwagę skupiamy na tym, co jest istotą tego, co faktycznie jest produktem, co jest wartością. I lepiej zespół, interesariusze, sponsorzy zrozumieją, co jest faktycznie do zrobienia, co jest tutaj jakąś przewagą rynkową, a co jest może gdzieś mgliste lub może być zupełnie ominięte.

Jacek: Jeżeli chcesz poznać więcej argumentów, dlaczego warto dzielić pracę na mniejsze kawałki, zachęcamy do odsłuchania odcinka numer 76, „Dlaczego warto dzielić pracę na małe części?”. Odcinek ten znajdziesz pod adresem porzadnyagile.pl/76

Kuba: Dobrze, to w ostatniej części tego nagrania powiemy, co można zrobić, żeby było lepiej. Co można zrobić, żeby do swojego zespołu wprowadzić podejście ciągłego doskonalenia procesu i ciągłego doskonalenia produktu.

Kuba: Pierwsza rekomendacja. Sprawdź, jak dzisiaj często usprawnia się proces i produkt. Wiele zespołów kompletnie nie zdaje sobie sprawy, jak rzadko to robi, albo jest to po prostu codziennością, taką rzeczywistością, na którą nikt świadomie się nie pochyla, więc jako lider swojego zespołu, który przekonany jest do tego, że trzeba coś zmienić, możesz zebrać dane, zebrać fakty, cofnąć się trochę w przeszłość funkcjonowania twojego zespołu i przedstaw te fakty swojemu zespołowi i porozmawiajcie o tym, czy to jest satysfakcjonująca częstotliwość, czy może przegapiona okazja do tego, żeby się jednak zmieniać. Jeśli temat nakłuwa ciebie i przykuwa uwagę, to być może da się zrobić lepiej. Ja jestem ambitny i uważam, że w każdym zespole da się zrobić to jeszcze lepiej. Więc tutaj można łatwo na faktach i na pewnych konkretnych historiach lokalnych z tego swojego konkretnego zespołu pokazać, że da się proces usprawniać częściej niż robicie to aktualnie.

Jacek: Kolejny punkt, kolejna rekomendacja, buduj świadomość, dlaczego ciągłe usprawnianie się jest wartościowe. I tutaj zarówno mamy na myśli perspektywę członków zespołu, jak również organizacji. Czyli wszelkiego rodzaju te koncepcje, którymi dzieliliśmy się z Kubą w trakcie tego odcinka, mogą być właściwie gotowymi argumentami, gotowymi przykładami, którymi będziesz mógł lub mogła żonglować w rozmowie z zespołem. No bo tak naprawdę bez tej świadomości, jakby nie mając tego zrozumienia, dlaczego to może być wartościowe, no to zespół może odbierać tę zmianę jako coś niepotrzebnego, coś, co ma niższy priorytet niż zwykła taka bieżąca, codzienna praca.

Kuba: I w tym odcinku w kilku miejscach wymieniamy listę argumentów, dlaczego się usprawniać, dlaczego tego nie robić w zależności od kultury zespołu. Różna pula argumentów może być wykorzystana. Ja od siebie dorzucę jeszcze inną perspektywę. Można też zapytać, zwłaszcza członków zespołu z większym doświadczeniem, czy mają w przeszłości dobre wspomnienia po usprawnianiu się. W tej organizacji, może w poprzedniej, w której byli, wiele osób, które ma większe doświadczenie pracy, ma gdzieś w swojej historii takie fajne wspomnienie, jak to było ekstra, gdy ciągle zespół poprawiał, otwarcie mówił o tym, co może robić lepiej, czy na przykład o wiele częściej doskonalił produkt, bo to też często są bardzo inspirujące i bardzo konkretne historie? Więc tutaj możesz budować świadomość usprawniania się swoją historią i swoimi argumentami, możesz też poprosić członków zespołu do tego, żeby przynieśli swoje wspomnienia i swoje dobre historie. To też często bardzo przekonuje pozostałe osoby w zespole.

Kuba: Trzecia porada na temat tego, jak można usprawnić sposób usprawniania się zespołu. Przygotuj konkretną, prostą technikę, którą możesz pokazać zespołowi, by przeprowadzili sesje usprawnieniowe. Tutaj mam na myśli bardziej konkretnie historię związana z usprawnianiem procesu. Wiele zespołów niekoniecznie usprawnia swój proces, bo po prostu jednak nie za bardzo wie jak. Nie zna jakiejś struktur, nie zna sposobów. Zwłaszcza jeśli w zespole do tej pory w ten sposób się nie rozmawia, to może być takie trochę niezręczne, szczerze sobie powiedzieć, co nie działa. Może nie jest to częścią kultury organizacji, żeby też odważnie proponować różne zmiany, więc bardzo pomocne może być, jeśli jako lider lub liderka swojego zespołu po prostu zaproponujesz jakąś konkretną, prostą technikę usprawnieniową, która może otworzyć dyskusję, otworzyć co bardziej skryte osoby przed tym, żeby się nie wahały i jednak powiedziały co myślą i zaproponowały jakieś konkretne rozwiązania. Skąd brać te techniki? Wierni słuchacze wiedzą, że w wielu naszych odcinkach takie rzeczy wspomnieliśmy. Ja ponownie odeślę do naszego webinaru o retrospektywie do znalezienia pod adresem porzadnyagile.pl/retro. Oprócz samego webinaru jest częścią pakietu również zestaw instrukcji na temat tego, jak przeprowadzać konkretne techniki usprawnieniowe, które mogą być bardzo przydatne właśnie do tej rekomendacji, którą przed chwilą wymieniłem.

Jacek: Kolejna wskazówka, co można byłoby zrobić, żeby było lepiej w temacie ciągłego usprawniania się. Pomóż zespołowi w praktyce podzielić produkt na mniejsze elementy. Czyli to, o co mówił Kuba, to jest dostarczenie pewnej wiedzy, pewnych koncepcji. Natomiast tutaj przychodzi moment, kiedy należałoby sobie ubrudzić ręce i faktycznie namacanie na przykładach zespołowych pomóc wykorzystać tę wiedzę w praktyce. Dlaczego o tym wspominamy? Na bazie naszego doświadczenia brak umiejętności dzielenia jest jedną ze źródłowych przyczyn całego kłopotu. Zespoły często nie wiedzą, po co dzielić, nie wiedzą, że można dzielić, nie potrafią dzielić dostatecznie dobrze. I to niestety wpływa na to, że nie pracują przyrostowo, nie pracują interacyjnie, pracują na dużych elementach, które wchodzą albo wcale, albo w całości. I tak naprawdę to powoduje, że nie mamy zbyt wiele okazji do tego, żeby usprawniać zarówno produkt, jak i proces. Jeżeli temat tego, jak skutecznie dzielić prace na mniejsze kawałki jest dla Ciebie istotny, poruszyliśmy ten temat w naszym webinarze nazwanym Dekompozycja elementów Backlogu Produktu i znajdziesz ten webinar na stronie porzadnyagile.pl/deko.

Kuba: I ostatnia porada w temacie. Podsumuj rezultaty zmiany podejścia do usprawniania się. Przyjmijmy założenie, że wprowadzasz w życie rekomendacje wcześniejsze, które wymieniliśmy przed chwilą. Bardzo ważnym elementem wprowadzenia trwałej zmiany, zmiany nawyków, zmiany podejścia, czy po prostu zmiany kultury sposobu działania tego zespołu, to to, żeby jednak sobie świadomie zreflektować, czy jest lepiej. Czy to nowe podejście, częstsze rozmowy o tym, co możemy poprawić, czy inne podejście do rozwoju produktu, czy jest satysfakcjonujące, czy daje korzyści, daje te korzyści, które obiecywaliśmy, a może daje jeszcze jakieś nowe, o których nawet nie pomyśleliśmy? Pokaż miary. Jeśli masz jakieś miary procesowe, zrób rozmowę o tym, jak się usprawniacie, tak zwane Retro o Retro. Czyli czy ten sposób zmiany sposobu działania zespołu jest satysfakcjonujący, korzystny dla członków zespołu. Porozmawiajcie o tym, żeby bardzo świadomie sobie też zauważyć i docenić to, że ta zmiana faktycznie jest obiecująca, jest lepsza i że zespołowi się działa, dzięki temu lepiej czy efektywniej. Jeśli tego nie zrobimy, może być bardzo duże ryzyko, że gdzieś tam w takim codziennym pędzie życia projektowego, no po prostu przez chwilę było lepiej, ale nigdy sobie tego na głos nie powiedzieliśmy, no i niestety tak tutaj trochę incepcja wejdzie, ale wpadniemy w tę samą pułapkę, jak robienie Lessons Learned na koniec, albo w ogóle ich nierobienie. Czyli było przez chwilę lepiej, ale nigdy sobie tego na głos nie powiedzieliśmy, komuś gdzieś tam wypaliła się energia. Fajny moment będzie tylko wspomnieniem, a nie nową codziennością.

Jacek: I tym sposobem dotarliśmy do końca tego odcinka. Podsumowując, wiele zespołów pada w pułapkę Lessons Learned. Czyli wnioski dotyczące zarówno procesu, jak i produktu, pojawiają się na końcu procesu pracy.

Kuba: Zamiast antywzorca Lessons Learned na koniec, rekomendujemy ciągłe doskonalenie procesu pracy zespołu i ciągłe doskonalenie produktu. Daje to następujące korzyści. Zespół unika popełniania tych samych błędów. Może poszukiwać innowacyjnych sposobów wykonywania pracy. 

Jacek: Umożliwia pozostawanie konkurencyjnym na rynku i ciągłe dążenie do doskonałości. Uzyskiwanie tego samego efektu mniejszym kosztem i poprawia motywację zespołu.

Kuba:  Jeśli potrzebujesz wsparcia w zmienianiu kultury i chcesz zaszczepić ciągłe doskonalenie w swojej firmie, odezwij się do nas. Realizujemy programy wsparcia zespołów, których efektem jest nauczenie się przez nich i zbudowanie sobie nawyków poprawiania swojego sposobu pracy i poprawiania swoich produktów. Jeśli jest to narzędzie, które byłoby przydatne w twoich zespołach, odezwij się do nas na porzadnyagile.pl/kontakt.

Jacek: Natomiast notatki do tego odcinka, artykuł, transkrypcję oraz zapis wideo znajdziesz na stronie porzadnyagile.pl/122.

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

Jacek: Dzięki Kuba. I do usłyszenia wkrótce.

← Older

Dodaj komentarz

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

Wordpress Social Share Plugin powered by Ultimatelysocial