Agile poza IT

#07 - Metoda POPCORN flow

January 09, 2021 Sławek Łukjanow Season 1 Episode 7
Agile poza IT
#07 - Metoda POPCORN flow
Chapters
0:22
Co to i do czego?
4:18
Reguły
7:44
Kroki (litery) POPCORNu
14:12
Naciągane litery
18:43
Przykład
23:47
Podsumowanie
Agile poza IT
#07 - Metoda POPCORN flow
Jan 09, 2021 Season 1 Episode 7
Sławek Łukjanow

Czym jest POPCORN flow? To metoda na wprowadzenie, podtrzymanie i przyspieszenie ciągłej innowacji i zmiany. Dla mnie jest to bardzo dobre narzędzie do prowadzenia Retrospektyw i ogólnie do doskonalenia zespołu. To narzędzie, użyte w odpowiedni sposób, zdecydowanie poprawi tempo usprawnień w Waszych zespołach.

Show Notes Transcript Chapter Markers

Czym jest POPCORN flow? To metoda na wprowadzenie, podtrzymanie i przyspieszenie ciągłej innowacji i zmiany. Dla mnie jest to bardzo dobre narzędzie do prowadzenia Retrospektyw i ogólnie do doskonalenia zespołu. To narzędzie, użyte w odpowiedni sposób, zdecydowanie poprawi tempo usprawnień w Waszych zespołach.

OK, w takim razie czym jest POPCORN flow? Jak mówi sam autor, jest to metoda na wprowadzenie, podtrzymanie i przyspieszenie ciągłej innowacji i zmiany. Dla mnie jest to bardzo dobre narzędzie do prowadzenia Retrospektyw i ogólnie do doskonalenia zespołu. Wiele osób, mam wrażenie, stosuje tę metodę intuicyjnie. Może nie w całości, ale jej istotne elementy. Ale mam wrażenie, że jeżeli poznamy tę metodę i jeżeli będziemy w stanie wykorzystywać świadomie, to przyniesie nam to dodatkowe korzyści. Słowami autora, jeśli rozumiesz zasady, nie staniesz się zakładnikiem metody, jeżeli znasz tylko metodę, zawsze będziesz zakładnikiem metody. Zacznij stosować metodę, później zacznij doceniać zasady, a kiedy już je przyswoisz, masz swobodę wyboru metody. Tak to ładnie autor nazwał. I ma trochę racji. Chodzi o to, żebyśmy dobrze zrozumieli, na czym ta metoda polega, zresztą nie tylko ta, a potem wykorzystali ją w tych miejscach, w których będzie to miało dla nas największą wartość. I być może nawet zmodyfikowali ją tak, żeby pasowała do naszych potrzeb. 

Tutaj przywołam jeszcze coś ze Scrum Guida najnowszego - "fundamentem Scruma jest empiryzm i koncepcja lean", ale to nie o to w tym momencie chodzi, chodzi o ten empiryzm i "istotą empiryzmu jest to, że wiedza wynika z doświadczenia, a decyzje podejmowane są na podstawie tego, co można zaobserwować". I myślę, że ta metoda, POPCORN flow, jest świetnym sposobem na to, żeby potrenować empiryczne podejście do rozwiązywania problemów. Także zachęcam do spróbowania. 

Teraz może dwa słowa o twórcy metody. Nie będę specjalnie w to wchodził. Jeżeli ktoś jest zainteresowany, to może poczytać więcej. Twórcą metody jest Claudio Perrone. Mam nadzieję, że dobrze wymawiam. To jest gość, który jest w sumie od wielu lat związany z softwarem, kiedyś był programistą. No i w toku swoich prac, w toku konsultingu, stworzył metodę. Oczywiście, żeby to potem ładnie brzmiało, wymyślił jak to ładnie nazwać, stąd ten POPCORN. Też za chwilę do tego przejdę, skąd się w ogóle to wzięło. Mam wrażenie, że w niektórych miejscach to jest naciągane po to, żeby wyszedł ładny skrót, ale to za chwilę. Co ciekawe, Claudio był na konferencji ACE w Krakowie w 2016 roku i opowiadał o tym. I szczerze mówiąc nie wiem co się dzieje, dlaczego ta metoda jest aż tak mało popularna. Być może dlatego, że jest bardzo oczywista i - jak już mówiłem - wiele osób stosuje ją dość intuicyjnie. Dla mnie tak naprawdę dużą wartością w tym, co prezentuje ta metoda, a właściwie Claudio Perrone w związku z tą metodą, to są reguły i to, w jaki sposób należy działać, na co należy zwrócić uwagę. On twierdzi, że jest to związane z jego latami doświadczenia. Nawet obserwowałem, że to też się z biegiem czasu dość zmieniało i też rozwijało. Także mam nadzieję, że i wy będziecie mogli z tego skorzystać. 

