Najlepszym punktem wyjścia jest droga od rozpoznanej potrzeby do rezultatu używanego przez odbiorcę. Jeżeli implementacja trwa trzy dni, ale decyzja o zakresie czeka sześć tygodni, zwiększanie tempa programowania nie rozwiąże problemu. Trzeba zobaczyć kolejki, zależności i pracę rozpoczętą w zbyt wielu miejscach jednocześnie.
Przepływ bez jakości nie jest poprawą
Czas dostarczenia i częstotliwość wdrożeń warto obserwować razem z awaryjnością zmian, czasem odtworzenia działania i ilością poprawek. Szybszy przepływ, który zwiększa liczbę problemów produkcyjnych, jedynie przesuwa koszt na później.
Dostarczona zmiana musi mieć oczekiwany skutek
Zespół może sprawnie publikować funkcje, z których nikt nie korzysta. Dlatego każda ważna inicjatywa potrzebuje miernika powiązanego z jej celem: krótszego czasu obsługi, większego udziału zakończonych procesów, mniejszej liczby błędów albo zmiany zachowania użytkownika. Taki miernik powinien mieć także zabezpieczenie przed poprawą jednego wyniku kosztem innego.
W praktyce wystarczy niewielki, stabilny zestaw miar i regularna rozmowa o trendach. Przegląd powinien kończyć się jednym eksperymentem: ograniczeniem pracy w toku, uproszczeniem decyzji, automatyzacją testu albo usunięciem zależności. Dopiero później można ocenić, czy oczekiwany sygnał się zmienił.