After a few solid sprints, the next logical concern is the team’s velocity. How can I measure speed? Is my team moving fast enough?

It is very tempting to default to micromanagement and to measure each engineer’s performance. I’m not against individual performance (it is helpful for compensation adjustment), but it doesn’t tell the whole story about your team’s speed.

Another common pitfall is thinking that a slow day/break reduces velocity (crazy, but it happens.) Breaks are as necessary as the car’s brakes: if you want to get to your destination faster without injuries, you need to know when to hit the brakes.

The team velocity is determined by the slowest step in the process. Not even talking about blockers, but that specific stage in the process that you can’t speed up no matter how many engineers throw at it.

One example is the QA stage. The QA work defaults to the team if you don’t have a QA engineer. Engineers would prefer to start working on their next task instead of doing QA, especially testing other’s people work.

It doesn’t matter if you are using that ugly Upwork desktop app that takes screenshots of your developer’s screen or Clockify to track to the second; the team velocity is determined by the slowest step in the process.

Did you like this post? Subscribe!

Powered by MailChimp

LEAVE A REPLY