I teraz ta część, którą Claudio uważa za jedną z najważniejszych, w związku z tą metodą, to są reguły. Ja je oczywiście przetłumaczyłem na polski, także nie jest to jeden do jednego to, co mówi Claudio. Mam nadzieję, że moje tłumaczenie jest wystarczająco dobre. No więc tak, pierwszy element to jest "jeśli zmiana jest trudna, uczyń ją ciągłą". To jest powiązane z metodą małych kroków i to szczególnie będzie widoczne w tej części prowadzenia eksperymentów, żeby te eksperymenty były po pierwsze prowadzone cały czas, a po drugie naprawdę wybieranie jak najmniejszych elementów, które możemy sprawdzić. Druga rzecz, to "liczy się nie tylko to, co robisz, ale także to, czego się przy tym uczysz". Mam wrażenie, że jest to reguła samotłumacząca się. Kolejna - "każdy może mieć własną opinię na jakiś temat, ale wspólna opinia jest faktem". No, powiedziałbym jest to dość kontrowersyjne, dlatego opowiem tak, jak to tłumaczy Claudio Perrone. Więc chodzi o to, że jeżeli jedna osoba uważa na przykład, że dane urządzenie jest za ciężkie, to to jest opinia, ale jeżeli wszyscy w zespole, który coś realizuje, który realizuje to urządzenie, uważają, że jest za ciężkie, no to już to traktujemy jako fakt i staramy się to jakoś rozwiązać. Kolejna reguła, to już "nie chodzi o to, żeby zawodzić szybko i zawodzić często, ale uczyć się szybko i uczyć się często". I teraz tutaj bez sięgnięcia do wersji angielskiej będzie ciężko. To też wynika z książki, która została napisana w 2013 roku przez dwóch doktorów - trudne nazwiska, nie będę nawet próbował ich wymówić. I ta książka ma tytuł "Fail fast, fail often". I tak naprawdę, jeżeli ktoś dobrze przeczyta tę książkę, to ona naprawdę dobrze opisuje to, że nie chodzi tylko o to, żeby się cały czas potykać, tylko chodzi o to, żeby się na tym uczyć. Aczkolwiek dużo osób, czytając jakieś streszczenia, bo w ogóle nawet w necie można znaleźć dużo opisów tej książki, czy tam jakichś recenzji tej książki, które właśnie dość kiepsko interpretują, o co tak naprawdę autorom chodziło. I tutaj Claudio Perrone, też odnosząc się do tej książki, zdecydowanie podkreśla tę naukę na błędach, a nie samo popełnianie błędów. "Małe zakłady, duża wygrana" - tutaj po angielsku "small bets, big payoff". Chodzi o to, żeby poszukiwać miejsc, gdzie małym nakładem w większości wypadków niewiele zyskamy, ale też niewiele stracimy, ale czasami będzie taki moment, kiedy rozbijemy bank i osiągniemy coś bardzo, bardzo wartościowego. I to wszystko jeżeli chodzi o reguły, według których należy postępować, jeżeli chcemy być w zgodzie z metodą POPCORN flow.

