Debata o tym, czy i jak bardzo techniczne powinny być osoby podejmujące się odpowiedzialności Scrum Mastera trwa od lat. Od czasu do czasu ktoś podgrzewa temat twierdząc, że tak się nie da i zaraz odzywa się chór, że jednak się da.

Ja stawiam tezę, że Scrum Master musi znać statystykę. Tak, taki obszar matematyki. Dowiedz się dlaczego, jak Ci to pomoże i co ważniejsze — jak ten temat ugryźć?

Dwie znane drogi

Scrum Master poza znajomością Scruma – umiejętnością wyjaśnienia sensu i wartości jego elementów może naturalnie iść różnymi ścieżkami. Techniczną, choćby po to, by nie dać sobie „dmuchać w kaszę”. Przykład? Rozmowy o podejściu do tzw. refaktoringu, czyli przepisywaniu istniejącego kodu, o tym, czy wartość biznesową da się uzyskać bez przechodzenia na nowy język czy framework wymagają rozumienia tego, jak wytwarza się oprogramowanie. Przy takiej dyskusji musimy być świadomi ryzyka oraz tego, że developerzy kochają nowe rozwiązania. A te wcale nie muszą być tą najpotrzebniejszą klientowi i użytkownikowi rzeczą.

To ostatnie zdanie kieruje nas w stronę Scrum Mastera, który rozumie, czym i jak kierują się ludzie. Ci z biznesu i Ci od technologii. Wchodzimy więc w obszary popularnie nazywane „miękkimi”. O czym mowa? O rozumieniu tego, jak irracjonalne i emocjonalne potrafi być zachowanie nas wszystkich (włącznie ze Scrum Masterem). Świadomość tych schematów, motywacji czy utartych nawyków nie chroni nas przed nimi, ale zmniejsza prawdopodobieństwo, że będziemy je mieć wszystkie w tzw. martwym polu.

Padło wreszcie słowo prawdopodobieństwo, a od niego już tylko krok do statystyki. Scrum daje Scrum Masterom coraz mniej gotowych rozwiązań. Coraz mniej metryk i praktyk jest stricte scrumowe, co powoduje, że musimy sięgać po inne.

Widząc bardzo wiele osób „technicznych” i nazwijmy to „ludzkich” w rolach Scrum Masterów widzę pewien istotny i wspólny dla nich brak. Brak wiedzy z obszaru statystyki, która jest moim zdaniem konieczna do wspomagania produktywnego dialogu między biznesem i zespołami delivery.

Przykład? Ostatnio przy okazji szkolenia w Warszawie wybraliśmy się z grupą na spotkanie „Zwinnej Kawy”. Tam krążyła na kompie (Dzięki Kate!) długaśna lista, grubo ponad 100 tematów, w jakich może rozwijać się Scrum Master czy Agile Coach. Jak sądzicie, ile było wierszy poświęconych statystyce, myśleniu i prognozowaniu probabilistycznemu? Rozumieniu choćby tego, że średnia nie jest Twoim sprzymierzeńcem? Dobrze myślicie. Okrągłe zero.

Stary, ale po co mi statystyka?

Zacznę od tego, że nasza rzeczywistość to kraina statystyki. Statystycznie (ale nie średnio) podejmujemy nasze codzienne i te rzadsze decyzje w oparciu o własne doświadczenia czy zasłyszane opinie.

Tak samo robią lekarze. Serio. Bardzo rzadko mają „pewność”. Kiedy idziemy do nich jako pacjenci, to zbiór ich osobistych doświadczeń, tego, co zapamiętali ze studiów, odnotowane symptomy kierują ich w stronę diagnozy, która jest tylko najbardziej prawdopodobnym scenariuszem w oparciu o dostępne dane. Przepisując lek również idą pewną ścieżką prawdopodobieństwa. Może pomoże, bo wielu pomogło, a może nie, bo się pomylili. Może przez wyborem antybiotyku powinni zlecić antybiogram, ale komu by się chciało. Idąc ścieżką jeszcze mniejszych prawdopodobieństw możecie mieć nieuświadomioną alergię na składnik leku i rozchorować się gorzej i na co innego. Nie wszystkie te scenariusze są tak samo prawdopodobne i dlatego często decydujemy się na określenie leczenie bez nadmiernego lęku.

