Siedziałem i kminiłem, myślałem, dumałem… O czym tu dzisiaj napisać? Włosy (ostatnie) z głowy rwałem z rozpaczy, że wewnętrzny backlog pomysłów się wyczerpał, że w czarnej du… tfu, dziurze jakiejś się znalazłem. I nagle olśnienie! Eureka, rzekłbym! Jest pomysł! Podzielę się dzisiaj z Tobą moimi miarami, które stosowałem lub starałem się stosować z różnym powodzeniem w różnych zespołach i organizacjach. Nie będzie to naukowy wywód o miernikach z ogromną porcją teorii, jak mierzyć, po co, etc. Będzie to raczej próba podzielenia się ze światem swoim warsztatem… O! Rym częstochowski się przytrafił niechcący. Jeśli stosujesz inne miary, zachęcam do podzielenia się nimi – na przykład w komentarzu pod tym artykułem.
W kanbanie
Zacznę od kanbana. Mam w nim zdecydowanie mniejsze doświadczenie niż w scrumie, więc będzie szybko. Później przejdę do mojego ulubionego iteracyjnego, inkrementalnego frameworka na „S”.
WORK IN PROGRESS
i spokrewniony z nim WORK IN PROGRESS LIMIT.
Pierwszy pokazuje, ile mamy „pracy rozgrzebanej” jednocześnie. Wyrażany liczbą zadań w toku.
Drugi jest przyjętym przez zespół nieprzekraczalnym limitem pracy w toku – wyrażanym również liczbą zadań.
Po co zawracać sobie nimi głowę? Ano po to, aby nauczyć się kończyć pracę, zamiast w nieskończoność zaczynać kolejne zadania. Aby nadmiarowo nie przełączać kontekstu. Udowodniono, że wielowątkowość w wykonaniu człowieka jest mało efektywna, ale kiedy skupimy się na jednym wątku – potrafimy zdziałać cuda. Po to właśnie mierzymy i limitujemy WORK IN PROGRESS w Kanbanie.
LEAD TIME,
czyli czas od momentu złożenia zamówienia do chwili jego dostarczenia użytkownikowi. Pokazuje, jak długo klient musi czekać na realizację swojego zgłoszenia. Przykładowo: znajdujesz błąd w oprogramowaniu, zgłaszasz dostawcy buga i w tym momencie uruchamiasz zegar LEAD TIME. Zatrzyma się dopiero wtedy, gdy twoje zgłoszenie znajdzie finał w postaci naprawionego błędu na produkcji.
CYCLE TIME
to z kolei jest czas, jaki upływa na wykonaniu zadania – od chwili podjęcia do momentu zakończenia. Jeśli zespół limituje pracę w toku, to prawdopodobnie będzie niewielki, ale jeżeli ma rozgrzebane mnóstwo zadań – zaczyna, a nie kończy, to… no właśnie – CYCLE TIME będzie niewspółmiernie wysoki do rzeczywistego czasu, w którym można by dany problem rozwiązać.
Moją ostatnią istotną miarą kanbanową jest:
WYDAJNOŚĆ, czyli THROUGHPUT.
Wyrażana w liczbie zadań, które zespół jest w stanie zrealizować w danej jednostce czasu. Zrealizować, czyli doprowadzić do statusu „Done” zgodnego z przyjętą definicją ukończenia (DOD), jeśli takowa jest akurat stosowana. Przykładowo, jeśli w tygodniu realizowane jest średnio 5 zadań, to dzienna wydajność zespołu wynosi 1.
Po co nam ta miara? Ano po to, aby przewidywać, świadomie planować i podnosić sobie poprzeczkę.
Bardzo ciekawie o miarach stosowanych w Kanbanie pisała Iza Goździeniak w artykule „PODSTAWOWE MIARY W KANBANIE”. Polecam lekturę.
W scrumie
Zabieram Cię teraz na przegląd miar, które stosowałem lub stosuję w świecie iteracji, inkrementów, retrospekcji. Zapraszam do młyna! Cóż… nazwisko zobowiązuje 😉
VELOCITY,
czyli prędkość (zespołu). Kto z nas nie mierzy prędkości zespołu? Wyrażana w Story Pointach pokazuje, jaką ich liczbę (średnio) zespół dowoził w sprintach. Nie bierzemy tu pod uwagę wszystkich sprintów „od początku świata”, ale od trzech do maksymalnie pięciu sprintów wstecz.
Znajomość VELOCITY bardzo przydaje się do planowania kolejnych przyrostów produktów. Na podstawie tej miary PO może świadomie negocjować zakres produktu. Jeśli zespół zna swoją prędkość, jest w stanie określić swoje
CAPACITY,
czyli pojemność. Wyrażaną również w Story Pointach i często mylnie utożsamianą z VELOCITY. To poważny błąd, gdyż prędkość odnosi się do przeszłości. Pokazuje, ile Story Pointów zespół realizował w minionych sprintach – z jaką prędkością pracował. Natomiast CAPACITY odnosi się do przyszłości – a konkretnie do planowanego sprintu. Na jej podstawie możemy w miarę dokładnie przewidzieć, ile Story Pointów można zaplanować w kolejnym sprincie. Wyznaczając pojemność, należy wziąć pod uwagę zarówno prędkość zespołu z ostatnich kilku sprintów, jak również specyfikę planowanego sprintu – urlopy, święta, szkolenia i inne czynniki, które mają wpływ na to, ile Story Pointów realnie możemy „dowieźć”.
Na podstawie danych z kilku ostatnich sprintów jesteśmy w stanie wyznaczyć kolejną miarę, a mianowicie:
PREDICTABILITY
co w ojczystym języku oznacza przewidywalność.
Patrząc na to, ile Story Pointów planowaliśmy a ile rzeczywiście „dowoziliśmy” w kilku ostatnich sprintach, możemy policzyć przewidywalność zespołu. Im mniejsza różnica między planem a rzeczywistością, tym większa przewidywalność.
Po co nam to? Po pierwsze, podobnie jak znajomość VELOCITY, przewidywalność pozwala nam precyzyjniej zaplanować sprint. Po drugie, jeśli jesteśmy mało przewidywalni, a plany często rozjeżdżają się z rzeczywistością, to znaczy, że potrzebne jest dobre retro, że coś w procesie szwankuje. Może jesteśmy zbytnimi optymistami na planowaniu? Może boimy się brać więcej zadań do sprintu? Może nadmierna liczba błędów powoduje, że ciągle łatamy dziury, zamiast realizować ambitne cele sprintów? Jak nic – potrzebna inspekcja i adaptacja.
AGILE SPEED
Na własne potrzeby przyjmuję, że jest to czas, który upływa od chwili rozpoczęcia pracy nad jakąś historyjką do momentu wdrożenia jej na produkcję. Wyrażany najczęściej w dniach lub sprintach. Liczony dla każdej historyjki osobno. Na tej podstawie możemy wyznaczać średni AGILE SPEED dla zespołu, dla całej organizacji, w ujęciu rocznym, kwartalnym, etc… Sky is the limit. Miara pozwala weryfikować wpływ decyzji i zmian w całym procesie wytwórczym (zarówno w zespole, jak i poza nim) na czas potrzebny do dostarczenia wartości dla użytkownika.
Kolejna miara, to:
TIME TO DEPLOYMENT,
czyli czas od zakończenia prac w zespole scrumowym do chwili wdrożenia historyjki na środowisko produkcyjne. Wyrażany najczęściej w dniach. Najbardziej przydatny w środowisku, w którym wdrożeniem produkcyjnym nie zajmuje się zespół scrumowy w sprincie, a wydzielona jednostka – zespół adminów, release mangement, etc. Miara pozwala weryfikować wpływ decyzji i zmian procesu wdrożeniowego na cały cykl procesu dostarczania wartości dla użytkownika. Jest składową AGILE SPEED.
I jeszcze jedna miara związana z czasem:
TIME TO MARKET,
który jest czasem upływającym od „narodzin” inicjatywy do oddania jej w ręce użytkownika. Wyznaczany w dniach lub sprintach. Najczęściej wyznaczamy go od chwili pojawienia się historyjki w backlogu do wdrożenia na produkcję. Porównując z dwoma poprzednimi miarami – ta jest najdłuższa, bo obejmuje pełen cykl życia user story. Jeśli znamy AGILE SPEED, to pomiar TIME TO MARKET daje nam odpowiedź na pytanie, jak długo nasze inicjatywy muszą czekać na realizację – ile czasu „kiszą się” w backlogu, zanim trafią do sprintu.
A teraz coś z innej beczki:
ROI
Return of investment, czyli mówiąc po polsku „Zwrot z inwestycji”. Bardzo przydatny przy priorytetyzowaniu backloga. Pośrednio pokazuje, którymi historyjkami powinniśmy zająć się w pierwszej kolejności, gdzie będzie największy zysk przy najmniejszych kosztach. Liczony jest jako stosunek wartości biznesowej do poniesionych kosztów. Jeśli stosuję tę miarę w zespołach, to najczęściej wartość biznesową wyrażamy w gotówce, a jako koszty przyjmujemy estymatę historyjki w Story Pointach.
WASTED TIME
lub po prostu „czas zmarnowany”. Wyrażany w dowolnej jednostce czasu. Przydatny do identyfikacji „marnotrastwa” w procesie. Wywodzi się wprost z praktyk Lean. Pomaga zidentyfikować wycieki czasu, który nie jest inwestowany w rozwój produktu i realizację kolejnych przyrostów wartości.
Jak go mierzyć? W zespole, w którym użyliśmy tej miary na naszej tablicy scrumowej, zawisła koperta. Umówiliśmy się, że każdy członek zespołu, jeśli zauważy, że on sam lub ktoś inny „marnuje czas”, czyli zajmuje się tematami nieplanowani w sprincie, zapisuje to na karteczce, z informacją, ile czasu zmarnowano, a karteczkę wrzuca do koperty. Podczas retrospektywy koperta była otwierana, a zespół analizował, na czym stracił najwięcej czasu. Wychodziły z tego ciekawe akcje – np. Product Owner bardzo szybko przeorganizował backlog, tak aby w pierwszej kolejności można było wdrożyć porządny, czytelny dla zespołu wsparcia, mechanizm logowania zdarzeń, żeby do programistów nie napływały liczne prośby o analizę przypadków z produkcji.
HAPPINES INDEX
Tę miarę stosowaliśmy w jednym z zespołów przez kilka sprintów. Codziennie, przed wyjściem z pracy każdy wrzucał do zamkniętej urny (kartonu z otworem) karteczkę z buźką – zadowoloną, neutralną lub smutną – w zależności od tego, w jakim nastroju wychodził. Można też było na karteczce napisać przyczynę. Na retrospekcjach otwieraliśmy urnę, wysypywaliśmy karteczki i toczyły się ciekawe dyskusje prowadzące do wartościowych akcji – spektrum przyczyn radości i smutków było bardzo szerokie. Od relacji międzyludzkich po twarde tematy związane z architekturą, procesem wytwórczym czy kompetencjami.
CUSTOMER SATISFACTION
Niezależnie, czy pracujemy dla klienta wewnętrznego czy zewnętrznego, warto znać jego poziom zadowolenia z naszej pracy, z wartości, którą mu dostarczamy, etc. Jak to zmierzyć? Banalnie prosto. Chociażby wykorzystać metodę z karteczkami opisaną przy HAPPINES INDEX na zakończenie podsumowania sprintu. Jeśli nie chcemy się bawić w ten sposób, to można klienta poprosić o wypełnienie ankiety ze starannie dobranymi pytaniami – czy to po podsumowaniu czy w trakcie sprintu. Śmiało postawię tezę, że w przypadku tej miary ogranicza nas jedynie nasza wyobraźnia.
Hmm… myślę, myślę, i nic więcej nie przychodzi mi do głowy. Prawdopodobnie dotarłem do granic swojej pamięci, a to, co tu zostało napisane, to chyba wszystkie najważniejsze miary, które kiedykolwiek stosowałem w pracy z zespołami zwinnymi. Jeśli o czymś zapomniałem, a w przyszłości przypomnę, to na pewno uzupełnię ten wpis. Jeśli masz w swoim zestawie narzędzi inne miary i chcesz się podzielić, to proszę! Nie krępuj się! Można na przykład w komentarzu napisać. Zachęcam!
Warto też wspomnieć o tym, aby zadać sobie pytanie po co i co mierzymy? Dla przykładu można mierzyć lead time wraz z Happines index lub NPS. Otrzymujemy informację nie tylko o tym jak szybko dostarczamy wartośc klientom ale takżę jaki jest ich poziom zadowolenia: )
Bardzo cenna uwaga, Marcin – „co i po co mierzymy?”. Samo mierzenie dla mierzenia, bez praktycznego wykorzystania wyników to, moim zdaniem, nic innego, jak marnotrawienie czasu – waste.