I teraz przejdę do tych liter, bo każda litera z POPCORNu coś oznacza. Teraz wyobraźcie sobie taką tablicę kanbanową, każda kolumna to jest jedna litera z tego POPCORNu. No i pierwsza litera to jest litera "P" - Problems and observations. Tutaj, w tej kolumnie, umieszczamy znane problemy. Tak jak mówiliśmy, jeżeli jest to jakaś opinia i być może będziemy chcieli przetestować, czy w ogóle mamy rację, że to jest coś, co komukolwiek przeszkadza - bo czasem jakimś eksperymentem może być to, żebyśmy w ogóle zapytali naszych użytkowników, czy to faktycznie jest problem. Co ważne te problemy i obserwacje powinny być spriorytetyzowane - tak coś w sumie jak Backlog - oczywiście od tych, które uważamy za najbardziej uciążliwe, do tych, które są - powiedzmy - jakimiś tam dalekimi obserwacjami, być może są to obserwacje poszczególnych osób, a nie coś, co uznajemy za pewnik. No i tutaj autor bardzo podkreśla, że najpierw musimy się zgodzić, że problem istnieje, wtedy widzimy, że są różne opcje rozwiązania tego problemu. Jak już widzimy już opcje rozwiązania tego problemu, to przychodzi nam druga litera, czyli druga kolumna kanbanowa - "O" - Options, czyli szukamy jakie mamy opcje rozwiązania danego problemu, jakieś potencjalne rozwiązania. Jakieś krótkie eksperymenty, nie każdy będzie uważał, że każda opcja pomoże, ale krótki eksperyment może rozwiać wątpliwości. Kolejna kolumna to "P" - Possible experiments, czyli jakieś możliwe eksperymenty. I one są specjalnie oddzielone od opcji po to, żeby podzielić je na jak najmniejsze kroki - powinny być tak małe, żebyśmy byli w stanie jeden eksperyment zrealizować w jednym Sprincie, a nawet kilka eksperymentów w jednym Sprincie. Co ciekawe autor proponuje, żeby nie łączyć eksperymentów w ramach jednej opcji, a nawet w ramach jednego problemu. Chodzi o to, żebyśmy nie zaburzali obserwacji wyników jednego eksperymentu drugim eksperymentem. Dlatego nawet jeżeli chcemy prowadzić więcej niż jeden eksperyment w ramach Sprintu, no to autor zdecydowanie zachęca do tego, żeby to były eksperymenty z różnych problemów, a przynajmniej z różnych opcji. Kolejna literka to "C", czyli Commited. To jest kolumna, do której przenosimy eksperymenty, które chcemy realizować, już w jakiś sposób się zgodziliśmy na to, że będziemy je realizować, no i to nie jest tak, że my już je realizujemy, tylko dopiero zamierzamy je realizować. No i kolejna kolumna - Ongoing - te, które robimy. I tutaj zdecydowanie autora zachęca do tego, żeby zachować jakiś limit Work In Progress, także jeden, dwa. Tutaj też podkreślałem to, żeby to były niezaburzone obserwacje, to powinno to być z różnych grup problemów, ale to tak naprawdę najlepiej byłoby mieć tylko jeden eksperyment i dopiero jak go zakończymy, dopiero realizować kolejny. Także tutaj bardzo zachęcam do tego, by WIPa ustawić na poziomie 1 i po prostu nawet w trakcie Sprintu, jeżeli chcemy realizować więcej takich eksperymentów, to nadal robić tak, że zrobić jeden, szybko go zakończyć, zrobić go po prostu tak małym, żebyśmy byli w stanie zweryfikować w jeden, dwa, trzy dni i potem cyk, przerzucamy się na kolejny. No i kolejna literka to jest "R", czyli Review. Robimy przegląd - patrzymy - i tutaj są podpowiedzi, są takie specjalne pytania, rzeczy, na które powinniśmy zwrócić uwagę:

  • Jakie eksperymenty zgodziliśmy się robić? - i to nie tylko ten, który aktualnie, ale ogólnie - w ramach całego problemu, czy w ramach danej opcji,
  • Jakie faktycznie wykonaliśmy?
  • Jakich wyników się spodziewaliśmy?
  • Co się faktycznie wydarzyło?
  • Czego się nauczyliśmy?
  • Na podstawie tego, czego się nauczyliśmy, co zrobimy teraz?

I ja tutaj zachęcam do tego, żeby robić to po każdym eksperymencie - myśleć o tym po każdym eksperymencie. Chociaż też wiem, że niektórzy stosują to tak, że jeżeli kończy się Sprint, to jest to jeden z elementów Review tego, danego zespołu i wtedy wszystkie rzeczy są przeglądane, wtedy to już pewnie głównie patrzymy na to, co się działo w danym Sprincie. Ale, tak jak mówiłem, jakoś bardziej chyba mi się sprawdza to, żeby patrzeć jednak po każdym eksperymencie na to, jak to jest powiązane z innymi eksperymentami z tego zagadnienia, z danego problemu, czy z danej opcji, a nie mieszanie tego, bo jesteśmy w stanie dużo więcej wyciągnąć, jeżeli będziemy jednak to grupować po problemach. No i ostatnia literka nam została z POPCORNu, czyli "N" - to jest Next - zastanawiamy się nad tym, co zrobić, jaki kolejny eksperyment, jaki kolejny problem, może jednak przechodzimy do jakiejś opcji...? No bo już wiemy, czy dany problem został rozwiązany, być może mamy jakieś nowe pomysły, na bazie tego, czego doświadczyliśmy. Więc to jest kolumna, w której będziemy się nad tym zastanawiać. 

