Prezentyzm – termin, na który wpadłem, zapewne podobnie jak i ty, przez całkowity przypadek. Może on nam pomóc w każdej dziedzinie naszego życia – od analizy wydatków z wakacyjnego wyjazdu, który odbył się 2 lata temu, po retrospekcję minionego sprintu.
Prezentyzm – co to właściwie oznacza?
Prezentyzm, mimo że odkryty przeze mnie zaledwie kilka miesięcy temu, nie jest niczym nowym. Po raz pierwszy pojawił się w literaturze fachowej w latach 20 XX wieku, a więc jest to już teoria z tradycjami.
Prezentyzm (z łac. praesens „obecny” i gr. ismos „wiedza”) – kierunek analizy historycznej polegający na ocenie zdarzeń, faktów, poglądów i ocen z przeszłości ze współczesnej perspektywy – Wikipedia
Prezentyzm wyrósł z nurtu, który jest popularny w metodykach zwinnych, czyli pragmatyzmu. Termin ten możemy rozumieć jako ulubione przez nas „pozytywne lenistwo” charakteryzujące się realistyczną oceną rzeczywistości i stawianiu na te minimum działań, które przyniosą najwięcej korzyści.
Co oznacza prezentyzm w kontekście Scruma i prowadzenia projektów metodykami zwinnymi? Może każdy z nas wykorzystuje go już dzisiaj nie zdając sobie z tego sprawy? Czy analizę przeszłości z punktu widzenia teraźniejszości powinniśmy traktować jako pozytywną czy negatywną?
Wszystko się zmienia
Scrum został opracowany w celu wsparcia skomplikowanych projektów i w takim też celu jest wykorzystywany. Projekty te charakteryzują się, między innymi, częstymi zmianami które znajdują swoje odzwierciedlenie w ciągle aktualizowanym Backlogu Produktu. Czy istnieje zatem możliwość analizy zdarzeń z przeszłości z punktu widzenia tego, jak nasz projekt wygląda w dniu dzisiejszym? Ponieważ lubimy dziwne przykłady, to posłużymy się zmianami siły nabywczej pieniądza na przestrzeni lat w Polsce.
Próbując dokonać analizy danych dotyczącej liczby kilometrów możliwych do przejechania taksówką za średnią krajową w wybranych latach zaobserwujemy następujące wartości: w roku 1995 za średnią krajową można było przejechać 550 km, w roku 2000 – 800 km ale już w roku 2012 było to aż 1100 km.
Weryfikując powyższe dane z punktu widzenia roku 2018 nie możemy jednoznacznie stwierdzić, z czego wynika przyrost ilości przejechanych kilometrów. Nie wiemy czy zmieniły się ceny paliwa, samochody stały się bardziej ekonomiczne czy np. zmniejszyły się korki na ulicach. Nie jesteśmy w stanie wskazać przyczyn zmian bez przeniesienia się do przeszłości i sprawdzenia ówczesnych warunków.
Podobnie rzecz ma się z naszym projektem, w którym praca w krótkich iteracjach powoduje ciągłe zmiany. Po czasie nie będziemy w stanie powiedzieć, które z aspektów (negatywnych lub pozytywnych) wpłynęły na taki a nie inny wynik realizacji Backlogu Sprintu. Nie ma tutaj znaczenia, czy historia naszego projektu znajduje się w narzędziu elektronicznym czy na kartce papieru – nikt nie będzie porównywał i weryfikował wszystkich zmian, żeby po czasie wyciągać z nich wnioski.
Odkładanie retro
W popularnym poście o Broken Window Theory pisałem o psuciu Scruma poprzez rezygnację z Retrospektywy Sprintu. Z punktu widzenia Zespołu Deweloperskiego odkładanie tego spotkania może spowodować, że nie uda się nam poprawić negatywnych aspektów funkcjonowania naszej machiny o nazwie Scrum.
Prezentyzm jasno mówi, że analiza przeszłych zdarzeń z dzisiejszego punktu widzenia może nie doprowadzić nas do prawidłowych wniosków.
Przeanalizujmy następujący przypadek: w sprincie -1 nie udało się nam dowieźć żadnego z zaplanowanych wymagań. W bieżącym sprincie udało się nam dowieźć 90% zaległych wymagań oraz 75% zaplanowanych pierwotnie do realizacji. Zespół chciał uniknąć narzekania i po sprincie -1 nie odbyło się spotkanie Sprint Retrospective.
Odłożenie tego spotkania nie spowoduje, że będzie lepiej. Nie dokonawszy analizy zaraz po zakończeniu sprintu spowodowaliśmy, że uciekła nam możliwość przyjrzenia się „na żywo” temu, co się wydarzyło. Co więcej, patrząc z perspektywy bieżącego sprintu z dużą dozą prawdopodobieństwa można przypuszczać, że członkowie naszego zespołu nie przypomną już sobie o negatywnych wydarzeniach z przeszłości. I nie muszę nikogo przekonywać, że jest to droga donikąd.
Skąd wiemy co wydarzy się w kolejnym spricie? Czy problemy ze Sprintu -1 nie powrócą?
Jeśli jednak spróbujemy…
Co jeśli jednak spróbujemy ocenić teraźniejszość z punktu widzenia przeszłości? Są sytuacje w których nie będziemy mieli innej możliwości. Przykładem może być budżet naszego projektu czy próba oszacowania złożoności wymagania, które realizowaliśmy wcześniej.
Ponieważ mamy dostępne jakieś dane z przeszłości, możemy się na nich oprzeć. Oznacza to, że z punktu widzenia dnia dzisiejszego jesteśmy w stanie sięgnąć po wcześniejsze lub długoterminowe dane. Może się nawet okazać, że dużo się nie pomylimy.
Wszystko jak zwykle zależy od kontekstu i od tego, w jakim celu wykorzystujemy nasze dane. Scrum został opisany na 18 stronach właśnie po to, aby wykorzystać go we właściwy dla nas sposób. I to mi się właśnie w nim bardzo podoba. Można by wręcz powiedzieć, że został stworzony dla ludzi myślących i kreatywnych. Tylko oni będą to w stanie wykorzystać w sposób przynoszący im najwięcej korzyści biznesowych.
Jak to właściwie jest z tym prezentyzmem
Istnieje szereg sytuacji, w których nie ma ucieczki przed prezentyzmem. Nie mamy przecież możliwości przeniesienia się w czasie do przeszłości, aby np. przeanalizować przyczyny rozstania się z dziewczyną/chłopakiem, o którego/którą staraliśmy się kilka lat temu. W takim przypadku pozostaje nam jedynie możliwość oceny tamtych wydarzeń z punktu widzenia teraźniejszości. Ocena ta może być nieprawdziwa, prawdopodobnie zaszło w nas bardzo wiele zmian które spowodują, że nie wyciągniemy prawidłowych wniosków.
Błąd poznawczy, który opisuje przypisywanie naszemu dawnemu „ja” dzisiejszej wiedzy i motywacji to Consistency bias (lub Self-consistency bias).
Podobnie rzecz ma się z maszyną o nazwie „Scrum”. Jeśli nie dokonamy retrospekcji na bieżąco, jeśli nie podejmiemy wysiłku znalezienia przyczyn sukcesu lub niepowodzenia zaraz po jego wystąpieniu, z dużą dozą prawdopodobieństwa nie znajdziemy ich prawdziwej przyczyny.
Czy możemy sobie na to pozwolić w iteracyjnym podejściu do tworzenia oprogramowania? Czy mamy czas, aby dwa razy popełniać te same błędy? W Agile Mindset zawiera się gotowość na porażkę, ale czy powinniśmy tę porażkę sprowadzać na siebie celowo, przez zaniechanie poprawy?