Wiecie co? Ludzie, szczególnie specjaliści, często się mylą. Mylą się w bezwzględnych liczbach częściej, bo muszą podejmować dużo decyzji, przypadki są różne, a ich zestaw doświadczeń ograniczony.

Dużo osób mówi o tym, że autonomiczne samochody skurczą grono zawodowych kierowców, ale po pierwszych próbach okazuje się, że może lekarzy też. I to różnych lekarzy – od tych rodzinnych, po specjalistów radiologii włącznie, bo mogliby zostać zastąpieni przez… Statystycznie skuteczniejsze algorytmy karmione olbrzymimi zestawami danych. Niedawno słyszałem, że przeciętna pierwsza diagnoza lekarza psychiatry jest skuteczna w około 40% przypadków. Algorytm w ponad 90%.

Żeby nie było tak ponuro, to ostatnio było też głośno o chomiku, który losowo inwestował i spieniężał wybrane kryptowaluty swoim kołowrotkiem w klatce, co dawało stopę zwrotu lepszą niż decyzje ludzi ponoć uwarunkowane logicznym myśleniem i analizą faktów. Czy to znaczy, że jesteśmy bez szans? Nie, po prostu rozkład i zmienność prawdopodobieństw w medycynie i rynku finansowym nie są takie same.

No dobra, ale po co statystyka u Scrum Mastera?

Po pierwsze budowanie jakichkolwiek planów to podejmowanie decyzji w oparciu o zakłady. Zakłady rozumiane w ten sposób, że pewien zestaw i ciąg wydarzeń wydaje się nam bardziej prawdopodobny niż inny. Albo może inaczej. Pewnego zestawu i ciągu wydarzeń chcielibyśmy bardziej niż innego np., że uda się nam zrealizować cel Sprintu. Tu pojawia się wątek złożoności. Jeśli będziemy dyskutować, czy do zrobienia jest A, to odpowiedź może brzmieć tak. Tak samo możemy odpowiedzieć, jeśli chodzi o B i C, ale plan dostarczenia A, B i C w tym samym przedziale czasu nie jest prostym dodawaniem. Tu potrzeba myślenia statystycznego, wiedzy o tym jak rośnie potencjalny błąd, gdy składamy (mnożymy) prawdopodobieństwa.

Podobnie ma się z odpowiedzią na najczęściej zadawane przez biznes pytanie: „Na kiedy to będzie?” Musimy być wyczuleni, że często w odpowiedzi przekierowujemy rozmowę w stronę „Ile to zajmie?”, a to nie to samo pytanie. Ostatecznie chodzi o to, by wiedzieć: kiedy zacząć, żeby zdążyć? A to jeszcze inne pytanie. Odpowiedzi na te pytania są pytaniami opartymi o prawdopodobieństwo. Z jakim prawdopodobieństwem chcemy to wiedzieć?

Tu wchodzimy głębiej np. w rozumienie tego, że często używany czas realizacji (lead time), czyli czas od momentu rozpoczęcia do dostarczenia zadania dla pojedynczego zadania, jest w istocie konkretną wartością (np. 4 godziny, czy może 3 dni). Gdy pytamy o przyszłość, o potencjalny czas wykonania podobnego zadania, to z pojedynczej wartości przeskakujemy na histogram, gdzie operujemy rozkładami prawdopodobieństw i zakresami. Gdy zaś mówimy o zestawie zadań, jeden histogram nie wystarczy i musimy posiłkować się modelowaniem takim jak technika Monte Carlo.
Nie wierzysz? To zajrzyj do Scrum Guide’a. Czym jest prognoza (forecast) i wszechobecne w języku zespołów Scrumowych szacowanie lub wycena? Sprawdź choćby w Wikipedii.

