… czyli KPI w SCRUMIE.

Zostałem zainspirowany do napisania tego tekstu przez trzygodzinną (rekrutacyjną) rozmowę ze Scrum Masterem. Połowę tego czasu spędziliśmy na jednym temacie — KPI (Kluczowe Wskaźniki Efektywności). Rozmowa zaczęła się od pytania: Jak rozpoznać dobrego Scrum Mastera po jego/jej wynikach? Jak pokazać kierownictwu, który SM jest lepszy, a który gorzej wykonuje swoje zadania?

Moje życie zawodowe zawsze było osadzone w biznesie i IT. Przez kilka lat na zmianę pełniłem role PM i analityka, w których mierzenie postępów i tworzenie wskaźników było dla mnie oczywiste od pierwszego projektu. Od samego początku mojej pracy w scrumie poważnie podchodziłem do śledzenia pracy i postępów i… dzisiaj myślę, że to był błąd. Za bardzo wierzyłem wynikom.

W moim pierwszym projekcie szczegółowe śledzenie postępów odwróciło moją uwagę od kluczowych kwestii: badań satysfakcji klienta i sprawdzania entuzjazmu zespołu. W końcu wszystko wyglądało dobrze na papierze, więc dlaczego klient miałby być niezadowolony? Dopiero dzięki reakcji bardziej doświadczonego Scrum Mastera udało mi się skierować projekt na właściwą ścieżkę.

W kolejnym projekcie zespół przypadkowo spowodował jeszcze większy problem. Stopniowo zmieniali swoje podejście do estymacji, nieznacznie je podnosząc. Nie było to widoczne, a nawet jeśli zaczęliśmy rozmowę na ten temat, ani Scrum Master, ani Product Owner nie mają prawa naciskać na zespół w kwestii zmiany estymacji. W rezultacie, przy stałej wydajności, zespół dostarczał mniej, więcej czasu poświęcano na poszczególne historie, było mniej błędów, zwiększyła się przewidywalność, ale po pewnym czasie satysfakcja klienta spadła. Zauważ, że wszystkie KPI (z wyjątkiem satysfakcji klienta) rosły lub pozostawały na tym samym poziomie, ale projekt zmierzał ku upadkowi. Wartość w pojedynczym sprincie zmniejszyła się, ale to naturalne, ponieważ najbardziej wartościowa praca została wykonana na początku. Jedyne rzeczy, które się zmieniły, to wczesne estymacje w backlogu, które rosły w miarę doprecyzowywania, oraz Burn Down Chart produktu, który się rozciągał. Wzięliśmy się w garść dopiero wtedy, gdy klient ogłosił, że jest zmęczony, że spodziewał się, że następne wydanie zostanie ukończone kilka tygodni wcześniej, że widzi, że zespół pracuje dobrze, ale wyniki go rozczarowały. Zespół przyspieszył, estymacje wróciły do pierwotnych, a wysoka jakość została zachowana.

Z obu sytuacji wyciągnąłem wnioski:

• nie wierzyć ślepo w KPI, bo to tylko liczby,
• najważniejsza jest satysfakcja klienta, bo to on decyduje o płaceniu za przyrosty,
• wykresy mogą jedynie dawać wskazówkę, gdzie może znajdować się problem, ale nie przekazują konkretnych informacji.

W ten sposób nie wierzyłem ślepo w miary zależne od:

• prędkości (zależnej od estymacji elementów Product Backlog),
• „wczorajszej pogody” (zależnej od poprzednich estymacji PBI),
• wydajności (zależnej od estymacji PBI),
• RPI (zależnego od zidentyfikowanych problemów PBI).

Wskaźniki pokazujące jakość produktu zależą od czasu przydzielonego do PBI (tj. wad na wydanie lub długu technicznego). Mogą one również pośrednio zależeć od estymacji poszczególnych PBI. Oczywiście wskazują one na stan produktu, ale nie na jakość pracy Scrum Mastera jako takiej. Tak więc odpowiedź na postawione pytanie Jak oceniać pracę Scrum Mastera na podstawie wyników? brzmi Nie na podstawie KPI, ponieważ mogą one pokazywać bezsensowne wyniki.

Jednocześnie zostawiam na szczycie listy te miary, których nigdy nie należy lekceważyć, tj. satysfakcję klienta, entuzjazm zespołu i czas na naukę, czyli zwinność całej organizacji, o czym napiszę innym razem.