Nie bez przyczyny pierwszy post na blogu będzie dotyczył empiryzmu. Jest on bowiem fundamentem dla wszystkich metod zwinnych, w tym również dla Scruma. Bez dobrego zrozumienia tego zagadnienia oraz podążania z jego duchem, nie ma mowy o prawdziwej zwinności.
Zacznijmy od teorii
Zacznijmy od tego czym jest empiryzm. [1] Z greckiego émpeiros, czyli ‘doświadczony’. Jest to filozofia, która głosi, że poznanie ludzkie wynika z doświadczenia zmysłowego, zewnętrznego lub wewnętrznego. Przeciwstawiana jest racjonalizmowi, który wywodzi poznanie z rozumu.
[2] Jeżeli założymy, że wiemy jedynie to czego doświadczyliśmy, to znaczy, że nie możemy przewidzieć przyszłości, a jedynie pewna jest przeszłość. Najstarsze znane człowiekowi metody poznania świata opierały się na empirycznym podejściu. W podejściu tym budowane są hipotezy, przeprowadzane doświadczenia, dokonywane obserwacje i zbierane są dane, z których na koniec wyciąga się wnioski. To wszystko pozwala potwierdzić lub obalić hipotezę, dostarczając wiarygodnej wiedzy na temat otaczającego świata rzeczywistego.
Empiryzm w „Przewodniku po Scrum”
Już na samym początku rozdziału „Teoria Scruma” w „Przewodniku po Scrumie” (ang. Scrum Guide) [3] czytamy: „Fundamentem Scruma jest empiryzm i koncepcja lean. Istotą empiryzmu jest to, że wiedza wynika z doświadczenia, a decyzje podejmowane są na podstawie tego, co można zaobserwować.” Jest to kluczowe zagadnienie, które trzeba zrozumieć, ponieważ cały Scrum zbudowany jest właśnie wokół tej teorii.
Flagowym przykładem, którym posługują się trenerzy Agile, żeby zobrazować ideę empiryzmu, jest zasada działania termostatu [4]. To urządzenie, które zamontowane jest m.in. w klimatyzatorach, umożliwiające utrzymanie stałej temperatury.
Jak działa? Określamy cel – docelową temperaturę w pokoju. Następnie iteracyjnie sprawdzamy (inspekcja) jaka jest aktualnie temperatura w pokoju. Na podstawie różnicy pomiaru i docelowej temperatury, następuje dostosowanie (adaptacja) pracy urządzenia, tak by doprowadzić do osiągnięcia celu, czyli oczekiwanej temperatury. Jeżeli dobrze określimy cel, a proces będziemy powtarzać odpowiednie często, to zapewniamy, że temperatura nigdy nie odjedzie zbytnio od docelowej i zapewnimy sobie komfort termiczny.
Co się jednak stanie jeśli obok termostatu postawimy gorącą herbatę? Odczyt temperatury będzie fałszywy, nasz klimatyzator zacznie działać jak szalony, a w pokoju zrobi się zdecydowanie za zimno. Zafałszowane rezultaty inspekcji spowodują adaptacje niezgodną z ustalonym celem. Dlatego tak ważna w całym procesie jest transparencja – czyli pokazywanie rzeczy takimi jakie są w rzeczywistości. Bez transparencji trudno będzie osiągnąć zamierzony cel.
Po inne przykłady obrazujące idee empiryzmu odsyłam tu: [2]
Trzy filary Scruma – transparencja, inspekcja i adaptacja
To co przedstawione jest jako zasady Scruma umożliwia realizowanie empiryzmu poprzez trzy filary: przejrzystość, inspekcję i adaptację. Każde wydarzenie, artefakt i to jak praca jest zorganizowana realizują tę ideę.
Przejrzystość, zwana inaczej transparencją, polega na tym, aby pokazywać wszystko takim jakie jest. Każdy w zespole, ale również poza (np. Interesariusze), ma dostęp do prawdziwych, rzetelnych i kompletnych informacji bez ograniczeń. Bez przejrzystości rezultat inspekcji może prowadzić do niepoprawnego kierunku adaptacji, a zatem błędów i strat.
Inspekcja, czyli cykliczne sprawdzanie i weryfikowanie aktualnego stanu rzeczy, umożliwia wyciąganie wniosków, które pomagają ukierunkować dalsze działania Zespołu w kierunku określonego celu. Inspekcji może podlegać wszystko – produkt, procesy, lub czynniki ludzkie.
Opisane wyżej zmiany kierunku rozwoju to adaptacja. Jej sensem jest podejmowanie dalszych kroków, w taki sposób, by uwzględnianie były wyniki inspekcji, oraz by zbliżały nas do określonego celu. Jeżeli w wyniku inspekcji uzyskamy rzetelne informacje, to za podjętą decyzją o zmianie kierunku rozwoju będą stały twarde dane, czyli fakty.
Empiryzm dla Product Ownera
Każdy z trzech opisanych filarów Scruma ma znaczenie dla pracy Product Ownera.
Właściciel Produktu powinien żyć ideą przejrzystości. Będąc pewnego rodzaju pomostem pomiędzy światem zewnętrznym (Interesariuszami), a Developerami, kluczowe jest prowadzenie komunikacji w sposób otwarty i szczery. Z jednej strony PO powinien jasno i uczciwie przekazywać Interesariuszom informacje o postępach prac, a z drugiej strony przekazywać Zespołowi wszystko to, co ma znaczenie dla ich działań (argumentując swoje decyzje w oparciu o kontekst biznesowy). Wszystko to pomaga budować zrozumienie obydwu stron oraz obopólne zaufanie. Uporządkowany Backlog jest narzędziem ułatwiającym taki sposób komunikacji.
Zadaniem Właściciela Produktu jest podejmowanie decyzji o tym, co i w jakiej kolejności będzie tworzone przez Developerów. Co do zasady, powinny być to rzeczy, które przyniosą największą wartość produktowi. Idealnym rozwiązaniem jest poparcie decyzji danymi (Evidance-based Management). Z danymi trudno się kłócić – jest to zatem wspaniałe narzędzie do rozmów z kluczowymi Interesariuszami przy argumentacji swoich działań.
Jak pozyskać te dane? Skąd PO wie co przyniesie wartość? Na początku wszystko jest hipotezą. Dopiero po wdrożeniu możemy dowiedzieć się, czy to co zrobiliśmy rzeczywiście przyniosło wartość i jaka ona jest – zgodnie z ideą empiryzmu. [6] Jeżeli decyzje produktowe podejmowane są w oparciu o dane, to znacznie redukujemy ryzyko implementacji niewłaściwej rzecz. Aby określić realną dostarczoną wartość musimy po wdrożeniu dokonać inspekcji. Warto o tym pamiętać i zaplanować ten krok.
Pomocne może być tworzenie weryfikowalnych hipotez przed rozpoczęciem implementacji pełnego rozwiązania. Na przykład, kiedy wiemy, że użytkownik ma pewien problem związany z korzystaniem z naszego systemu spróbujmy zastanowić się jakie mogą być potencjalne rozwiązania i zweryfikujmy je z grupą docelową (znów inspekcja!), zamiast podejmować decyzje bazujące jedynie na własnym osądzie.
Dobrym pomysłem jest również stosowanie MVP (Minimal Viable Product), czyli produktu lub jego funkcjonalności w minimalistycznej wersji, którą wdrażamy jak najszybciej i poddajemy ocenie użytkowników (znów inspekcja). Ocena ta służy nam do nauki i podejmowania decyzji o dalszym kierunku rozwoju. Jest to tzw. pętla Build-Measure-Learn, będąca fundamentem metody The Lean Startup. Jest to kolejny przykład wartościowej inspekcji i adaptacji.
Empiryzm daje również miejsce na błędy. Product Owner nie wie wszystkiego i nie jest nieomylny. Gdy PO podejmuje decyzje w duchu najlepszych intencji, bazując na swojej najlepszej wiedzy i danych, to wciąż rezultat działań może okazać się niekorzystny. Scrum daje na to przestrzeń umożliwiając szybką inspekcję i adaptację. Błędy te najpewniej przyniosą pewne straty, za które odpowiedzialny jest PO. Jeżeli jednak na błędach się uczymy i wyciągamy z nich wnioski, które prowadzą Zespół do zmiany kierunku rozwoju, to końcowy produkt będzie bardziej wartościowy.
*To wszystko może tak działać, o ile pracujemy we wspierającym otoczeniu, które rozumie ideę empiryzmu i akceptuje fakt, że nie da się wszystkiego przewidzieć w złożonym środowisku [6].
Podsumowanie
Scrum zbudowany na idei empiryzmu pozwala realizować jego trzy filary – przejrzystość, inspekcję i adaptację. Bez pełnego zrozumienia tego aspektu, ciężko mówić o prawdziwym Scrumie. To nie same wydarzenia, artefakty i role tworzą Scruma, a właściwy mindset – otwartość na doświadczenia i wyciąganie z nich wniosków; uznanie, że w złożonym środowisku nie możemy wszystkiego przewidzieć i zaplanować; oraz, że złe decyzje będą się pojawiać, a stosując prawdziwie empirycznego Scruma można ograniczać straty.
Bibliografia
[1] Empiryzm; https://encyklopedia.pwn.pl/haslo/empiryzm;3897812.html
[2] Empiricism is not just a fancy word; https://www.scrum.org/resources/blog/empiricism-not-just-fancy-word
[3] Przewodnik po Scrumie (polska wersja Scrum Guide) https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Polish.pdf
[4] Empiricism is an Essential Element of Scrum; https://www.scrum.org/resources/empiricism-essential-element-scrum
[5] The Three Pillars of Empiricism (Scrum); https://www.scrum.org/resources/blog/three-pillars-empiricism-scrum
[6] The Empirical Product Owner; https://www.scrum.org/resources/empirical-product-owner
Hej Ola!
Fascynuje mnie zastosowanie SCRUMa w metodologii zarządzania zespołami handlowymi. Dzięki za tego bloga, ułatwia zrozumienie podstaw!
Cześć Łukasz! Dziękuję za Twój komentarz. Mam nadzieje, że dalsze treści będą dla Ciebie równie interesujące.
Osobiście mam jedynie doświadczenie w IT, ale w firmie, w której pracuje stosujemy elementy Scruma również w działach Hardware, czy People&Culture. Znajomy przez krótki czas nagrywał podcast „Agile poza IT” (https://open.spotify.com/show/3y5zh9Dgb9FPOezy8eSp9D). Fajny jest odcinek o People&Culture (https://open.spotify.com/episode/2msSei5b8u4ACnq2uf0L3I), bo pokazuje jak to wygląda w praktyce.