Praktycznym wyzwaniem dla Scrum Masterów jest umiejętność rozumienia tych zagadnień na tyle dobrze, by nie tylko samemu posiąść wiedzę tajemną, ale też (tak sam, jak Scrum) umieć go w przystępny sposób objaśnić biznesowi i zespołowi.

Czy to nie jest proste? Niestety nie. Co do zasady wszyscy jako ludzie mamy silny lęk przed niepewnością. Czujemy się spokojniejsi, gdy poda nam się nierealną, ale wyglądającą na dokładną wartość, niż poda zakres i obarczy go jakimiś szansami na (nie) powodzenie. Tu statystyka przecina się z ekonomią behawioralną, której bliżej do psychologii niż danym statystycznym z GUS-u.

Musimy więc umieć poprowadzić rozmowę, z której wyczytamy, jaki jest apetyt na ryzyko biznesu. Tu pomocne jest rozumienie statystyki na tyle dobre, by opowiedzieć to w przystępny, bazujący np. na storytellingu sposób. Tu pojawia się choćby konieczność zrozumienia i wyjaśnienia, że średnia to zły czynnik, by opisywać niepowtarzalną w swojej naturze pracę intelektualną. Musimy umieć więcej, niż tylko powiedzieć, że ludzie i zbudowany z nich zespół to nie to samo, co maszyna i cała linia produkcyjna.

Po stronie developerów (to również statystyczne uproszczenie) będziemy mieli dokładnie odwrotną sytuację. Inżynierską chęć osiągnięcia precyzji, która po pierwsze nie jest potrzebna, a po drugie da wręcz fałszywe poczucie kontroli i pewności. Często na tym etapie developerzy „czellendżują” Scrum Mastera odwołując się, że prognozy muszą bazować o duże zestawy danych (nieprawda!) albo że zadania oszacowane na duże są zawsze realizowane dłużej niż te „małe”, ponieważ w martwym polu mamy kwestię priorytetów czy klas usług. Wszystko to da się pokazać na całkiem niedużych zestawach danych, ale musimy wiedzieć, jak i czym jest przetworzyć, a następnie — jak zaprezentować.

Skąd wziąć właściwą wiedzę?

Na szczęście żyjemy w czasach, w których dostęp do informacji jest stosunkowo łatwy. Wystarczy zacząć wgryzać się w temat od strony popularnonaukowej. Na polskiej scenie najjaśniej świeci pewnie znana Janina Bąk ze swoją książką „Statystycznie rzecz biorąc”, ale warto też sięgnąć po inne tytuły, np. „Thinking in Bets” Annie Duke. No i tak oto mamy 100% rekomendacji materiałów napisanych przez kobiety. Warto polecić i mężczyzn. Tu mam swojego faworyta, czyli kurs statystyki dostępny na Coursera a przygotowany przez dwóch naukowców z uniwersytetu w Amsterdamie, gdzie jest sporo męskich tematów. Jak zrozumieć błąd statystyczny na przykładzie pokrycia ciała piłkarzy tatuażami lub tym jak duża jest szansa na zrobienie przez dziecko kupy w momencie jego przebierania. Przez ojca. Życie to statystyka, warto w nią umieć.

Nie byłbym sobą, gdybym nie dodał, że wspomniane tu tematy to coś, co do świata zwinności wstrzykuje Metoda Kanban. Ponieważ bazujemy w niej na danych i metodzie naukowej powyższe i wiele innych praktycznych aspektów poznacie w ramach szkoleń Kanban System Design i Kanban Systems Improvement. Ich najbliższe terminy znajdziecie jak zawsze na leanagile.ninja.

W praktyce jako coach i konsultant widzę, że równie częstą barierą w adopcji dobrych praktyk jest nie tylko brak umiejętności statystycznych, ale i ograniczenia narzędziowe – wiemy co, ale nie wiemy i/lub nie mamy jak. Tu z pomocą przychodzą odpowiednie narzędzia, o których opowiadam w dwóch kolejnych odcinkach podcastu (#33 i #34).

Na koniec warto zadać pytanie – jakie jest prawdopodobieństwo, że zainteresujesz się statystyką?