Jak uniknąć pułapki Lessons Learned?

Porządny Agile

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ń.

Porządny Agile · Jak uniknąć pułapki Lessons Learned?

Lessons Learned, czyli wyciąganie wniosków na końcu projektu, dla wielu wydaje się, być sensownym podejściem. Dowiedz się, dlaczego warto zrewidować tę koncepcję i jak efektywniej usprawniać produkty i procesy.

Pomysł na poruszenie tego tematu pojawił się podczas konferencji dotyczącej zbierania wymagań. Jacek opowiadał na niej o tym, dlaczego koncepcja Lessons Learned jest bardziej antywzorcem niż polecaną przez niego praktyką. Wzbudziło to duże zainteresowanie i postanowiliśmy rozwinąć to zagadnienie.

Spis treści

• Czym jest Lessons Learned?
• Ciągłe doskonalenie procesu
• Dlaczego warto się usprawniać?
• Ciągłe doskonalenie produktu
• Podejście iteracyjno-przyrostowe
• Korzyści z podejścia iteracyjno-przyrostowego
• Jak wprowadzić do zespołu podejście ciągłego doskonalenia procesu i ciągłego doskonalenia produktu?
• Transkrypcja podcastu „Jak uniknąć pułapki Lessons Learned?”

Czym jest Lessons Learned?

Lessons Learned jest powszechnym narzędziem stosowanym w zarządzaniu projektami. Polega na tym, że bazując na dotychczasowych działaniach, zbiera się i podsumowuje wnioski. Na tej podstawie ustalane są w zespole projektowym potrzebne zmiany, np. w podejściu do pracy zespołu lub do sposobu działania procesów, czy też dostosowania narzędzi dla kolejnych projektów w przyszłości.

Najczęściej polega to na spotkaniu podsumowującym pracę po skończonym projekcie lub wdrożeniu. Cały zespół projektowy zastanawia się przez chwilę, co można było zrobić lepiej. Przemyślenia te i wnioski są spisywane, aby wiedziedzieć jak działać lepiej w przyszłości.

Koncepcja Lessons Learned ma rację bytu, w sytuacji, gdy jest to jedyna rzecz, jaką ma zrobić zespół w ramach wyciągania wniosków, czy szukania usprawnień. Pozwala ona, chociaż w małym stopniu unikać ponownych błędów lub zawirowań. Jednocześnie Lessons Learned może być taktyką organizacji, która się uczy, a także w pewnym sensie elementem rozwoju osobistego członków zespołu, z których każdy nabiera coraz lepszych doświadczeń na temat tego, co działa, co nie działa, jak działać lepiej.

Z obserwacji niestety wiemy, że z implementacją tego podejścia bywa różnie, zwłaszcza gdy jest traktowana, tylko jako pewien punkt na liście do odhaczenia, zamiast stanowić szczerą refleksję.

Często jest ona też realizowana już po skończonym projekcie, kiedy ludzie są już myślami w nowych zadaniach, zespoły się mieszają lub realizują całkowicie odmienne projekty. Bywa to też traktowane jako smutny obowiązek bez dostrzegania pozytywnych aspektów, które mogą usprawniać działanie w przyszłości.

Jednocześnie widzimy, że jest to po prostu zwykłe dokumentowanie pewnych wniosków i nacisk jest kładziony na to, żeby je dobrze spisać i to jest głównym celem ćwiczenia. Wnioski potem nie są wykorzystywane, a propozycji zmian nikt nie wdraża w życie. Bywa też tak, że ze spisanych przemyśleń korzysta zupełnie inny zespół, więc nie ma tu motywacji, żeby zrobić to rzetelnie.

Ciągłe doskonalenie procesu

Lessons Learned stoi trochę w kontrze z ciągłym doskonaleniem procesu, gdyż zgodnie z tym, co wspomnieliśmy powyżej, moment refleksji pojawia się trochę późno, bo na koniec projektu. Z kolei podejście ciągłego doskonalenia procesu sugeruje, aby takie ćwiczenie odbywało się częściej, np. co tydzień lub co 2 tygodnie albo po każdej iteracji czy innym rodzaju cyklu.

