Porażka napędza, sukces stopuje

Nie jestem zwolennikiem teorii o konieczności przewrócenia się, aby się czegoś nauczyć. Po co się narażać się na otarcia i rany, gdy możemy pomóc sobie doświadczeniem innych osób? Nie da się jednak ukryć, że niepowodzenie ma większe oddziaływanie na nasze działania niż sukces. Spróbuję dziś udowodnić, że porażka napędza, sukces stopuje.

 

Kraina miodem i mlekiem….

Nie pamiętam, czy uczestniczyłem kiedyś w przedsięwzięciu, które od początku do końca było pasmem samych sukcesów. Tym bardziej trudno wyobrazić mi sobie, że taka sytuacja w ogóle może mieć miejsce. Zawsze będziemy mieli do czynienia z sytuacjami niepożądanymi, które będą wpływały na powodzenie naszego działania. Zmiany kadrowe, zawirowania budżetowe czy nowe, wcześniej nieznane wymagania to tylko część z nich.

Jeśli pracując nad projektem wydaje się wam, że są rzeczy do poprawy, a z drugiej strony widzicie mowę sukcesu, to musicie też wiedzieć, że coś jest na rzeczy. Może macie styczność z Watermelon project, gdzie na zewnątrz wszystko z pozoru jest jak powinno, w środku widać już pierwsze symptomy problemów? Nie, nie jest to normalna i oczekiwana sytuacja, nie tak powinna wyglądać praca w zwinnym projekcie.

Czy istnieją miejsca, gdzie wszystko idzie zgodnie z planem? Aby tak było musiałoby dojść do nieprawdopodobnego splotu wielu wydarzeń. Takie rzeczy raczej się nie dzieją!

 

Porażka

Porażka nie jest niczym złym. Jest stanem, w który owszem, nie wyszło nam, ale cała sytuacja powinna dać nam co najmniej materiał do przemyśleń. W zwinnych metodykach częstotliwość porażki znacząco wzrasta. W końcu weryfikacja naszych prac ma miejsce w krótkich cyklach, w Scrumie zwanych Sprintami. Jak nam nie idzie, mamy pecha. Czy to oznacza, że pochwalam porażki? Przecież wyżej napisałem, że nie jestem ich zwolennikiem!

Z drugiej strony te krótkie cykle dają nam pewną przewagę. Osobiście upatruje w nich, podobnie jak inni, możliwości szybkiej zmiany kierunku. Interesuje nas oczywiście kierunek na sukces. Bez tej częstotliwości nasza droga ku sukcesowi jest do samego końca niepewna. Pracowaliście kiedyś przy produkcie, który nie został wdrożony? To właśnie przykład negatywnego efektu braku informacji zwrotnej.

Kiedy wolelibyście dowiedzieć się o błędach – w momencie, gdy koszt ich poprawy jest przewidywalny i relatywnie niski czy później, gdy jest wysoki lub wręcz skazuje nam całe przedsięwzięcie na porażkę? Myślę, że wybór jest oczywisty, choć są ludzie, którzy wolą brnąć w błędne rozwiązania w pozornej niewiedzy. Zwracam uwagę na słowo “pozornej”.

 

Pochwalanie porażek

Dawno temu, podczas jednego ze szkoleń ktoś zapytał mnie dlatego wspieram, pochwalam i akceptuję porażki. Czy nie widzę zagrożenia, że przyzwolenie na nieudane Sprinty zagrozi końcowemu sukcesowi projektu? Przyznacie, że pytania te są aktualne i dziś. Pewnie wielu z Was się nad tym zastanawia:

“Pozwolić Deweloperom upaść, aby się czegoś nauczyli czy dbając o dobro prac nad Produktem wyprzedzić zbliżającą się katastrofę?”

Załatwianie wszystkiego za Deweloperów nie jest dobrym rozwiązaniem. Brak klarownej informacji o porażce nie jest jednoznaczny z jej brakiem. W miejscach, gdzie zwinność jest tylko na papierze malowanie trawy na zielono wchodzi na nowe poziomy. Wolicie wiedzieć i móc podjąć trudną decyzję czy nie wiedzieć i zdziwić się na sam koniec? Ja jestem zdecydowanym zwolennikiem pierwszej opcji, choć przyznaję, że czasem jest to trudne.

Zwolennicy drugiej opcji myślą, że jakoś to będzie. Cierpi na tym jakość produktu, cierpi często PR firmy, cierpią relację z Interesariuszami. Odbudowanie tych aspektów jest bardzo trudne, a często wręcz niemożliwe.

 

Porażka napędza, sukces stopuje

Nie pochwalam porażek, co więcej empatycznie rozumiem ludzie, którzy od nich stronią. Dbają oni (w ich mniemaniu) o dobro Produktu. Tylko czy na pewno tak właśnie jest. Czy zamknięcie oczu powoduje, że czegoś nie ma?

Porażka jest szansą dla Scrum Teamu na uniknięcie powtarzania cały czas tego samego błędu. Jego wykrycie na wczesnym etapie występowania daje nam większe szanse na naprawienie przy ograniczeniu szkód do minimum. Jeśli nie damy sobie przestrzeni na porażki, nigdy nie uda nam się wypracować sposobu pracy przybliżającego nas do sukcesu. Osoba odpowiedzialna za błąd, czasem wręcz za porażkę całego projektu zmieni pracę (dziś nie jest to przecież trudne), a my zostaniemy na tonącym okręcie, niczym orkiestra na Titanicu.

Jak wszędzie tak i tym przypadku trzeba poszukać złotego środka. Jeśli porażek jest za dużo musimy się tym zainteresować. Poruszaliśmy ten temat już we wpisie “Fail Early, Fail Often“. Dzieje się prawdopodobnie coś złego, z czym powinniśmy zawalczyć. Mamy ku temu narzędzia, mowa chociażby o Retrospekcji. Skorzystajmy z niej, aby znaleźć przyczynę porażki i ją wyeliminować. Kto to powinien zrobić? Oczywiście członkowie Scrum Teamu, to im zależy najbardziej na sukcesie.

Sukces jest dobrym i pożądanym zjawiskiem. Nie pozwólmy jednak, aby zamydlił nam oczy i doprowadził do porażki stopując rozwój naszego Produktu.

Łukasz Bręk

15 lat doświadczenia w IT, 8 lat doświadczenia w metodykach zwinnych, PSM, PSPO, Scrum Master zespołów zwinnych, Product Owner, analityk biznesowy/systemowy, Agile Coach, trener Scrum. Swój warsztat szlifował na projektach waterfallowych, dziś skupiony wokół zwinnego dostarczania Produktu.

Click Here to Leave a Comment Below

Leave a Reply: