Imagine a thrilling software development race where developers zoom around the office on tiny race cars, navigating coding challenges and collecting story points like Mario collects coins. The faster they go, the more “velocity” they earn, bringing them closer to the coveted Golden Keyboard Trophy. Sounds exhilarating, right?
But let’s pause for a moment. While the image of developers racing around may bring a smile to your face, the reality of relying solely on software development velocity to measure progress isn’t always as amusing.
In this blog post, we’ll explore the limitations of using velocity and why it can sometimes feel like an endless pursuit of speed. Buckle up and get ready for a joyride through the quirks and pitfalls of measuring progress with software development velocity.
Software Development Velocity vs Speed
“I feel the need, the need for speed velocity!”
In the world of software development, velocity has become the buzzword of the moment. However, when we strip away the fancy terminology, we find that what people are calling development velocity is actually just speed.
Speed is defined as “the rate at which something can move,” but velocity adds an extra dimension — it’s speed with a purpose, speed with a direction. Developing fast is only valuable if it’s the right thing. Speeding to New York is great, but not if you were supposed to be in Florida.
Placing too much emphasis on speed alone, without considering the direction, can lead to problems. Perhaps the term “velocity” has gained popularity because it conveniently masks the inherent dangers and pitfalls of an obsession with speed. It is easier to understand that there is a limit to how fast a team should go – that going too fast is unsafe. But by calling it software development velocity instead, somehow, that concern fades away. It’s like velocity creates a veil, hiding the realities beneath the surface.
The Limitations of Development Velocity
Outcomes Over Output
One significant limitation of velocity is its focus on output rather than outcomes. Completing a large volume of work doesn’t necessarily translate into valuable results. Delivering numerous features is meaningless if they fail to address user needs or enhance the product’s value. Development velocity fails to account for quality or user satisfaction, providing an incomplete and potentially inaccurate picture of progress.
Historical, Not Predictive
Velocity in software development is a lagging indicator that looks at past performance, failing to provide insights into current or future trends. Teams relying solely on velocity may overlook potential roadblocks or emerging issues until their productivity is affected. By the time a problem is identified through a drop in velocity, it may have already impacted the project’s timeline and overall progress.
Unintended Consequences
Goodhart’s Law states that when a measure becomes a target, it ceases to be a good measure. Fixating on development velocity as a performance metric can lead to unintended consequences. Teams driven to increase velocity may inadvertently prioritize speed before delivering genuine value. This can result in the infamous phenomenon of gaming the system, where strategies are employed to artificially inflate velocity. Shortcuts may be taken, compromising the quality of work, and estimations might be exaggerated to create the illusion of productivity.
Ultimately, the metric intended to assess progress loses its integrity, providing an inaccurate depiction of the true state of affairs. It’s a cautionary tale of how an excessive focus on velocity can have far-reaching consequences.
Software Development Can Be Unpredictable
Software development is inherently complex and unpredictable. Velocity assumes a consistent and predictable workflow, ignoring the inherent variability in tasks and challenges. Unforeseen issues, changing requirements, and technical complexities can impact a team’s ability to deliver work at a consistent pace. Relying solely on software velocity disregards this variability and can lead to misguided expectations and unrealistic goals.
Understanding how many story points your team completes each sprint (what most refer to as “velocity”) can be helpful, but only in a limited context. It is useful for a team to understand this number as a guide when planning their next sprint. If nothing has changed in the team makeup, then it is reasonable for them to commit to a similar number of story points in the next sprint. If changes are on the horizon (e.g., an upcoming vacation), they should consider committing to fewer story points. The team can use this number within their team for planning purposes, but it should never be used outside the team. Doing so, as we’ve already seen, can be dangerous.
In the exciting race of software development, velocity has often taken the driver’s seat as the primary metric to measure progress. However, as we’ve explored the limitations of relying solely on velocity, it becomes clear that a more comprehensive approach is needed to accurately assess software development progress.
We must consider multiple dimensions beyond velocity to gauge software development progress. Outcomes must take precedence over output, focusing on delivering genuine value to users. Real-time insights and adaptability to changing circumstances become crucial in navigating the unpredictable nature of development.
Next time, we’ll delve deeper into some metrics your team can consider that provide a more comprehensive view of your software development team’s performance. Until then…
def coding():
while True:
iterate()
add_touch_of_magic()
have_fun()
Keep coding, keep iterating, and may your software always run with a touch of magic.
-
Dusty Rowe