Koncepcja ciągłego doskonalenia podczas korzystania ze Scruma zwykle łączona jest z Retrospektywami Sprintu, natomiast my chcemy Cię zachęcić do podejścia, jakie znamy od Alistair’a Cockburn’a, czyli do nano-usprawnień. Są to takie, naprawdę drobne usprawnia, dzięki którym ciągle się doskonalimy, ciągle poprawiamy swój proces pracy i sposób działania zespołu, usprawniamy przebieg spotkań, szukamy lepszych narzędzi czy taktyk. Stawiamy sobie tu proste pytanie: co działa, co warto wypróbować, a potem robimy małe kroki i przeprowadzamy drobne eksperymenty. Można to robić np. na koniec Daily, gdzie zespół odpowiada na pytania: jak bardzo wartościowe było to spotkanie, co działa dobrze, a co można by zrobić lepiej. Wystarczy dosłownie 5 minut rozmowy każdego dnia, gdyż to już po tygodniu może doprowadzić, że Daily stanie się satysfakcjonujące i przydatne dla wszystkich.

Nano-usprawnienia sprawdzą się w zasadzie przy każdej czynności, czy to w przypadku pojedynczego warsztatu z klientem, sesji planowania, czy Refinementu Backlogu Produktu. Nie ma tu potrzeby przeprowadzania jakiejś formy rozgrzewki, głosowania kropkami, czy długiej burzy mózgów. Wystarczy szybka rozmowa w zespole i wspólne zastanowienie się, czy jest coś, co można przetestować, zrobić inaczej, poprawić.

Dlaczego warto się usprawniać?

Podzielimy się 5 najważniejszymi naszym zdaniem powodami, dla których warto się nieustannie usprawniać.

Uniknięcie popełniania tych samych błędów.

Zespoły, z którymi rozmawiamy często narzekają, na popełnianie wciąż tych samych błędów, co jest bardzo frustrujące. Ciągłe usprawnianie procesu pomaga zidentyfikować te błędy, a następnie w prosty sposób je wyeliminować.

1. Uniknięcie popełniania tych samych błędów. Zespoły, z którymi rozmawiamy często narzekają, na popełnianie wciąż tych samych błędów, co jest bardzo frustrujące. Ciągłe usprawnianie procesu pomaga zidentyfikować te błędy, a następnie w prosty sposób je wyeliminować.
2. Poszukiwanie innowacyjnych sposobów wykonywania pracy. Wykonywanie pracy wciąż w ten sam sposób powoduje pewien rodzaj stagnacji, brak rozwoju zarówno całego zespołu, jak i poszczególnych jego członków. Do pracy wkrada się rutyna, którą można zastąpić ciekawością wzbudzoną przez eksperymenty wprowadzane do sposobu pracy. Można spróbować nowego podejścia, innej taktyki, prowadzenia spotkań czy sposoby planowania pracy.
3. Pozostawanie konkurencyjnym na rynku i ciągłe dążenie do doskonałości.
   Konkurencja nie śpi i należy o tym pamiętać. W czasie, gdy my pozostajemy w znanej nam strefie komfortu i nic nie zmieniamy, to firma, która zabiega o tego samego klienta, szuka usprawnień każdego tygodnia i w ciągu roku robi to aż 52 razy. To nie tylko prowadzi do podniesienia efektywności pracy, ale i zwiększa zaangażowanie zespołu, który widzi, że może się cały czas rozwijać.
4. Uzyskiwanie tego samego efektu mniejszym kosztem.
   Szukając ciągłych usprawnień, dbamy o wydajność procesu, sprawniejsze wykonywanie zadań, a blokady są eliminowane. Często przynosi to namacalne efekty finansowe, chociażby pośrednio poprzez wygodniejsze i szybsze działanie.
5. Poprawa motywacji zespołu.
   Wspomnieliśmy już o tym wcześniej, jednak chcemy podkreślić to jeszcze raz. Usunięcie blokad, utrudnień w pracy, elementów, które powodują frustrację, pozytywnie wpływa na motywację zespołu. Mniej jest stresu, nieprzewidywalności i zniechęcenia. Wielokrotnie obserwowaliśmy, jak zmienia się energia w zespole, gdy jego członkowie widzą, że mają realny wpływ na swoją pracę i widzą, że ich usprawnienia przynoszą efekty.

