Myth: Velocity is Performance
Day by day we are approaching Agile transformation. One of the most important goals for us is to increase the velocity of commands by X%. Have you heard about it? Mark Andreessen’s words that “software is eating the world” are becoming a hallmark of industries that were previously less automated.
The Agile product company surveyed over 18,000 clients and software engineers.
77% practice Agile
Atlassian survey 2016
A notable contribution to this game is Scrum, a framework by which people can solve complex adaptation problems, effectively and creatively provide products with the highest possible value.
Velocity is an optional and optional part of your Scrum practice.
When you start using Scrum, all the work that needs to be done to achieve a goal can be summarized at any time. Various projective practices are used to predict progress, such as burnout charts or cumulative flow charts. They turn out to be quite useful. However, they do not dispute the importance of empirical judgment. In particular, Agile frameworks like Scrum do not require any practice. However, these additional practices are often helpful. All of these methods are used to build dashboards that help make decisions.
But Agile development doesn’t have to respond to the dashboards and reports that managers love. The few metrics it produces make little sense outside of the context of team planning. Given the resulting lack of information, it might be tempting to reuse velocity to measure performance. After all, this is also a measure of the team’s potential, which means that its change over time can be used to determine the change in performance, right?
Velocity is a way to measure progress, not a specific amount!
Along with complementary practices, the biggest risk in this approach is that velocity is a planning tool, not a specific value. This is an estimate of relative performance and tends to change over time, but these changes do not necessarily indicate a change in performance. In general, this is a convention and varies greatly between organizations, teams and products. There is no reliable way to represent this metric as a normalized number that can be used in a constructive comparison.
Then what is velocity?
Velocity is a measure of the ability to turn a product backlog into workable functionality over a period of time or a specific cost.
My goal is to increase the velocity of the team.
Given that velocity is a conditional indicator, it is easy to play with it, inflate and deflate it. By equating velocity with performance, you create a “distorted stimulus” to optimize velocity through quality software development. Whether consciously or not, teams will try to demonstrate an increase in performance by increasing velocity. If such a goal is set, then velocity will become proportional to the performance. But teams will start cutting corners to deliver functionality faster. In turn, this will lead to increased technical debt, and the product that teams are developing will become more and more fragile.
Magic moment: open the team task burnout diagram
Let’s say your task is to show combustion charts to management. During each sprint, the progress line will magically intersect with the goal of delivering the product. The shape of the line can vary a lot, but somehow there will be acceleration or deceleration in the second half of the sprint to meet expectations.
Velocity is a measure of the amount of work a team can do. This is not the same as a measure of the value or impact of that work. Velocity can indeed be relatively stable in a successful well-coordinated team, as the amount of effort required in each sprint remains the same. In this case, artificial pressure on velocity will only distort the picture.
How do you measure performance then?
Performance is determined by analyzing the inputs and outputs of an activity. It is easy enough to measure the inputs to the software development process, but it is more difficult to measure the outputs in any logical way.
The bottom line is more important than the output.
A crude quantitative measure such as the number of lines of code will not provide any rational information. It depends too much on changing factors such as coding style, development language, and implementation approach. This metric can be counterintuitive, as well-written code that has taken a long time to develop often takes fewer lines.
How do you measure value?
If you infer performance from velocity, you will see a statistical improvement. But it will not mean successful development.
Ultimately, Agile frameworks like Scrum take an empirical approach. The empirical approach, in turn, relies on validation, adaptation, and transparency to provide a continuous loop of feedback between development teams and the business. A more meaningful measure of success should focus on real benefit rather than abstract normalized metrics.
Remember, release is about value.
Am I saying metrics are bad? In no case. I’m not saying metrics are useless. They will help you gather information, make decisions about corrective actions, and most importantly, understand which way to go. If you tend to satisfy the constant hunger of managing reports, you end up creating meaningless overhead. After all, software is complex, its evolution cannot be predicted, but it can be predicted!
Then what to measure?
One of Ken Schwaber’s ideas is called Evidence-Based Management or Evidence-Based Management. He says evidence-based management of a software development organization is the most useful way to transform software from cost to profitable assets.
EBM is beyond the scope of this article, so I recommend you follow this linkif you would like more information on this topic.
On the eve of the start of the course Agile Project Manager we invite everyone to a free demo lesson on the topic: “Agile Project Valuation Techniques for Various Contexts”…
Participants, together with an expert teacher, will analyze the types of project and task assessments, depending on the urgency, size and complexity of the scope of work.