Teraz, według mnie, dwie kolumny są trochę naciągane - bardziej pewnie pod to, żeby pasowało pod ten POPCORN. I tutaj jest kolumna "Commited". Ona jeszcze jest taką, którą można wpasować w proces, bo jeżeli mamy jakieś tam potencjalne możliwe do realizacji eksperymenty, to pewnie któreś zgodzimy się na to, żeby realizować, aczkolwiek - w większości wypadków - jeżeli mamy listę eksperymentów, to fajniej się na to patrzy jakie są opcje i dopiero w momencie, kiedy przechodzimy do tego Ongoing, dopiero wtedy zastanawiamy się nad tym, które chcemy realizować. Bo prawda jest taka, że jeżeli na przykład zrealizujemy jeden eksperyment i wracamy do tego, to że mamy ileś sztuk w Commited, to nauczeni nowymi doświadczeniami, zapewne będziemy jednak chcieli wziąć pod uwagę wszystkie opcje, być może nawet je rozbudować o kolejne. Także to Commited mam wrażenie jest troszkę naciągane. Kolejna rzecz - "Review". I teraz, jeżeli ktoś pracuje tak, że te eksperymenty będzie przeglądał dopiero na Review, bo dopiero po jakimś czasie, jeżeli tych eksperymentów się zbierze, no to ta kolumna ma sens. Bo wiadomo, one tam czekają, dopóki ich nie omówimy, no to jakoś musimy wiedzieć, które zostały zakończone, a które są w trakcie. Ale jeżeli ktoś robi tak, że po każdym eksperymencie analizuje, to - powiedzmy sobie szczerze - nie jest to najważniejsza rzecz. Kolejna kolumna to jest "N", to jest Next i ona też tak naprawdę, co tutaj można w tej kolumnie zrobić - jeżeli mamy tę karteczkę (czy jakiś zestaw karteczek), która wędruje po tych kolumnach, to już raczej średnio będzie zastanawiać się, to już raczej w ramach Review jest zastanawianie się, co z tym dalej zrobimy. Ewentualnie, czy przechodzimy do kolejnej opcji, czy przechodzimy do kolejnej obserwacji. Tu bardziej brakuje mi kolumny, w której mam historię tego, co się działo, w ramach danego problemu. I ja tak tę kolumnę - Next - traktuję. Także nie jest to dla mnie Next, tylko bardziej jest to kolumna Done. I przynajmniej można wrócić do tego, jakie eksperymenty zrealizowaliśmy w ramach danej opcji i jakie opcje poruszyliśmy w ramach danego problemu. 

Jeżeli mamy na to miejsce, to warto w ogóle je grupować w taki sposób, żeby na pierwszy rzut oka było widać, że po lewej stronie jest jakiś jeden problem, wygenerowaliśmy do niego ileś opcji i teraz - jeżeli mamy do tego jakieś eksperymenty, to one też powinny być w jednej linii z daną opcją, po to, żeby łatwo było wrócić do tego i kontynuować. To się szczególnie przydaje na tym etapie, kiedy zrealizowaliśmy jakiś eksperyment, no i niestety okazało się, że co prawda czegoś się nauczyliśmy, ale to nie jest rozwiązanie, które powinniśmy stosować docelowo. I szybkie spojrzenie na to, od razu daje pogląd, co jeszcze teraz szybko możemy zrobić i którą opcję lub który eksperyment wybrać. To niestety nastręcza trochę problemów, chyba że robimy to w jakimś narzędziu. Ja niestety nie mam do tego żadnego narzędzia. Do tego fajnie przydają się karteczki. Ale na przykład już w Muralu można całymi grupami to sobie zaznaczać i przenosić. Polecam tego typu narzędzia, bo z karteczkami fizycznymi, no niestety, jest dość upierdliwe. 

