„No dobrze, ale skąd będziemy wiedzieć, że wprowadzenie Scrum poprawiło nam efektywność pracy?” – to zdanie jest często wypowiadane przez managerów, z którymi rozmawiamy na temat wdrożenia Scrum’a. To pytanie jest z jednej strony zasadne, bo Scrum jest tylko pewnym frameworkiem, który ma poprawić efektywność pracy (szybkość dostarczania wartości do klienta), jakość produktu i zgodność produktu z oczekiwaniami klienta. Z drugiej strony, jak zaczynamy mówić o szczegółach, spotykamy się z niezrozumienim tego, jak mierzyć efektywność Scruma. Przyjrzyjmy się zatem, jakie użyteczne metryki możemy zastosować w zespołach Scrumowych i produktach tworzonych przez takie zespoły i czy powinno się mierzyć efektywność samej metodyki Scrum.
Warto najpierw przybliżyć dwa pojęcia, często spotykane przy definiowaniu metryk: Performance Indicators (PI) i Key Performance Indicators (KPI). PI mają pokazywać jak sprawnie działa organizacja, w odniesieniu do pewnego oczekiwanego poziomu. KPI to zbiór najważniejszych PI. Do PI i KPI definiuje się metryki i cele, które te metryki mają osiągać. Co zatem należy wziąć pod uwagę przy definiowaniu metryk i PI?
Zacznij od zdefiniowania pozytywnych zachowań
Podstawowym celem metryk w podejściu zwinnym nie jest kontrola ludzi, tylko wspieranie pozytywnych zachowań ludzi oraz kontrola procesu. Zdefiniowane oczekiwanych zachowań jest kluczem do dobrych metryk. Dopiero po ich zdefiniowaniu wybieramy metryki.
Przykład:
Załóżmy, że oczekiwanym zachowaniem jest utrzymywanie przez deweloperów wysokiej jakości kodu przez szybkie wyłapywanie i poprawianie błędów regresji. Aby osiągnąć taki cel, należy priorytetowo potraktować naprawę wszystkich regresji pojawiających się w trakcie dewelopmentu. Kolejnym krokiem jest zdefiniowanie metryk. Przykładową metryką może być czas naprawy defektów oznaczonych jako regresja. Sposobem pomiaru będzie czas pomiędzy wykryciem regresji przez automatyczne testy a wycofaniem lub naprawieniem błędu w kodzie. Celem dla takiej metryki może być maksymalny akceptowalny czas na naprawienie błędu (np. 24 godziny). Kolejną metryką dla tego samego oczekiwanego zachowania może być procent błędów regresji wyłapywanych przez „smoke testy” uruchamiane jeszcze zanim zmiana zostanie zintegrowana na master branch’u. Logika jest taka, że im więcej regresji wyłapią nam wczesne testy, tym lepiej. Celem dla takiej metryki może być oczekiwany poziom w procentach (np. 80%).
Przy definiowaniu metryk należy sobie odpowiedzieć na pytania: Czy tak zdefiniowana metryka będzie wspierać właściwe zachowania? Czy sposób mierzenia nie spowoduje, że ludzie znajdą sposób na „obejście”, które spowoduje, że metryka będzie „zielona”, ale jakość wcale nie ulegnie poprawie.
Spójność metryk
Kolejnym bardzo ważnym aspektem jest spójność metryk. W systemach złożonych musimy uważać na to, żeby nie wpaść w pułapkę lokalnych optymalizacji. W wielu organizacjach pojawiają się sprzeczne oczekiwania: chcemy mieć kod najwyższej jakości, jednosześnie chcemy dostarczać klientowi produkt jak najszybciej i jak najtaniej. To management (który ostatecznie definiuje metryki) musi wiedzieć, gdzie leży punkt, w którym zachowany jest zdrowy balans pomiędzy sprzecznymi celami lokalnymi i zachować spójność metryk w całej organizacji. Scrum daje naturalną przewagę nad waterfall’em, ponieważ nie dzieli zespołu na architektów, programistów, testerów. Przy podziale zespłu na specjalizacje, zywkle otrzymujemy inne metryki dla programistów, a inne dla testerów. Wynika to głównie z lokalnych optymalizacji – inne cele mają ci, którzy tworzą produkt, inne ci, którzy ten produkt testują. W Scrum’ie metryki są optymalizowane pod kątem ostatecznego sukcesu produktu, a nie sukcesu poszczególnych działów organizacji. Wszyscy mają ten sam cel – zachwycić klienta.
Metryki muszą być spójne w taki sposób, aby nie było między nimi silnych konfliktów, które powodują, że możliwe jest spełnienie tylko jednej z nich i zespół musi sam wybierać, której. Podam przykład sprzecznych metryk, z którym spotkałem się w jednym z projektów waterfall’owych. W pewnym momencie organizacja ogłosiła, że stawia na jakość i ustawiła cel na „0 defektów” a jednocześnie funkcjonował milestone, który mówił, że w pewnym momencie cała funkcjonalność ma być „zakodowana” (ale nie musi być w pełni przetestowana). Efekt był taki, że najpierw cała organizacja pracowała tylko nad jednym celem, który był pierwszy sprawdzany przez management, czyli nad zakodowaniem funkcjonalności, tworząc w międzyczasie górkę defektów.Niespójne metryki mogą powodować, że organizacja jako całość nie będzie działać sprawnie. Będą też budzić naturalną frustrację.
Mierzalne cele
Z mierzalnością celów dla PI i KPI sprawa nie jest taka oczywista. Ja nie mam przekonania, że zawsze trzeba wyznaczać cele dla PI. Czy lepiej powiedzieć, że chcemy przejść z obecnego pass rate 50% na 85%, czy może lepiej powiedzieć, że chcemy poprawić go tyle ile się da, tak szybko jak to możliwe? Konkretny cel, czy może kierunek w jakim mamy zmierzać oraz obserwacja metryk i ciągła dyskusja, co jeszcze można w danym temacie poprawić? Wydaje mi się, że warto sobie odpowiedzieć na pytanie, jakie są zalety i wady obydwu podejść.
Główną zaletą mierzalnych PI jest jasno postawiony cel przed ludźmi i łatwość w komunikowaniu tego celu. Główną wadą mierzalnych PI jest ustawiona poprzeczka do osiągnięcia. Nie motywuje to ludzi do jeszcze lepszych wyników. Może tam, gdzie wydaje się, że można poprawić wskaźnik o 20%, zespół będzie w stanie poprawić go o 200% (jeśli poczuje, że to jest ich cel, a nie coś, co zostało narzucone z góry). Nie mam dobrej odpowiedzi, co z tymi mierzalnymi celami, bo to mocno zależy od kontekstu i dojrzałości zespołu.
Uważam jednak, że w każdym przypadku najlepiej będzie jeśli to zespół, który będzie odpowiadał za wyniki, będzie miał największy wkład w określenie metryk i celów, które mają zostać osiągnięte.
Metryki współtworzone przez osoby, których praca jest mierzona
Wysłuchanie zespołu, dyskusja nad właściwymi metrykami i zgoda na określenie celów przez zespół ma jedną zasadniczą korzyść. Zespół przyjmuje uzgodnione metryki i cele jako swoje. Ten niuans ma klolosalne znaczenie, ponieważ metryki nie konsultowane z zespołem, są postrzegane jako metoda kontroli a nie sposób na wykrycie problemów w procesie i pomoc w ciągłym doskonaleniu. Z mojego doświadczenia ludzie chcą pracować w uporządkowanych projektach i lubią dyscyplinę procesową, jeśli ramy i zasady są według nich są rozsądne i dobrze zdefiniwane.
Co do definicji celów PI i KPI to inaczej rozmawia się o osiąganiu celów zdefiniowanych przez zespół niż o narzuconych celach. W pierwszym przypadku jest to analiza: „przyjrzyjmy się co nam mówią metryki i co możemy zrobić, żeby je poprawić” lub świętuje się sukcesy. Cele narzucone często prowadzą do defensywnych zachowań i (jeśli są nie spełnione) szukania winnych.
Prostota i stabilość
Metryki powinny być też możliwie jak najprostsze i stabilne w czasie. W organizacji, gdzie mamy dużo skomplikowanych, zmieniających się metryk, zyski z ich mierzenia i analizy będą raczej mizerne.
Przykłady metryk, które mają zastosowanie w zespołach zwinnych
Metryki procesowe – przewidywalność i optymalizacja procesów:
- Z metryk Scrum – prędkość zespołu (team velocity)
- Doskonale sprawdzają się metryki Kanbana:
- Average Story/Defect Cycle Time – średni czas od startu do zakończenia implementacji story/defektu.
- Story/Defect Cycle Time Distribution – dystrybucja Story Cycle Time (to typowa metryka Kanbanowa, ale doskonale się sprawdza, ponieważ
odcina się od estymat story i pokazuje zmienność czasu zamykania story i defektów /przewidywalność procesu/) - Cumulative Flow Diagram.
- Ilość defektów w backlogu.
- Average Defect Lead Time.
- Average Defect Cycle Time.
- Defect Ageing.
- Story Ageing.
Metryki jakościowe:
- % testów automatycznych w całym zakresie testów.
- % testów automatycznych, które wykrywają regresję jeszcze przed integracją kodu z master branchem (% testów w smoke testach) w ramach środowiska Contiuous Integration.
- % testów zakończonych sukcesem (pass rate), które są uruchamiane na każdej zbudowanej wersji produktu.
- Metryki unit testów – pass rate, coverage, itp.
- % i ilość defektów, które zostały zgłoszone przez klienta (nie zostały wykryte przez nasze testy).
Metryki produktowe i biznesowe:
- Metryki biznesowe (finansowe, sprzedażowe).
- Zadowolenie klienta z produktu.
- Procent używanych przez klienta funkcjonalności.
Inne metryki:
- Team Morale Index
- Rotacja pracowników.
Nie wszystkie metryki, które opisałem są definiowane w Scrum Guide. Wybierając metryki dla swojej organizacji można czerpać garściami z szeroko pojętych dobrych praktyk programistycznych, wskaźników biznesowych, czy metryk innych metodyk (Kanban). Jestem przekonany, że do metryk trzeba podejść podobnie jak do implementacji Scruma: nie może być to cel samym w sobie, powinna to być natomiast droga do poprawy efektywności pracy organizacji (jakości, zadowolenia pracowników, czasu dostarczania produktów). Dlatego mierzyć powinno się te parametry, które są najważniejsze dla konkretnej organizacji, bo każda organizacja ma swoje wyjątkowe, unikatowe środowisko, problemy i inną mieszankę różnych ludzkich osobowości. Pamiętajmy zatem, żeby nie mierzyć efektywności Scruma. Mierzmy efektywność organizacji.
Przemek
(z cennym wkładem Lecha)
