Let's talk about the difference between Speed and Velocity.
🤔 Why you should care about it
"Velocity and speed are different things. Speed is the distance traveled over time. I can run around in circles with a lot of speed and cover several miles that way, but I'm not getting anywhere. Velocity measures displacement. It's direction-aware." - Shane Parrish, Farnam Street.
High-growth technology companies often confuse speed and velocity. They tend to optimise decision-making and organisational design to complete tasks or deliver features faster (speed). But more features, faster, mean something other than that the team can deliver more value to users. Savvy leaders also monitor velocity, which is the progress they make towards achieving their goals.
Overall, speed and velocity can be essential metrics for understanding the performance of an organisation, but they measure different aspects of its work.
😫 Problem(s)
High rate of defects or lack of progress towards the team's goals —> focusing too much on speed could lead the team to prioritise completing tasks quickly at the expense of quality or long-term progress.
Low productivity and efficiency —> focusing too much on velocity could lead the team to prioritise making progress towards their goals at the expense of completing individual tasks quickly and efficiently.
😃 Solution
In general, it's essential for an engineering team to maintain a balance between speed and velocity and to consider both measures when evaluating their performance and making decisions about how to allocate their resources.
To optimise velocity, be very specific on the objective to reach (direction) and only optimise the speed of tasks and projects that contribute to the objective. You should shave away any other tasks, projects, and ideas which are distractions.
💡 Key Concepts
Productivity —> the team's ability to complete tasks and deliver valuable software efficiently and effectively.
Value —> the benefits and advantages the team's work provides to its users and stakeholders, measured in usage, satisfaction or revenue.
Objectives —> what they should achieve to deliver as much value as possible while being as efficient as possible.
😡 Detractors
"We're a startup; we need to be able to change direction often" —> while it's essential to be good at course correcting, especially before Product-Market Fit, changing too often the direction will always result in low velocity.
"Focusing too much on velocity decreases quality" —> an engineering team shouldn't focus only on value generation since short-term choices permanently impair long-term velocity. It's all about choosing the right objectives.
"Team members are burned out from ever more ambitious objectives" —> organisations run marathons, not sprints, so it's essential to always plan for cool-down times during a year and not jump from one objective to the next.
📚 Top book
Agile Software Development: The Cooperative Game - Alistair Cockburn
🗂 See also
📝 Top content
Understanding Speed and Velocity: Saying "NO" to the Non-Essential - Farnam Street
Velocity in Software Engineering - Tom Killalea
Engineering Velocity: The Need for Speed in Software Engineering - Eiso Kant & Jason Warner