Can Your Team's Velocity Be Too Fast?

Yes. Thank you for coming to my TED talk.

But seriously, this was something asked earnestly by a member of my team this week, and I think is due some discussion.

Velocity as measured by frequency of deploys can in fact be too fast, and this is actually something that's accounted for in Accelerate. It's why we also need to account for the change failure rate, which tells us how based on how often we push something to production it negatively impacts the end user, and has to be reverted, rolled back, or patched in some way.

Though high change failure rate signals that your velocity is too high, it doesn't tell you what to do about it. Where you need to make changes is going to depend on your software development process. But it can give you some clues. Maybe the review process before code is merged isn't thorough or consistent enough. See my articles on What's in a Code Review or 9 Common Pull Request Failure Modes. At minimum you should ensure you have a code review checklist. You can sign up for my emails to get a head start on that if you don't have one.

You could also opt to start pair programming more in order to address this, which brings the benefits of always on code review.

It could also signal that you're not spending enough time on the specification or design of the system, from either an architectural or product perspective, ensuring that you're building the right thing. This can be addressed by spending more time with the product team in order to understand what the user needs, and how you know that, as well as if this is the easiest way to verify that. From an architectural perspective you can address this by looking at the potential sources of volatility in your system, the number of users this solution needs to be able to address, as well as where in their life cycle the users are, and if the recently implemented solutions meet the needs of both the number and life cycle of those users. If not that may be something that needs to be integrated into your architectural design process.

More than likely though it's that your team feels pressured to get things out quickly, and so they're rushing and cutting corners. This is where it becomes important to enforce in your words and actions that you shouldn't rush your current work, because ultimately it will end up costing you far more than doing it right the first time.

It may or may not be moving too fast if members of your team express that they feel like things are moving too quickly. That could be a sign that the team's velocity actually is too quick, but it could also be a sign of too high of a cognitive load on the team.

Each of these problems is going to result in slightly different solutions, but in the end all of them are going to result in changes that result in the team going a little bit slower in terms of raw velocity to dramatically increase the net output of the team.

I'd love to hear about other signs that you look for indicating that your team's velocity is too fast. Tell me about it via Twitter (@brit_broderick) or email.