Empiryzm - Code Sprinters - Agile Experts

Empiryzm

Całkiem niedawno poproszony zostałem o wskazanie tego aspektu Scruma, który uznaję za kluczowy do osiągnięcia zwinności. Odpowiedź była oczywista: empiryzm, który w Scrumie manifestuje się wbudowaniem pętli inspekcja-adaptacja we framework i wymogiem przejrzystości (bez której inspekcja jest nieskuteczna, a adaptacja może wieść na manowce).

A potem uświadomiłem sobie, że nie zawsze było to dla mnie oczywiste. Gdy po raz pierwszy czytałem o Agile i Scrumie za mrocznych czasów, gdy tkwiłem w okowach Waterfalla skundlonego z V-modelem, ten empiryzm nie wydawał mi się bardzo ważny. Jako członka ogromnego zespołu w Agile pociągała mnie najbardziej możliwość organizowania sobie pracy, poprawa komunikacji, poczucie wpływu, lekkość procesów – a nie empiryzm. To, że jest niezbędny i stanowi podstawę, zrozumiałem dopiero pracując w metodach Agile.

Czy wszyscy Scrum Masterzy wiedzą, co to empiryzm?

Niestety wciąż spotykam Scrum Masterów lub leaderów Agile w organizacjach, którzy (tak jak ja kiedyś) nie przywiązują do empiryzmu wagi. Scruma traktują jako sposób organizacji pracy, pozwalający zwiększyć efektywność działań w magiczny sposób. Magiczny, bo przecież czytali, i słyszeli, a czasami widzieli, że „to działa” – magia, jak nic.

Nie oszukujmy się: Agile jest wdrażany nie po to, by można było działać empirycznie, ale by „dostarczać więcej”, czasami szybciej, a czasami lepsze rozwiązania. Zdarza się, że osoby pełniące rolę Scrum Masterów są tak naprawdę „mechanizatorami Agile” w firmie, nie rozumieją jak narzędzie w ich rękach może zaowocować zwinnością zespołów lub całej organizacji. Jak przekonać kogoś, że empiryzm jest kluczowym elementem Agile?

Gdy brak empiryzmu

Wyobraźmy sobie prosty do rozwiązania problem: przejechać z miasta A do miasta B na ważne spotkanie biznesowe. Tradycyjne podejście w uproszczeniu wygląda tak: analizujemy trasę, budujemy plan podróży z uwzględnieniem tego, co może wpłynąć na jego wykonanie, po czym realizujemy plan. Jeśli analizy były trafne, założenia (czyli informacje z prognoz, statystyk korków etc.) się potwierdzą, być może dojedziemy na czas. Jak zdarzy się coś nieprzewidzianego, musimy proces powtórzyć…

W tym podejściu podstawą planu są założenia i przewidywania. Taki predyktywny sposób działania jest tym mniej skuteczny, im dłuższy plan wytworzyliśmy, bo rośnie ilość zmiennych, jakie musimy brać pod uwagę, przewidując ich wartości.

Gdy jest empiryzm

W rzeczywistości wybierając się z miasta A do miasta B dokonamy analiz niezbędnych jedynie do wyboru środka transportu, po czym plan będziemy tworzyć na bieżąco i wdrażać etapami, dostosowując się do okoliczności. Ba, jeśliby się okazało, że wybraliśmy samochód, a ten uległ awarii, możemy wynająć auto, jechać autobusem lub pociągiem. Działamy empirycznie i w oparciu o to, co wiemy – bo się wydarzyło – wykonujemy kolejne kroki. Jedyne, co się nie zmienia, to cel: dojechać do B.

A gdzie ta zwinność?

Tradycyjny model, w którym empiryzmu brak, w ogóle nie jest zwinny: jeśli plan nie przewidział, co zrobić w nietypowej sytuacji (np. wypadku na drodze, która została potem zablokowana), nie możemy podejmować decyzji „z marszu”, ale musimy zmodyfikować plan. Prosta zmiana trasy staje się problematyczna, bo skręcenie w inną drogę wymaga zaplanowania dalszego ciągu trasy do samego końca.

Empiryczny model jest zwinny: decyzje podejmuje ten, kto działa aby osiągnąć wyznaczony cel. Nie ma planu, choć jest nieustanne planowanie, w bardzo krótkiej perspektywie, w oparciu o obserwacje i zdarzenia, jakie miały miejsca. Jest wypadek i korek – omijamy to miejsce. Trzeba zmienić trasę, jadę inną drogą. Ba, mam GPS, który mnie wspiera.

Zwinność, poziom drugi

W tradycyjnym modelu nie jest raczej możliwe, by w trakcie realizacji planu odbyła się na nowo dyskusja na temat celu. Cel jest niezmienny i niepodważalny, realizujemy plan.

W empirycznym modelu na dowolnym etapie można wrócić do dyskusji o celu. Jeśli mamy dotrzeć do miasta B, ale jest potężny korek i pół przedmieścia stoi, to rozumiejąc cel (spotkanie biznesowe) możemy zaproponować, że ze względu na okoliczności zrobimy telekonferencję.

