Dlaczego empiryzm? Bo jak pokazujemy zarówno na naszym kanale na YouTube, jak i na tym blogu – zbyt wiele nam się wydaje. Wysnuwamy teorie na podstawie niesprawdzonych danych albo staramy się dopasować fakty do naszych przekonań. A gdyby tak pójść z duchem agile i stosować tylko to, co sprawdza się w praktyce?
Empiryzm, czyli co?
W odróżnieniu od racjonalizmu i sceptycyzmu, empiryzm zakłada, że głównym (lub jedynym) źródłem naszej wiedzy są bodźce które do nas docierają. Mówiąc inaczej: teorie i idee budujemy na podstawie tego, co się dzieje. A to z kolei mamy okazję obserwować naszymi zmysłami.
W empiryzmie teoria jest na samym końcu, a oparta jest o badania i analizy. Schodząc na ziemię – nie zakładamy z góry tego, jak byśmy sobie życzyli, żeby świat działał, ale najpierw działamy, a potem wyciągamy wnioski z rezultatów.
„Teoria jest wtedy, kiedy wiemy wszystko, a nic nie działa! Praktyka jest wtedy, kiedy wszystko działa, a nikt nie wie dlaczego. W tym pomieszczeniu łączymy teorię z praktyką. Nic nie działa i nikt nie wie dlaczego.” – prof. Jan Miodek
Ma to wiele wspólnego z podejściem obserwowanym w domenie złożonej Cynefin Frameworku, ale także z agile mindsetem czy w ogóle – podejściem zwinnym. Praktyka zdecydowanie liczy się bardziej niż teoria.
I podobnie jak nie ma jednego przepisu na „bycie agile”, tak i empiryzm empiryzmowi nierówny. Zajmijmy się więc jego scrumowym wariantem.
Empiryzm w Scrum
W materiale źródłowym o metodyce Scrum mamy jasno i wyraźnie powiedziane, że jest on oparty o empiryzm (ang. empiricism). Trudno jest kłócić się z tak jasnym stwierdzeniem:
„Scrum is founded on empirical process control theory, or empiricism. Empiricism asserts that knowledge comes from experience and making decisions based on what is known.” – Scrum Guide
Opierając się o nasze rozumienie agile mindsetu, wydaje się to trafiać w punkt. Opierając się o to, co jest nam znane podejmujemy decyzje i działania. Na podstawie rezultatów zdobywamy wiedzę o tym, jak to działa w praktyce. Jest to nic innego, jak zwinny eksperyment.
Scrum to przecież nieustanne dostosowywanie procesu wytwórczego do naszych wyjątkowych warunków. Każdy zespół i każda organizacja są inne. To, co świetnie sprawdza się w jednym przypadku, w innym może być destrukcyjne. Musimy więc nieustannie weryfikować, czy dobrze sobie radzimy i czy nie jesteśmy w stanie tego robić lepiej.
Empiryzm w Scrum widoczny jest zarówno w spotkaniach pokroju Sprint Retrospective czy Sprint Review, ale także w jawności artefaktów takich jak backlogi czy Inkrement. Nie mają dla nas większego znaczenia rzeczy, które „prawie się zadziały”, ani wymagania „prawie skończone” (niezgodne z Definition of Done). Te nie przybliżają nas do celu.
Skupienie się na planach, prognozach czy teoretycznych aspektach tworzenia oprogramowania lub interakcji międzyludzkich może przynieść więcej szkody niż pożytku. W idealnym świecie motywacja naszych współpracowników byłaby zawsze pozytywna i ukierunkowana na sukces zespołu. Niestety, jak pokazuje praktyka często ludzie działają samolubnie.
Zamiast złościć się na to, jak świat działa, empiryzm mówi „przyjmij to z dobrodziejstwem inwentarza”. Większy sukces osiągniemy działając zgodnie z zasadami „złego” świata, niż łudząc się, że funkcjonuje on zgodnie z naszymi wyidealizowanymi wyobrażeniami.
Pozytywna strona empiryzmu
Poprzednie akapity mogły zabrzmieć pesymistycznie, ale trzeba pamiętać, że w #białko jesteśmy przede wszystkim realistami. Jeśli coś jest mniej niż idealne, to należy szukać w tym szansy, a nie narzekać na zły los.
Empiryzm daje nam potężne narzędzie do ręki: nasze doświadczenia. Coś, co empirycznie sprawdza się w naszym przypadku, niekoniecznie musi zaraz stanowić ogólną teorię. Z drugiej jednak strony – co nas interesują takie teorie, skoro liczy się praktyka tu i teraz?
Mówi o tym Cynefin framework w kontekście domen złożonych i chaotycznych. Nie możemy a priori stwierdzić, jaki będzie rezultat naszych działań, musimy sprawdzić to w praktyce. Ślady takiego podejścia znajdziemy też chociażby w Cyklu Deminga, gdzie pętla zwrotna powstała po to, żeby uwzględnić różnice pomiędzy teorią, a praktyką.
Metodyka Scrum, reprezentant podejścia zwinnego, oparty jest przecież na trzech filarach: transparentności oraz inspekcji i adaptacji. To właśnie te dwa ostatnie „filary” mówią o tym, że musimy spoglądać wstecz, żeby przekonać się czy nasze zmiany przyniosły spodziewane rezultaty. To znaczy, że z góry zakładamy, że możemy się pomylić i dopiero praktyka powie nam, czy mieliśmy rację.
Empiryzm – warunki konieczne
Istnieje kilka koniecznych warunków do skutecznego wykorzystania empiryzmu. Jednym z nich jest wspomniana już wcześniej transparentność. Bez niej nie będziemy wiedzieli co tak naprawdę się dzieje na naszym projekcie. Możemy wtedy podejmować decyzje w oparciu o fałszywe przesłanki.
Ale nawet przy absolutnej przejrzystości, jeżeli nasze pomiary są zaburzone albo gdy mierzymy nie to co trzeba, możemy sami sobie zaszkodzić. I to pomimo najlepszych chęci! Mówiliśmy już o tym na YouTube w filmie Pomiary kontra intucja, a także omawiając Prawo Goodharta, a nawet mierzenie Velocity.
Jak więc nie pogubić się przy stosowaniu empirycznego podejścia? Przede wszystkim należy maksymalnie uprościć to, co analizujemy. Próbowanie odnalezienia zależności w skomplikowanym systemie jest z góry skazane na porażkę. Zamiast tego wróćmy do podstaw.
Dlaczego pojawiły się te błędy? Dlaczego nie udało się dowieźć tego wymagania? Z jakiego powodu borykami się z ciągłymi broken buildami? Czemu trzeci sprint z rzędu planujemy więcej niż jesteśmy w stanie zrealizować? Ale także – czemu te User Story skończyliśmy dwa razy szybciej? Dlaczego nie wiedzieliśmy, że ta funkcjonalność jest już w systemie i wystarczy ją włączyć? Czy zmiany wprowadzone w ostatnim Sprincie w tym zespole nie mogłyby być przeniesione na cały projekt?
Odpowiedzi na te proste pytania mogą prowadzić do usprawnień, które przecież możemy wdrożyć co Sprint. Ale skąd będziemy wiedzieli, czy przyniosą one korzyści? Empirycznie sprawdzimy to na następnym Sprint Retrospective, analizując rezultaty.
A jeśli się pomyliliśmy, to tak samo szybko będziemy mogli się z tej decyzji wycofać. Nie zapomnijmy tylko sprawdzić, czy powrót do poprzedniego podejścia faktycznie coś zmienił.
