Wasze Velocity to ściema

Ustalmy na samym początku jedną rzecz: Velocity (prędkość zespołu) to nie jest miara wydajności programistów.

Jeśli w poprzednim sprincie twój zespół bez problemu dowiózł 40 punktów, a management nagle żąda 50 w obecnym, to znaczy, że kompletnie nie rozumieją, jak działa Agile.

Gdy miara staje się celem

Mówi o tym stare porzekadło, znane jako prawo Goodharta: Gdy miara staje się celem, przestaje być dobrą miarą.

Kiedy góra używa velocity jako bata, żeby wycisnąć z ludzi więcej, zespoły robią to, co w ludzkiej naturze – po prostu się dostosowują. Zaczynają sztucznie zawyżać estymaty, żeby wyrobić normę. To, co kiedyś było zadaniem na 3 punkty, nagle staje się "piątką". Gratulacje dla zarządu: velocity właśnie wzrosło o 20%, ale w rzeczywistości nie dowieziono ani jednej dodatkowej linijki kodu.

Velocity to wskaźnik do planowania przepustowości (capacity). Istnieje tylko po to, by odpowiedzieć na jedno pytanie: Ile pracy możemy bezpiecznie wziąć na ten sprint, żeby nie zajechać zespołu?

Aby uzyskać prawdziwe, szczere velocity, potrzebujesz środowiska, w którym programiści czują się bezpiecznie i nie boją się podawać dokładnych estymat. Zaczyna się to od korzystania z niezależnego narzędzia do pokera estymacyjnego online – z dala od wścibskich oczu korporacyjnych dashboardów – gdzie zespół może szczerze i w swoim gronie przedyskutować złożoność zadań.

Chroń swoje sesje planning pokera, dbaj o szczere estymaty i pozwól, aby velocity było tym, czym miało być od początku: narzędziem do planowania dla zespołu, a nie celem do odhaczenia dla szefa.