Ktoś może zaprotestować: zaraz, zaraz, przecież to samo można zrobić w modelu tradycyjnym. Można przeplanować trasę, można zadzwonić. No właśnie, teoretycznie można. W praktyce to się nie stanie, bo nie wyposażamy osób realizujących plan ani w uprawnienia, ani w narzędzia, ani w umiejętności planowania lub analizy (bo przecież normalnie tego nie robią, czyż nie?). Aby takie przeplanowanie zrobić, wymagany jest czas, zaangażowanie dodatkowych osób, zgody, budżet…

Co więcej, nawet gdyby realizujący plan mogli działać względnie swobodnie, nie da się już odzyskać czasu i kosztów poniesionych na wytworzenie planu, który okazał się nierealizowalny. Im bardziej marnotrawstwo staje się widoczne, tym większa staje się presja, by jednak za wszelką cenę zrealizować ten pierwotny plan. Jest korek? To poczekamy, trudno, spotkanie odbędzie się po czasie, o ile ktoś na nas poczeka.

Eksperymentuj!

Empiryzm wymaga eksperymentowania, a więc i gotowości na porażki i błędy, z których czerpie się wiedzę i doświadczenie. Jadący z A do B w naszym przykładzie może źle zrozumieć mapę, zdecydować się na podróż tramwajem o zmienionej niekorzystnie trasie etc. To spowoduje problem, ale działając empirycznie, po jego wykryciu dokonana zostanie zmiana, być może korzystna. Istota podejścia empirycznego polega na zdolności do szybkiego wykrycia, że należy dokonać korekty i na dokonaniu tej korekty.

Warto uświadomić sobie, że każdy Sprint w Scrumie to eksperyment. To nie tylko „iteracja”, czyli kawałek roboty do wykonania w dwa do czterech tygodni. To doświadczenie: stawiamy tezę, że coś da się osiągnąć w dwa-cztery tygodnie, i że to coś będzie wartościowe. Na koniec Sprintu weryfikujemy poprawność tej tezy i planujemy kolejny eksperyment-Sprint.

Nie róbmy nic „raz a dobrze”

Jeśli wydaje nam się, że wiemy dokładnie, co chcemy osiągnąć, to… cóż, może powinniśmy to zrobić najszybciej jak się da, nie dzieląc pracy niepotrzebnie na iteracje.

Jeśli jednak mamy odrobinę zdrowego rozsądku, będziemy mieć świadomość, że wizja może nie przetrwać starcia z rzeczywistością i zmiennym otoczeniem. W takim przypadku zastanówmy się od czego zacząć, zróbmy to, po czym zdecydujmy jak (i czy w ogóle) chcemy kontynuować. Jest szansa, że osiągniemy cel zupełnie inaczej, niż początkowo zakładaliśmy.

Jeśli tworzylibyśmy system zarządzania flotą pojazdów, moglibyśmy go napisać „raz a dobrze”. Lub kawałkami: najpierw UI, potem baza danych, potem jakieś serwisy komunikujące się z urządzeniami w samochodach etc. Na koniec poskładalibyśmy to system, być może wart poniesionych na niego nakładów. Przekonamy się o tym, jak zaczniemy go używać.

Dużo lepiej jednak zrobić na początek najprostszy system komunikacji z pojazdami, który potwierdzi, że faktycznie potrafimy coś takiego wytworzyć. Krok po kroku dodamy do niego coraz więcej funkcjonalności; gdzieś po drodze zaczniemy go używać na długo przed tym, zanim zrealizujemy większość wymagań. Ba, pewnie okaże się, że wiele z wymagań będzie już nieaktualnych, pojawią się nowe. Być może w trakcie prac nasz system zostanie użyty skutecznie do zarządzaniem wózkami widłowymi w dużym magazynie i… zdecydujemy się pozostać przy takim jego zastosowaniu?

Dlaczego empiryzm jest ważny w Scrumie

Bo jest jednym z „magicznych” powodów, dla których Scrum „działa”, jak starałem się to wyjaśnić powyżej. Oczywiście to nie jedyny powód, ale to już temat na osobny wpis.

Jak budujecie swoje rozwiązania? Zwinnie, czy planując z góry co i kiedy uda się osiągnąć? „Raz a dobrze”, czy raczej inkrementalnie, cały czas zastanawiając się, jaki powinien być następny krok? Empirycznie, czy predyktywnie?

LinkedIn

SZKOLENIA ZWIĄZANE Z TEMATYKĄ ARTYKUŁU


O autorze: Rafał Markowicz
Scrum Master z wieloletnim doświadczeniem, w branży IT od 2001. Praktyk Agile, ekspert w zakresie inżynierii testów i zapewnienia jakości. Pracował jako analityk systemowy i biznesowy, jest doświadczonym developerem, managerem i konsultantem.

Inne artykuły tego autora