.st0{fill:#FFFFFF;}

Fail Early, Fail Often to marketingowa bzdura 

 4 lipca, 2019

Tomasz Dzierżek

Od początku mojej przygody z agilem bardzo często od bardzo różnych ludzi słyszałem mantrę „Fail Early, Fail Often.” Oczywiście nikomu nie chodziło o to, żeby prowokować porażki, ale to powiedzenie bywa źle rozumiane. A nawet jeśli intencje są dobre, to jego nadużywanie prowadzi do zupełnie odwrotnego efektu.

 

Do Not Fail Early, Fail Often

Koncepcja „Fail Early, Fail Often” ma przede wszystkim zachęcić do popełniania błędów w pierwszych fazach naszego przedsięwzięcia. Wtedy koszt pomyłek jest mały, a szanse na ich bezbolesne naprawienie – duże. Mówiąc obrazowo, o wiele łatwiej jest nam zmienić średnicę lin podtrzymujących most na etapie projektu, a dużo trudniej na etapie realizacji.

„Fail early, fail often, but always fail forward.” – John C. Maxwell

Ogromnym założeniem koncepcji „Fail Early, Fail Often” jest kolejne powiedzenie, czyli „co nas nie zabije, to nas wzmocni”. A konkretniej chodzi o to, żeby nasze błędy nas po prostu nie zabiły. To nie jest tak, że mamy mylić się na każdym kroku. Nie powinniśmy działać głupio, bez przemyślenia albo bez przygotowania. Jeżeli da się uniknąć błędów, to ich unikajmy. Kłopot w tym, że bardzo często nie mamy na to szans.

Każdy kto kiedykolwiek pisał jakieś oprogramowanie wie, że nie da się po prostu usiąść i napisać skomplikowanego kodu. Każdy programista co chwilę uruchamia swoje dzieło po to, aby przekonać się czy jest ono wolne od błędów (zwykle nie jest) i czy działa tak jak należy (zwykle nie do końca).

Jeżeli już musimy popełniać błędy, to oczywiste jest, że powinny one mieć miejsce wcześnie (early). Tylko po co mamy mylić się często (often)? W założeniu po to, aby jak najwięcej pomyłek popełnić jak najwcześniej i nie zostawiać ich na później.

I chociaż ta idea jest słuszna, to nie przemawia do mnie celowanie w popełnianie błędów. Takie nastawienie może spowodować, że – świadomie lub nie – będziemy poszukiwać dróg, które wyprowadzą nas na manowce.

A przecież nie o to chodzi.

 

Fail Fast?

Ryan Babineaux i John Krumboltz w swojej mocno krytykowanej książce zasugerowali bardzo podobną strategię. Rozdmuchali ją jednak do absurdalnych rozmiarów i dodali prowokacyjny przypisek „How Losing Can Help You Win”. Całość ich podejścia zawiera się w tytule książki. Samą pozycję nieszczególnie jesteśmy w stanie polecić, ale i tak dziś znęcać się będziemy nad jednym zdaniem.

„Fail Fast, Fail Often: How Losing Can Help You Win” – Ryan Babineaux, John Krumboltz

Oczywiście, że „porażki” mogą pomóc nam wygrać. Pod warunkiem, że nauczymy się z nich czegoś, wyciągniemy wnioski i – co najważniejsze – będziemy ich unikać w przyszłości. Skoro żeby osiągnąć sukces musimy unikać porażek, to może jednak wcale one nie są dla nas takie dobre?

Autorzy twierdzą, że ludzie sukcesu więcej eksperymentują, więcej próbują oraz popełniają więcej pomyłek. Nic w tym dziwnego – im więcej rzeczy spróbujemy, tym więcej porażek odniesiemy. Ale też im więcej wykonamy prób, tym większa szansa, że w końcu nam się uda. I to rozumowanie przyjmuję w całości. Natomiast nie powiedziałbym, że samo dążenie do porażek ma jakąkolwiek wartość. Jeżeli już, to bądźmy szczerzy – „Expriment Fast, Experiment Often”.

Czyż nie lepiej byłoby zrobić wszystko dobrze za pierwszym razem i po prostu osiągnąć sukces? Oczywiście takie podejście na kilometr śmierdzi perfekcjonizmem. Jeśli spróbujemy się idealnie przygotować, to zmarnujemy mnóstwo czasu na przygotowania, a jak pokazuje praktyka – i tak nie przewidzimy wszystkiego. A nawet jeśli nam się uda zabezpieczyć na każdą okoliczność, to będziemy działać bardzo wolno.

Czy to znaczy, że „Fail Early, Fail Often” jest bez sensu? Nie, ale sformułowane w ten sposób propaguje bardzo zły mindset.

 

Odwrotność Fail Early, Fail Often

W tym miejscu z pomocą przychodzą nam: zdrowy rozsądek oraz pragmatyzm. Ten ostatni mówi nam, że powinniśmy podejmować tylko te działania, które faktycznie mają szanse na powodzenie. Nie pchajmy się bez sensu w stronę porażek, za to zdecydowanie dążmy do szybkich, małych sukcesów.

Odwrotnością „Fail Early, Fail Often” nie jest „Fail Late, Fail Rarely”, ale „Succeed Early, Succeed Often”. I taka mantra przede wszystkim skieruje nas w stronę, na której nam najbardziej zależy – osiąganiu sukcesów. A w przypadku naszej branży, przy okazji opisuje też iteracyjne podejście do tworzenia oprogramowania.

Jeżeli chcemy szybko osiągać sukcesy, robić „rozpoznanie bojem”, unikać największych porażek oraz minimalizować koszt naszych błędów, to powinniśmy pracować jak najmniejszymi etapami. Można mówić o iteracjach, Sprintach – szczegóły nie są istotne. Ważne jest, żebyśmy jak najszybciej nauczyli się jak najwięcej.

Tylko znów, błagam, nie nastawiajmy się na „Fail Early, Fail Often”! Dążmy do sukcesu, mając pełną świadomość tego, że po drodze i tak nie raz się potkniemy. Słynna gotowość na porażkę jest przecież nieodłącznym elementem agile mindsetu. A o tym piszemy, mówimy i opowiadamy od bardzo dawna.

„Mądry człowiek uczy się na swoich błędach. Sprytny człowiek uczy się na cudzych błędach. A głupi nie uczy się wcale i wciąż popełnia te same błędy, licząc na inny rezultat.”

Wyciągajmy wnioski z naszych porażek. Bez tego nigdy nie staniemy się lepsi, a każdy mindset i tak prędzej czy później wyjdzie nam bokiem. Im trudniejsze rzeczy robimy, tym częściej będziemy się mylić. Zapewnijmy więc sobie poduszkę bezpieczeństwa. Niech nasze błędy nas nie zabiją, tylko faktycznie wzmocnią i nauczą czegoś na przyszłość.

Tylko nie nastawiajmy się na celowe popełnianie błędów, bo wtedy na pewno je sprowokujemy. Więc dlaczego by nie zacząć myśleć „Succeed Early, Succeed Often”?

Tomasz Dzierżek


21+ lat doświadczenia w IT, 13+ lat doświadczenia w Scrum i agile, PSM I-III, konsultant zwinnych procesów i zespołów, Agile Coach, trener

Your email address will not be published. Required fields are marked

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.

{"email":"Email address invalid","url":"Website address invalid","required":"Required field missing"}