In the agile world, especially within the Scrum framework, much emphasis is placed on the velocity of a team.  A team’s velocity is defined as the number of story points that a team typically completes within a sprint cycle.  The idea is that by using past velocity as a guide, the team will be able to pick an appropriate amount of work for the upcoming sprint cycle. 

The term velocity is borrowed from the physics world, but there’s a problem with the metaphor.  Velocity in the physics world combines the speed and direction of a force, yet in the scrum parlance there’s no notion of direction, simply speed.  What then should we use for direction? We often try to think in simple one dimensional terms of forward or backward, but there is almost always more nuance to it than that. 

If your intent is to go East but your team’s technical results are sending you Northeast, then you have only achieved 50% efficiency (half of the team’s efforts were spent going North which wasn’t your desired direction). If the team’s technical results aren’t aligning with your desired business results then it may be the team is driving you North, South, or worst yet West. 

Why would a team spend effort not being efficient?  While this inefficiency can happen in legacy code bases where people are afraid to make direct changes, it can just as easily happen in greenfield projects where developers attempt to implement defensive coding practices to protect themselves from prior pains they’ve experienced.  The very nature of sprints reinforce the idea that everything could change during the next sprint which has the psychological effect of forcing developers to protect their future selves from the work they’re doing today. Unfortunately humans aren’t very good at predicting the future.

Developing trust, candor, and empathy within the team is vital to increasing your efficiency.  If the entire team knows what they’re building, why they’re building it, and who they’re building it for they’re far more likely to correctly determine how to build it.  If they trust the vision and the developers around them they’re also less likely to clutter your project with unnecessarily defensive code or needless abstraction which simply serve to increase the story points associated with tasks.  The speed aspect of velocity is important, but the directional aspect is actually much more important because It doesn’t matter how fast you build the wrong thing.

Reid Evans is a senior consultant with ResultStack, sought after speaker and an expert in agile methodology. When he’s not helping clients solve complex integration problems, he enjoys cycling and classical guitar.