Więcej o tym, dlaczego się usprawniać, co może podlegać usprawnieniom i jak przeprowadzać sesje usprawnieniowe mówimy w naszym webinarze Porządna Retrospektywa Sprintu

Ciągłe doskonalenie produktu

Podobnie jak Lessons Learned są antywzorcem w przypadku wykonywania tego ćwiczenia na koniec projektu, to samo możemy powiedzieć o praktykowaniu tego na poziomie zarządzania rozwojem produktu.

Bardzo często obserwujemy wyciąganie wniosków i wprowadzanie poprawek dopiero po weryfikacji rynkowej. Nie ma już okazji, aby szybko coś poprawić w ramach bieżącej inicjatywy, a wnioski, które się pojawią, zazwyczaj mało kogo już interesują.

Refleksja na temat produktu dopiero w momencie, kiedy ten produkt wydajemy czy pokazujemy światu, ma kilka zasadniczych wad:

• Moment weryfikacji założeń biznesowych pojawia się naprawdę bardzo późno w procesie. Założenia te mogą już zostać na stałe, jeśli nie ma w planach robienia kolejnej rundy usprawnień lub modyfikacji produktu. Zatem wszystkie błędne decyzje zostaną na rynku, a im dłużej czekamy, tym ewentualne ich skorygowanie staje się coraz kosztowniejsze.
• Poprawienie czegokolwiek w wielu organizacjach wymaga zgłoszenia nowego projektu. Wynika to z różnego rodzaju procedur lub ograniczeń formalnych czy narzędziowych, funkcjonujących w danej firmie. Prowadzi to do sytuacji, w której poprawienie czegokolwiek jest po prostu prawie niemożliwe, albo wymaga bardzo dużych wysiłków, albo te poprawki są zrobione minimalnym możliwym kosztem i byle jak.
• Pojawia się ryzyko idealistycznego dążenia do wypuszczenia perfekcyjnego produktu, co jest wynikiem świadomości, że nie będzie możliwości późniejszych uprawnień. Blokuje to kreatywność, a dodatkowo może spowodować paraliż analityczny i wydłużenie procesu decyzyjnego.

Podejście iteracyjno-przyrostowe

W celu zminimalizowania opisanych przez nas problemów proponujemy podejście iteracyjno-przyrostowe, z wczesnym wdrożeniem pierwszej wersji i częstymi kolejnymi wdrożeniami rozwijającymi produkt.

Dzięki takiemu działaniu produkt rozwija się małymi krokami, począwszy od zaspokojenia takich podstawowych potrzeb klienta, a może nawet potrzeb tylko pewnej podgrupy klientów. Produkt już na wczesnych etapach trafia do odbiorcy docelowego, przez co jest okazja, aby zebrać informację zwrotną i wyłapać ewentualne błędne założenia.

W podejściu tym masz możliwość wprowadzania poprawek w przyszłości, zmniejszasz też presję na to, aby od razu stworzyć idealne rozwiązanie.

Korzyści z podejścia iteracyjno-przyrostowego

• Otrzymasz wcześniejszy feedback i udoskonalisz rozwiązanie.
• Wcześniej dostarczysz część wartości na rynek, klienci będą mogli poznać produkt, a w miarę kolejnych usprawnień, szybciej zaczną go doceniać i chcieć za niego płacić.
• Łatwiej oddzielisz wartościowe elementy od mniej wartościowych, co oczywiście wiąże się z umiejętnością dzielenia wymagań na mniejsze kawałki.
• Podczas dzielenia odkryjesz niuanse pracy do wykonania i łatwiej zrozumiesz istotę tego, co faktycznie jest do zrobienia.

Więcej argumentów za tym, aby dzielić pracę na mniejsze kawałki, usłyszysz w rozmowie „Dlaczego warto dzielić pracę na małe części?”, do odsłuchania którego serdecznie Cię zachęcamy.

Jak wprowadzić do zespołu podejście ciągłego doskonalenia procesu i ciągłego doskonalenia produktu?