No i teraz może jakiś przykład. Załóżmy, że mamy tego typu problem - "zależność od podwykonawców powoduje, że nie zawsze udaje się osiągnąć Cel Sprintu". Teraz jakieś opcje - zastanawiamy się, co możemy zrobić, żeby ten problem rozwiązać. Załóżmy, że opcje są takie:

  1. Rozwijamy technologie i umiejętności w zespole ,
  2. Ograniczamy się do technologii, które już mamy,
  3. Daną pracę zaczyna wykonywać inny zespół, który ma wiedzą i możliwości,
  4. Nie bierzemy na Cel Sprintu niczego, co jest zależne od podwykonawców - no taka bym powiedział trochę sztuczka,
  5. Szukamy wielu podwykonawców tej technologii i wybieramy tego, który ma najkrótszy czas realizacji,
  6. Prace z podwykonawcami planujemy wcześniej i zawczasu bookujemy terminy.

Rozmawiając w zespole okazało się, że jedni uważają, że najlepszą opcją będzie szukanie wielu podwykonawców w tej technologii i wybranie tego, który ma najkrótszy czas realizacji. No a inni z kolei byli raczej za opcją, żeby prace z podwykonawcami planować wcześniej i zawczasu bookować terminy.

Załóżmy, że nie byliśmy w stanie zgodzić na to, która opcja jest najlepsza, więc stwierdziliśmy, że sprawdzimy jedną i drugą. Stwierdziliśmy, że przetestujemy te dwie opcje, czyli szukania wielu podwykonawców danej technologii i prace z podwykonawcami planowaną wcześniej. Więc przekształciliśmy to na możliwe eksperymenty. I tutaj jednym to będzie - "przy następnym frezowaniu w stali nierdzewnej - wybranie ofert od różnych firm i wybranie tej z najkrótszym czasem", a jeżeli chodzi o planowanie wcześniej, to że "przy następnym vacuum castingu, jak tylko wiemy, że będzie taka praca, to dogadujemy z podwykonawcą na termin". No i od razu zdecydowaliśmy, żeby najpierw zrealizować ten pierwszy eksperyment. Wzięliśmy go na Sprint. No i co się okazało? Okazało się, że jeżeli chcemy coś na najkrótszy termin - na jakiś super-ekstra termin, to okazuje się, że jest to dużo droższe, a co więcej - psujemy sobie relacje, które zbudowaliśmy z naszymi podwykonawcami, z którymi współpracowaliśmy do tej pory. Dlatego potem okazuje się, że nie dość, że od tych, z którymi do tej pory współpracowaliśmy, mamy gorsze stawki, to - wiadomo - jeżeli oni się dowiadują, że trochę tu popracujemy, trochę jednak z innymi itd., to możecie się domyślać, że ta relacja ulega zdecydowanemu pogorszeniu - nie jest coś takiego, że potem - z dnia na dzień - możemy poprosić o coś super-ekstra, super-pilnego i traktować się jak prawdziwych partnerów w biznesie.

Po zrealizowaniu tego, wiemy już, że nie chcemy tej opcji, jest ona dla nas nieakceptowalna, zdecydowaliśmy się, żeby sprawdzić kolejną opcję. No i to jest eksperyment, który mówił o tym, że przy vacuum castingu, którego trochę stosujemy, jednak pomyśleć o tym trochę wcześniej i dogadać się z podwykonawcą na termin. No i wzięliśmy to na któryś Sprint. I co się okazało...? Że to planowanie wcale nie jest aż tak proste, takie planowanie bardzo do przodu, aczkolwiek przyniosło to zamierzony skutek, byliśmy zadowoleni z tego. Podwykonawca - dalej współpracujemy z tym samym, więc to jest dalsze budowanie relacji. No i - co ciekawe - kwota zdecydowanie niższa, jeżeli można to było zaplanować i nie było to na ASAPie. Także tutaj trzeba od razu powiedzieć, że zaczęliśmy się zastanawiać nad tym, jakie kolejne eksperymenty możemy zrealizować, idąc kierunku tej opcji. Bo, mimo wszystko, to planowanie takie bardzo do przodu takie banalne nie było. I nawet, jak się już dowiadywaliśmy o tym, że coś chcemy wykonać, to prawda jest taka, że potrzebowaliśmy tego na już.

No i w ten sam sposób możemy przechodzić przez kolejne eksperymenty, kolejne opcje i kolejne problemy i obserwacje. I w ten sposób po pierwsze się czegoś uczyć, po drugie w ten sposób się rozwijać. 

To jest właśnie podstawa prawdziwego empiryzmu. I do tego powinniśmy dążyć!

Co to i do czego?
Reguły
Kroki (litery) POPCORNu
Naciągane litery
Przykład
Podsumowanie