skip navigation

Here you will find ideas and code straight from the Software Development Team at SportsEngine. Our focus is on building great software products for the world of youth and amateur sports. We are fortunate to be able to combine our love of sports with our passion for writing code.

The SportsEngine application originated in 2006 as a single Ruby on Rails 1.2 application. Today the SportsEngine Platform is composed of more than 20 applications built on Rails and Node.js, forming a service oriented architecture that is poised to scale for the future.

About Us

Why I don’t like Velocity measures for Product Development Teams

02/13/2014, 4:00pm CST
By Andy Morgan

You can go really fast in the wrong direction.

Here I may take artistic liberties with physics concepts but I trust the reader will understand the points without going all internet rage on the science.

If you have worked on or with a software development team that says they use Agile you have talked about velocity. “What is our velocity?” “What is the velocity of your team?” “Can you increase your velocity?” “Based on your velocity when can you have this done?” Some teams love to measure this and will grin when they talk about how many points they achieved in their sprint. Measuring is good and knowing how you are progressing and improving is important. But we have done ourselves a disservice by fixating on velocity. Look at the definition of velocity.

We can achieve tremendous velocity and completely miss our mark. Velocity cares about direction but it doesn’t care if it is the right direction. I prefer to talk about trajectory.

Trajectory brings forward a couple of important pieces of which the team must remain aware. Path and given forces. Our teams are looking to achieve something. Ship a product, complete a feature, eliminate a bug, improve performance, remove a capability, or any other list of meaningful objectives. Everyone of these will take us from the current state to a new future state (path). How fast we move along this trajectory is interesting but having a defined trajectory is more important. If you don’t know where you are going your measure of how fast you are going is meaningless.

So what about force? If we aren’t moving fast enough along our path we can apply more force to increase speed, right? We all know this is wrong. Back to the Mythical Man month or the nine women can’t make a baby in one month discussions. I won’t rehash these discussions.

There are multiple forces that we have to consider when looking at trajectory. Thrust, friction and counter forces all matter.

The diagram illustrates the three types of forces that act on a physical object and I’ve added a fourth which we deal with as humans trying to get stuff done.

  • Thrust — Developers, Beneficial Tools, Frameworks
  • Distracting Force — “It would be cool if it would…”, “I need you to attend this meeting”, Assholes on your team, shiny new tech, life
  • Friction — Poor tools, poor planning, personality conflicts, process for process sake
  • Counter Force — “We’ve sold that thing you are building twenty-four times so please hurry and get it done”, “I need to borrow one of your developers for …”, “Your team will also be responsible for”, life

One of these forces is positive (thrust), one of these forces can be bent to your will and used for good (friction), and two of these forces, generally, will be fighting against you the whole way (distractions and counter forces). Understanding this model shows you that thrust is not the only force that can be adjusted to have influence on trajectory and velocity. I frequently argue that working on reducing the counter forces is more productive in the early days. The same thrust, fighting against less counter force, produces improved velocity along your chosen path.

Working on the counter forces also has a multiplier affect. Counter forces on a team will always create distractions. Removing a counter force will also remove a distracting force. Removing counter forces and removing distractions will also improve the emotional state of your team. Nobody likes being taken off task when working on shipping products. The more you can create focus for your team the more success you will get from your team.

Improving a product team's speed and health is not always about what you add to the equation. Often it is better to start with what you can eliminate.

Tag(s): Home  Agile