In agile environments, velocity is commonly used to measure how much a team delivers each iteration. In this article I will relate this metric with concepts from classical mechanics, telling why you should always consider velocity towards your goals instead of going as fast as you can.
The objective of this article is not to explain what velocity is. I assume you already know this concept. If you would like a more detailed article about velocity, please let me know in the comments or any other options of contact.
Physics
You should have studied it in school: speed is the rate which an object changes its position. It is a scalar quantity, meaning it does not have a direction involved with the measurement. If you look at a speedometer, for example, you can’t tell if the vehicle is heading north, south or any other direction.
Velocity, on the other hand, tells you where you are going: together with speed, it has a direction. For example: your bicycle is 17 km/h northeast, Mr. Fredricksen house is 12 km/h up etc.
You Need to Know Where You Are Going
Consider I want to visit Argentina, and I live in Porto Alegre. Imagine a one-dimensional world, where I can either go left or right:
I know my vehicle can maintain an average of 70 km/h in this trip. Argentina is 700 km from where I am. It would take me 10 hours to reach Argentina.
Regardless my average speed, I need to go left. Otherwise, in a couple of hours, I will end up in the Atlantic Ocean. Heading towards my objective is much more valuable than knowing the average speed of the trip.
The Direction You Are Going Needs Constant Adjustments
Back again to the three-dimensional world (represented in two dimensions in the map), consider this route:
Check the arrows representing the velocity at some points of this fictional trip: they have the speed and direction. Most of the time they don’t point to the objective (Monte Caseros, Argentina). It was unimportant the instant velocity at any given time. The important fact is that velocity was adjusted to maintain the vehicle on the right road towards the objective.
Success in Agile Environments
Why do you create a product or service? I suppose it is to create value to someone: automate manual tasks, facilitate someone’s work/life, make someone save/earn money.
When we talk about product development, you don’t deliver effort, lines of code or even new features: you deliver value. In an agile environment, you should do that in small parts, constantly (incrementally and iteratively). You should reassess your plan and the value to be delivered frequently.
If the value can’t be demonstrated by the delivery itself, the incorrect set of work was selected. With a properly managed backlog, it should rarely happen.
Tips on how to do it are discussed in the article Delivering Incrementally.
Velocity Towards the Goal
Having clear goals helps us defining strategies to achieve them. Even if a team can create valuable deliveries, they may not be aligned with the goals.
Imagine a product goal like “reduce bug tickets in 40%”. The team works on creating new features like making the colors of the user interface customizable, but don’t put hands on code to fix bugs. Even valuable, these outcomes aren’t aligned with the defined goals.
Not having goals is more harmful: it will require effort just to have an idea what needs to be done (remember: effort, code or features aren’t valuable by themselves).
In cases like this, the team may have a great velocity. If it is not pointing to the goal, maybe the team isn’t delivering any value. Compare with the trip example from the beginning of the article: does it matter I can travel at 200 km/h, trying to visit Argentina, if I take the direction to the right? I will end up in the Atlantic Ocean and, maybe, the trip is over.
Velocity Without Direction is Speed
If velocity isn’t aligned to the goals, it is just like looking only at the speedometer.
First, define goals. Then focus your effort on them (preferrably, one at a time - otherwise you aren’t focusing). Having your velocity pointing towards a goal will give you confidence you’re delivering maximized value, not some nonsense effort.
Bonus: Jean’s Law
I could not finish this article about a metric without mentioning the generalization of Goodhart’s Law, by Marilyn Strathern:
When a measure becomes a target, it ceases to be a good measure.
As you may know, my last name is Waghetti, not Goodhart. Jean’s Law was coined by Matias Schertel and states that:
Everytime someone talks about metrics, Jean will quote Goodhart’s Law.
I do so because I’ve seen many times people paying more attention to the numbers rather than the meaning behind them. As Robert Martin points in Clean Architecture:
“(…) a metric is not a god; it is merely a measurement against an arbitrary standard.”
Use metrics! But use them sensibly.
