Colors fade, temples crumble, empires fall, but wise words endure.
As everyone knows, many challenges we have in software development are around semantics. People seem to really get wrapped around the axel when in a meeting team members (including stakeholders) start using words that are similar to others or there is an assumed shared meaning. So this is not a very easy problem or challenge to solve, so I thought we would start discussing some of the terms that occur regularly in the agile development world.
Let’s start with Velocity. In my experience, sometimes it seems like the word velocity may have been a poor choice. When we talk about velocity in terms of agile software development, we are referring to the rate at which a team produces working software. Velocity is a metric and knowing a team’s velocity is key to agile planning, not to mention it helps drive predictability which is a major benefit of using iterative processes.
Most people when they think of velocity with agile, they instantly say “how fast the team produces.” This is only natural when you look at the dictionary definition:
Velocity – speed of motion, action, or operation; rapidity; swiftness
Now for the problem that this creates. Once the velocity for teams is published, the stakeholders and managers automatically start asking the question, “can’t the team go faster?” Or, “why is that team slower than the other?”
Volume – amount; quantity. Also, amplitude of sound.
The idea of quantity is clear, but it is also an appropriate metaphor to relate it to the wave or amplitude of sound in that it can vary. If we originally used the word Volume, would we hear “how do grow our volume?” Or, “you all need to turn it up and get more out!”
Another word that may also be good to use instead of Velocity is Throughput. When I worked in the process manufacturing world, that was the word we used when we talked about how much materials were moved through the production line or how much ultimately came out the back. We also use throughput when it comes to processing data, so it only makes sense that we would use throughput. This would lend an opportunity for a new abbreviation, much like bandwidth of an internet connection — 300 MB/s, we could have 28 SP/i (or Story Points per Iteration).
I guess at the end of the day, the word Velocity works as well as any other word and we are most certainly going to re-write all the books. And even if we did use a word different than Velocity, the stakeholders and management would still want more and want it faster.
But the next time someone asks your team to go faster, try getting them to see Velocity not as speed, but more as Volume. And explain to them that your team is more like bucket and just like that bucket, it can only hold so much.
Or, tell them that your team is like a fine-tuned system that has a particular throughput. You may be able to do some small tweaks to change the throughput, but pushing it to much will simply result in bottlenecks somewhere down the line or all-out system failures.
Let me know what you think? Does the word Velocity cause challenges for your organization? Look for more posts in the series and your suggestions for new words to explore are welcome.