Blog

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: to empiryzm, który w Scrumie manifestuje się wbudowaniem pętli inspekcji-adaptacji 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 projektowego, w Agile pociągała mnie najbardziej możliwość samodzielnego organizowania sobie pracy, poprawy komunikacji, zyskanie poczucia wpływu, lekkość procesów, a nie empiryzm. To, że jest niezbędny i stanowi podstawę działania zwinnego zrozumiałem, dopiero gdy zacząłem pracować w metodach Agile.

Czy wszyscy Scrum Masterzy wiedzą co to empiryzm?

Niestety wciąż spotykam Scrum Masterów lub lideró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 bardzo często „wdrażany” nie po to, by można było działać empirycznie, ale by „dostarczać więcej”, robić to szybciej, a tylko czasami po to, by powstały lepsze rozwiązania. Zdarza się, że osoby pełniące funkcję Scrum Masterów są tak naprawdę „mechanizatorami Agile” w firmie i 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 następująco: 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 i jeśli założenia (czyli informacje z prognoz, statystyk korków etc.) się potwierdzą, być może dojedziemy na czas. Jeśli zdarzy się coś nieprzewidzianego, plan stanie się bezużyteczny, a chcąc wytworzyć nowy plan (uwzględniający pozyskaną wiedzę), proces trzeba 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 bardziej rozbudowany jest plan, jaki wytworzyliśmy, i im dalej w przyszłość sięgały nasze prognozy. Dlaczego? Bo rośnie ilość zmiennych, jakie musimy brać pod uwagę, przewidując ich wartości; rośnie też ich zmienność i nieprzewidywalność.

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 na podstawie tego, 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 w jego wyniku zablokowana), nie możemy podejmować decyzji z marszu, ale musimy zmodyfikować plan. Prosta zmiana pierwotnych planów staje się problematyczna, bo skręcenie w inną drogę wymaga zaplanowania dalszego ciągu trasy do samego końca, zanim ruszymy z miejsca. Nie możemy przecież wyruszyć w dalsza drogę bez planu, skoro jest on podstawą każdego kroku, jaki podejmujemy.

Empiryczny model jest bardziej elastyczny: decyzje podejmuje ten, kto działa, aby osiągnąć wyznaczony cel. Nie ma detalicznego planu, choć jest nieustanne planowanie, w bardzo krótkiej perspektywie, na podstawie obserwacji i zdarzeń, jakie miały miejsce. Jest wypadek i korek – omijamy to miejsce. Trzeba zmienić trasę, jedziemy inną drogą. Ba, mamy GPS, który nas 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, a my po prostu 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 utrudniające dojazd 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 tak się nie stanie, bo nie wyposażamy osób realizujących plan ani w uprawnienia, ani w narzędzia, ani w niezbędne do tego 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 decydentów, 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ę niemożliwy do zrealizowania. 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. Jeśli to spowoduje problem, po jego wykryciu dokonana może zostać kolejna zmiana, być może bardzo korzystna. Istota podejścia empirycznego polega na zdolności do szybkiego wykrycia, że należy dokonać korekty i na bezzwłocznym 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 ciągu maksymalnie miesiąca. To doświadczenie: stawiamy tezę, że coś da się osiągnąć w ten miesiąc 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 zastanowimy się, od czego zacząć, zrobimy jeden niewielki krok i zdecydujemy jak (i czy w ogóle) chcemy kontynuować. Jest szansa, że osiągniemy cel zupełnie inaczej, niż początkowo zakładaliśmy.

Przykładowo, jeśli tworzylibyśmy system zarządzania flotą pojazdów, moglibyśmy go napisać raz-a-dobrze i na koniec uruchomić. To wydaje się dość karkołomne, zdecydowanie bezpieczniej byłoby tworzyć takie rozwiązanie kawałkami: najpierw UI, potem bazę danych, następnie jakieś serwisy komunikujące się z urządzeniami w samochodach etc. Na koniec poskładalibyśmy te komponenty w system, być może wart poniesionych na niego nakładów. Przekonamy się o tym, gdy 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ę za to nowe. Być może w trakcie prac nasz system zostanie użyty skutecznie do zarządzania 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 tych 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 artykuł.

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?