Co łączy Scrum Mastera, lidera i strategicznego analityka biznesowego? Każdy z nich próbuje usuwać przeszkody stojące na drodze grupy osób, która pracuje nad określonym celem – czy jest to cel sprintu, cel działu czy strategia firmy. Czym są przeszkody? Jak je zidentyfikować? I jak je usuwać?
Usuwanie przeszkód jako zadanie Scrum Mastera
Jednym z zadań Scrum Mastera wpisanych w Scrum Guide jest usuwanie przeszkód. Polega to na dbaniu, aby zespołowi nie stawało nic na drodze do tworzenia wartościowego dla klientów, potencjalnie releasowalnego przyrostu produktu. Czasem przeszkody leżą w samym zespole (np. nie wymieniamy informacji między sobą), czasem między zespołami (np. inny zespół dostarcza nam dane niskiej jakości), a czasem w organizacji (np. firma ustala kontrakty z klientami bez konsultacji z produkcją).
Czym są przeszkody?
Jeśli zespół nie dostarcza na koniec sprintu przyrostu produktu, który może być potencjalnie wydany do klienta, to pojawia się pytanie „dlaczego?”. Nie chodzi tu o szukanie winnych. Chodzi o znalezienie powodów, które utrudniają ludziom pracę. Chcemy je sukcesywnie usuwać.
Często na pytanie „jakie są przeszkody” słyszę status zadania, czyli gdzie jesteśmy z realizacją. Ta informacja na pewno jest ciekawa, natomiast w kontekście szukania przeszkód – bezużyteczna. Z informacji „gdzie jesteśmy” nie wynika pomysł na to, co moglibyśmy zrobić, żeby być dalej.
Przykład:
Wyobraź sobie, że masz cel przebiec 10 km w czasie 50 minut. Po kilku startach stwierdzasz, że biegasz 10 km w czasie 58 minut. Cel nie jest osiągnięty. Jakie są przeszkody?
Odpowiedzią na to pytanie nie jest „obecnie biegam 10 km w 58 minut”. Ani „obecnie mam treningi 2 razy w tygodniu”. Ani „2 lata temu miałem kontuzję”.
Co może być przeszkodą, że nie biegasz tak szybko, jak byś chciał? „Bo jak biegnę to nie wiem jak szybko i czy powinienem przyspieszyć”. „Bo jest mi ciężko, bo ważę za dużo”. „Bo mnie buty cisną”.
Przykład:
Jeśli masz cel wydać działający, wartościowy przyrost produktu gotowy do puszczenia do klienta, a nie wydajesz, to jakie mogą być przeszkody?
Przeszkodami nie będą odpowiedzi: „Nasi najlepsi ludzie nad tym pracują.”. Ani „Mamy 2 taski na backlogu in progress.”. Ani „Zadanie poszło do drugiego zespołu/zewnętrznego dostawcy”. Ani „Aktualnie implementujemy algorytm X w technologii Y.”.
Przeszkodami są na przykład: „Zespół nie zna wystarczająco technologii X”. „Mamy za duży dług techniczny w module X”. Albo „Zespół X nie zrobi dla nas części zadania, bo ma inne priorytety”. Albo „Zewnętrzny dostawca sam nie potrafi znaleźć przyczyny i potrzebuje więcej czasu.”
Po co szukać przeszkód?
Skoro Scrum, to empiryzm. A skoro empiryzm, to inspekcja i adaptacja. Inspekcja polega m.in. na szukaniu przeszkód. A adaptacja na ich usuwaniu i późniejszej ocenie, czy nastąpiła poprawa. Czyli bez przeszkód nie ma empiryzmu. A bez empiryzmu nie ma Scruma.
Jak znajdować przeszkody?
Naturalnym sposobem szukania przeszkód w pracy z zespołem Scrumowym są retrospekcje. Podczas podsumowania sprintu jest czas i miejsce na zadanie pytania zespołowi „Dlaczego się nam nie udało?”, „Co nam przeszkodziło?”, „Co wymagałoby zmiany, żebyśmy mogli dostarczać wartościowy produkt?”.
W zależności od dojrzałości zespołu, dostaniemy różne odpowiedzi. Niektóre zespoły same nazwą przeszkody, które uniemożliwiają im pracę. Zauważą wszystkie i wyczerpująco je wyjaśnią. Niektóre zespoły mogą potrzebować wsparcia w zauważeniu przeszkód, właściwym ich nazwaniu.
W jeszcze innych przypadku może być potrzeba początkowego robienia spostrzeżeń za zespół. Dotyczy to pewnie szczególnie sytuacji, kiedy mamy początkujący zespół i zaawansowanego Scrum Mastera, który dostrzega problemy, a na podstawie wiedzy i doświadczenia potrafi je zdiagnozować. To tak jak iść do lekarza z bólem kolana. Skoro lekarz studiował medycynę, to po objawach, obserwacji i badaniach potrafi stwierdzić, co dolega pacjentowi, choć on sam tego nie potrafił fachowo nazwać czy jego sugestie diagnozy są chybione.
Jakie techniki pomagają w szukaniu przeszkód?
5 x dlaczego
Zespół nie dostarczył działającego produktu. Usłyszysz różne powody. Na przykład – „bo tego się nie dało zrobić w tym czasie”. Jak się nie dało, to się nie dało. „Głupi PO”, „Niekompetentny zespół”, „Bo nas nie słuchają”. Nie prowadzi to do niczego konstruktywnego. Skoro nic się nie da zrobić, to czemu już sobie nie wykopać grobu i się w nim nie położyć? Albo zwolnić się z firmy, skoro jest taka słaba i nie ma nadziei?
Zamiast pozostawać na poziomie, który jest tak ogólny, że nie wiadomo co z nim zrobić, zejdź do przyczyn źródłowych, zadając kolejne pytania „dlaczego?”.
- Nie dowieźliśmy celu sprintu.
- Dlaczego?
- Bo się tego nie dało zrobić w takim czasie.
- Dlaczego?
- Bo źle oszacowaliśmy
- Dlaczego?
- Bo nie znaliśmy pełnego zakresu prac.
- Dlaczego?
- Było niejasne wymaganie.
- Dlaczego?
- Bo nie mamy doświadczenia i wiedzy do precyzowania wymagań.
Co można z tym zrobić? Nagle się okazuje, że wiele. Można podnieść kompetencje zespołu. Można poprosić o mentoring analityka przy refinemencie. Można pożyczyć analityka na 1 sprint. I inne takie.
Wracając do przykładu z bieganiem.
Możesz dojść do wniosku, że ważysz za dużo, bo choć żyjesz od miesiąca na samych warzywach, to zapijasz je 2 litrową Colą.
Buty cisną Cię dlatego, że źle dobrałeś rozmiar.
Nie widzisz jak szybko biegniesz, bo nie masz urządzenia do pomiaru prędkości.
Diagram Ishikawa
Czasem uchodzi naszej uwadze, że przyczyny problemu mogą pochodzić z różnych obszarów. Skupiamy się na technologii, a problem leży też w komunikacji, organizacji, nastawieniu ludzi, itd. Bywa też, że problem ma więcej niż jedną przyczynę. Gdybyśmy się nie zagłębili w szukanie przyczyn z różnych kategorii, łatwo by nam to umknęło.
Przykładowo – katastrofy lotnicze często spowodowane są kilkoma czynnikami – zawiódł człowiek, ale też pojawił się błąd w danych i awaria sprzętu. Katastrofa w Czarnobylu również była złożeniem czynnika ludzkiego i niewłaściwych materiałów w konstrukcji reaktora.
Różnych przyczyn szukaj na diagramie ishikawa, gdzie na osiach ryby wpisuj kategorie poszukiwanych przyczyn. Zagłębiaj się w przyczyny przyczyn zadają pytanie „dlaczego”. „co to spowodowało?”. Mając pełen obraz sytuacji, spróbuj znaleźć przyczyny mające największy wpływ.
Nazywa się to analizą przyczyn źródłowych (RCA root cause analysis) i jest jedną z technik analityka biznesowego. Jak się okazuje, przydatną również Scrum Masterowi.
Co robić z przeszkodami?
Zbierz
Zbierz pojawiające się przeszkody. Fajnie byłoby mieć perspektywę wycinku i całości. Wycinkiem może być określony czas np. sprint, określony zakres np. zespół. Całością mogą być wszystkie istniejące przeszkody (choć tu warto pomyśleć o grupowaniu np. po tematach, częstości występowania czy sprytnym sposobie prezentacji, żeby nie utonąć w natłoku informacji).
Podziel
Pojawiające się przeszkody podziel na te, które:
- możecie rozwiązać sami w zespole,
- możecie rozwiązać przy współpracy z innymi zespołami,
- mogą zostać rozwiązane przez interwencję kogoś z firmy.
Kiedy to zrobisz, od razu zadaj sobie pytanie – czy na pewno tak jest? Jeśli masz tendencję do umieszczania zadań poza obszarem swojego wpływu – czy naprawdę nie możesz nic zrobić, żeby poprawić sytuację? Czy zanim eskalujesz problem do wszystkich świętych, jest coś, czego możesz spróbować samodzielnie? Pracuj nad poszerzaniem swojego wpływu. Czasem tylko wydaje nam się, że sami nie możemy nic zrobić. Ulegamy wygodnemu przekonaniu, że to przecież nie od nas zależy. Czasem poddaliśmy się zanim nawet spróbowaliśmy. Czasem poddajemy się po 1szej próbie.
Pracujmy też nad kreatywnością wymyślania rozwiązań. Na organizacyjny problem istnieje często wiele rozwiązań. Można z kimś porozmawiać, zrobić szkolenie, pójść ścieżką oficjalną albo nieformalną, poprosić kogoś o pomoc, ugryźć temat z kilku stron. Wysil się. Znajdź 5 sposobów jak można podejść do problemu. Myśl o tym, co zrobić teraz, ale też jak poszerzać swój obszar wpływu na przyszłość.
Zanim manager zacznie rozwiązywać problem, może zapytać „a czego już próbowałeś?”. Głupio byłoby powiedzieć „niczego”. Oczywiście czasem zdarzają się sytuacje wymagające natychmiastowej reakcji i eskalacji, ale, umówmy się, nie wszystkie.
Jeśli przekazujesz przeszkodę do organizacji, upewnij się, że została dobrze wyjaśniona właściwej osobie, umówiliście się na konkretną akcję i ta osoba wzięła ją jako zadanie (a nie zrozumiała, że tylko ucinacie sobie niezobowiązującą pogawędkę).
Po co taki podział? Żeby sprawnie przejść do przypisywania akcji właściwym osobom.
Przypisz akcje
Przydzielenie przeszkód do właściwej kolumny pomoże w przypisaniu akcji. Kto może zająć się problemem? Jaką akcję można wykonać? Na kiedy? Staraj się wybierać przeszkody najbardziej wartościowe biznesowo, problemy najbardziej przekładające się na klienta, najpilniejsze. Warto się na czymś skupić i nie zakopać w zbyt wielu akcjach na raz. Wyznaczaj akcje na tyle małe, żeby można je podsumować po krótkim czasie, np. 1 sprincie. Większe zmiany staraj się podzielić na mniejsze kroki.
Akcji naprawczych nie musisz robić samodzielnie, ale spowoduj, by się zadziały. Zadawaj pytania, wizualizuj przeszkody, pytaj kto najlepiej może w tym pomóc. Wspieraj, jeśli możesz.
Obawiasz się, że Ty maluczki niczego nie zmienisz w wielkiej machinie? A spróbowałeś? Ile razy? Pamiętaj – odwaga. I zaangażowanie. Walcz. Tam, gdzie jesteś bezsilny, przestań działać ciągle w ten sam nieskuteczny sposób. Tam, gdzie jesteś bezradny, proś o radę, szukaj innych sposobów, działaj inaczej i zobacz, co się wydarzy.
Wracając do przykładu z bieganiem.
Skoro jesteś gruby, bo źle się odżywiasz, najlepiej mieć pretensje do samego siebie i zmienić nawyk picia Coli. Jeśli masz za małe buty, to kup sobie nowe. Jeśli nie masz urządzenia do pomiaru prędkości, to też je sobie załatw. Chcesz zainwestować w porządniejsze buty albo fajnego Garmina, a jesteś jeszcze studentem na dorobku? Możesz zdefiniować akcję dla rodziców, żeby Cię dofinansowali przy okazji najbliższych urodzin. A do tego czasu możesz biegać z kolegą, który ma fajny zegarek i będzie Ci mówił jak szybko biegniecie.
Podsumuj
Podsumowuj pracę nad usuwaniem przeszkód. Wróć do akcji, jakie sobie wyznaczyliście, podsumowuj, jak poszło. Czy przeszkoda została usunięta? Czy zespół to potwierdza? A może sposób, w jaki pracujecie z przeszkodami również wymaga usprawnienia?
Uwagi praktyczne
Moje zeszłoroczne fuckupy z szukaniem przyczyn źródłowych, przypominają, żeby uważać na kilka rzeczy.
Jedz słonia kawałkami. W dużych firmach, projektach, można utonąć w ilości informacji. Dobrze zbierać wszystkie przeszkody, ale jednocześnie umieć pokazać jedynie jedną z perspektyw – wybranego zespołu, wybranego etapu procesu, wybranego sprintu czy wydania produktu, wybranej roli.
Bądź precyzyjny. Stwierdzenia typu „kiepska komunikacja” albo „mam słabego PO” czy „ta firma nie dba o jakość” nie doprowadzą do niczego konstruktywnego. Dopiero skupienie na konkretnych sytuacjach i szczegółowych kwestiach (np. „zespół A nie powiedział nam o zadaniu X”, „mamy informacje o dwóch sprzecznych celach”, czy „pominęliśmy w tym sprincie wymaganie jakościowe Z”) daje szansę na precyzyjniejsze definiowanie przeszkód i skuteczniejsze ich usuwanie.