Na koniec podpowiemy Ci, co może pomóc w zmianie sposobu pracy zespołu i uwzględnienia koncepcji ciągłego doskonalenia.

• Sprawdź, jak często obecnie usprawnia się proces i produkt w twoim zespole i przedstaw to zespołowi. Z praktyki wiemy, że bardzo wiele zespołów nie jest świadoma, jak rzadko przeprowadza usprawnienia, lub że warto to robić. Dlatego zachęcamy liderów zespołu, aby zebrać dane i fakty, spojrzeć wstecz na sposób funkcjonowania zespołu i przedyskutujcie sposób, w jaki obecnie odbywa się u Was proces usprawniania. Czy częstotliwość jest satysfakcjonująca, czy może coś można robić lepiej lub jakieś elementy tego procesu są zbędne?
• Buduj świadomość, dlaczego ciągle usprawnianie się jest wartościowe dla organizacji i członków zespołu. Skorzystaj z wcześniej przytoczonych porad, a korzyści, o których wspomnieliśmy mogą Ci posłużyć, jako argumenty podczas rozmowy z zespołem czy managementem. Ułatwi Ci to pokazanie wartości płynących z ciągłego usprawniania i zmniejszy poczucie, że proponowane zmiany są niepotrzebne i lepiej zostać przy tym, co sprawdzone i znane. Pomocne będzie też odniesienie się do Twoich wcześniejszych doświadczeń lub doświadczeń innych członków zespołu, którzy pracowali już z takim podejściem i być może mają inspirujące, oparte na faktach historie.
• Przygotuj konkretną prostą technikę, którą możesz pokazać zespołowi, by sprawnie przeprowadzili sesje usprawnieniowe. Dotyczy to bardziej usprawnień w procesie, których wiele zespołów nie robi, bo zwyczajnie nie wie jak. Nie każda organizacja ma kulturę jawnego mówienia o tym, co nie działa lub co należy zmienić. Dlatego warto zaproponować jakąś konkretną technikę usprawnieniową, która pomoże zrobić pierwszy krok, a także będzie wstępem do dyskusji, co jeszcze warto przetestować. Jeśli szukasz propozycji takich technik, to zachęcamy do przesłuchania naszego webinaru o retrospektywie, w pakiecie, do którego otrzymasz również zestaw instrukcji na temat tego, jak przeprowadzać konkretne techniki usprawnieniowe.
• Pomóż zespołowi w praktykach dzielenia produktu na mniejsze elementy.
  Na bazie naszego doświadczenia możemy śmiało stwierdzić, że brak umiejętności dzielenia produktu, jest jedną z podstawowych przyczyn braku podejścia iteracyjno-przyrostowego. Zespoły pracują na dużych elementach, które są wypuszczane tylko w całości. Nie daje to zbyt wielu okazji do usprawniania ani produktu, ani procesu. O tym, jak skutecznie dzielić pracę na mniejsze kawałki mówimy w webinarze Dekompozycja elementów Backlogu Produktu.
• Podsumuj rezultaty zmiany podejścia do usprawniania się. Bardzo ważnym elementem wprowadzenia trwałej zmiany (nawyków, podejścia lub kultury współpracy), jest monitorowanie czy te zmiany coś poprawiają. Dlatego pokaż miary, które pozwolą Wam to sprawdzić. Jest to o tyle istotne, że jeśli faktycznie pojawią się efekty i jeśli nie zostaną one głośno wyartykułowane, to może nawet ich nie zauważycie. Ten sukces będzie tylko szybko zapomnianym momentem, a nie nową codziennością.

Jeśli i Twój zespół wpadł w pułapkę Lessons Learned, czyli wyciągania wniosków na końcu, mocno zachęcamy Cię do zmiany podejścia i zaproponowania, aby wypróbować koncepcję ciągłego doskonalenia. Korzyści jest wiele, a metodą małych kroków i prostych eksperymentów, szybko można zauważyć poprawę efektywności i skuteczności.

Dodatkowe materiały

• Dlaczego warto dzielić pracę na mniejsze części?

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.

The post Jak uniknąć pułapki Lessons Learned? first appeared on Porządny Agile.