W ubiegły poniedziałek miałem zaszczyt (i frajdę) poprowadzić warsztat w ramach spotkań Agile Wrocław. Oto kilka przemyśleń o metrykach, tych które śledzimy i tych które może powinniśmy, ale o co z różnych przyczyn nie jest łatwo.
Gdy Paweł z Agile Wrocław zaproponował by zapytać o coś osoby rejestrujące się na warsztat, wybór był prosty. Skoro mieliśmy dowiedzieć się czegoś o najprostszych metrykach lean, to chciałem skonfrontować to z tym, co uczestnicy już mierzą. Zapytaliśmy więc o jedną obecnie śledzoną metrykę.
Największa liczba uczestników odpowiedziała, że mierzy różnie nazywaną satysfakcję klienta. Do tej samej kategorii metryk produktowych można bez wahania wrzucić ilość rejestracji i retencję klientów.
Na drugim miejscu znalazła się prędkość zespołu (velocity), która wraz z wykresem spalania backlogu sprintu (burndown chart), czy też śledzeniem samych punktów i rozmiarów historii mocno zaznaczyła, że Scrum ma się dobrze.
Pełna lista wyglądała tak:
Satysfakcja klienta (happiness index, NPS)
Prędkość zespołu (velocity)
Wykres spalania sprintu (burndown chart)
Wydajność/Produktywność
Liczba bugów
Liczba wrzut
Liczba rejestracji/retencja klientów
Rozmiary historii (T-shirt sizing)
Dochód na pracownika (revenue per employee)
Czas rozwiązania problemu (resolution time)
Dług techniczny
Przepustowość (capacity) zespołu(?)
Czy jest tu coś leanowego? Część metryk takich jak wydajność czy produktywność prosi się o bardziej szczegółowe definicje, ale o leanową naturę można podejrzewać czas rozwiązywania problemu czy przepustowość zespołu. Nie byłem jednak zdziwiony, że nikt jawnie nie podał tu czasu realizacji (lead time), czy historii liczby zadań w statusie i opartego o to wykresu CFD. Trochę szkoda, choć naturalnie odbiło się to pozytywnie na ciekawości warsztatu, w trakcie którego mierzyliśmy bardzo proste dane – czas realizacji zadań, oraz na koniec każego dnia, liczbę zadań w każdym z (4) etapów pracy.
W pierwszej fazie gry, pomimo, że gdzieś na końcu flipa z zasadami była adnotacja o możliwości pomocy innemu graczowi, chyba nikt z tego nie skorzystał. Wszyscy byli zajęci, zajęci swoimi zadaniami. Blokady odzwierciedlały to, o czym często słyszymy na daily – że wymagania niejasne, niekompletne, że środowisko X leży, że nie ma VPN-u do klienta, że testerzy poszli sprawdzać coś na produkcji (bo gdzieżby indziej 😉 i tym podobne. W zamierzony, choć nie wiem czy świadomy sposób, na tym etapie gracze byli skupieni na wysokim stopnia wykorzystania… siebie. Gdyby opomiarować to liczbą godzin w biurze, ruszonych ticketów w Jirze i tym podobnymi kej-pi-ajami, to pewnie wszyscy powinni dostać premię. Tylko co z klientem? 🙂
Jedna drobna wydawałoby się zmiana – wprowadzenie limitu pracy w toku (WIP limit) spowodowała, że niezależnie od wybranych wartości przy każdym stole w czasie daily zaczęło kipieć od rozmów i pomysłów. Najpierw, co zrobić by sprowadzić kolumny z ograniczeniem do stanu “pod kontrolą”. Następnie jak przeprowadzić przez nie resztę zadań. W końcu, gdy gracze przećwiczyli zasady pomocy okazało się, że i kolejność czynności opartych na tej samej rundzie rzutów kośćmi może przynieść różne wyniki.
Pojawiły się dyskusje i pomysły zmiany limitów – nie we wszystkich grupach zaakceptowane. To rodziło zabawną sytuację, gdy zespołowi wydawało się, pewnie słusznie, że wie co dla niego lepsze, ale kierownictwo nieugięcie stało na straży raz ustalonych limitów.
Mała, drobna zmiana okazała się doskonałym katalizatorem współpracy a zespół przeorientował się na… no właśnie na flow. “Orientacja na przepływ” jak mówi jedna z praktyk Metody Kanban, skupienie na zapewnieniu szybkiego dostarczania wartości, a nie walce o pokazywanie jak jest się zajętym.
Jak zawsze świetnie było widzieć ludzi, którzy z pełnym zaangażowaniem walczą o każde oczko na kości, a potem o jego jak najlepsze wykorzystanie.
Powstaje pytanie, czemu nie zawsze tak się dzieje w naszych biurach? Czy największym winowajcom są bariery w naszych głowach? Tytuły w stopkach maili, które blokują programistę/testera/Opsa od wyjścia poza swoje “job description”? A jakie są te opisy stanowisk? Jak skonstruowane są systemy ocen i premii? Czy opierają się na szczegółowym wylistowaniu zadań, czy na nadaniu odpowiedzialności za dostarczanie jako grupa kompletnego produktu lub usługi. Potem już można oczywiście mierzyć wszystko za pomocą NPS-u?
W ostatnim czasie miary czy wykresy takie jak: dystybucja czasu realizacji, obserwacja starzenia się pracy w toku (WIP aging) czy udział procentowy prac niezaplanowanych coraz częściej nazywa się metrykami flow. Metrykami, które próbują wyciągnąć ludzi poza obozy Agile czy Lean, Metrykami skutecznie obniżają opór ludzi wobec technik komplementarnych do tego, czym żyjemy i co uważamy za element naszej zawodowej tożsamości. Może ich spróbujesz?
Jeśli chcesz poczytać o tym więcej to w podobnym duchu napisany jest najnowszy wpis na blogu Markusa Hammarberga.
Na koniec naturalnie podziękowania dla ekipy Agile Wrocław za zaproszenie i pomoc w organizacji warsztatu dla tak dużej grupy. Bez tego warsztatu nie byłoby pewnie tych przemyśleń. Dla bardzo zainteresowanych.. nagranie z tego wydarzenia dostępne jest na profilu Facebook Agile Wrocław.