Myth: Velocity is Productivity
We are going towards “Agile” Transformation. One of our goals is to increase velocities across all our teams by X %. Have you heard this? I have heard Marc Andreessen’s adage that “Software is eating the world” is becoming the differentiator for Industries that were previously thought to be more manual.
A company that is known for developing “Agile” products surveyed more than 18,000 customers and Software development professionals, and this is what they discovered
77% practice Agile Development.
–Atlassian Survey,2016.
The well-known Contributor of this game-changer is “Scrum” – A framework within which people can address complex adaptive problems while productively and creatively delivering products of the highest possible value.
Velocity is just a Complementary & Optional Practice in Scrum
When you start adopting Scrum, the total work remaining to reach a goal can be summed at any time. Various projective practises upon trending have been used to forecast progress like burn-down charts or cumulative flows. These have proven useful. However, these do not replace the importance of empiricism. Especially, agile frameworks like Scrum doesn’t mandate any practices to be used. However, these are Complementary practices that are found to be useful. These practices are used to build “Dashboards” to make decisions.
But the Agile development does not necessarily lend itself to the kind of dashboards and reports beloved by managers. Moreover, the few metrics it produces make little sense outside of the context of team planning. Given this shortage of usable information, it can be tempting to re-purpose velocity to measure productivity. After all, it’s a measure of team capacity, so it follows that changes over time could be used to indicate overall shifts in productivity?
Velocity is an option to Measure progress, not the value!
Alongside these complementary practices, the biggest risk with this approach is that a velocity is a planning tool rather than a specific measurement. It’s an estimate of relative capacity that tends to change over time, and these changes don’t necessarily indicate a shift in productivity. It’s also an arbitrary measure that varies wildly between Organizations, teams, and Products. As a result, there are no credible means of translating it into a normalized figure that will be used for meaningful comparison.
What is Velocity, then?
Velocity is an indication of the ability to turn Product Backlog into releasable functionality across time, or for a specified price.
I want to increase my team velocity == my goal.
Given that velocity is such an arbitrary measure, it is easy to game, Inflate it or Deflate it. By equating velocity with productivity, you create a “perverse incentive” to optimize velocity at the expense of developing quality software. Consciously or not, teams will start trying to increase productivity by massaging velocity upwards if the goal is set as an Increase in Velocity is directly proportional to the productivity. Worse still, they may start cutting corners to deliver things. This can lead to a build-up of technical debt, and the product they create will be brittle.
Magic Moment- Open the team’s burn-down charts.
Suppose you distribute burn-down charts to senior management. Every sprint, the progress line magically starts to intersect with the delivery target. The shape of the line may vary wildly, but somehow there’s a speeding up or slowing down in the second half of the sprint to meet the expectation.
Velocity is a measure of the amount of work that a team can do. This is not the same as measuring the value or impact of this work. Velocity may actually be relatively stable in a successful and well-established team as the amount of raw effort available for each sprint remains constant. In this case, putting artificial upwards pressure on velocity will only serve to distort estimates.
Can you really measure software productivity?
Productivity is determined by looking at the inputs and outputs of an activity. It’s easy enough to measure the inputs for software development, but it’s actually challenging to measure the outputs in any consistent way.
Most importantly, it is the Outcome that Matters, not the Output.
A raw, quantitative measure such as numbers of lines of code does not provide any reasonable guide. It is too dependent on wildly variable factors such as coding style, development language and implementation approach. It can also be counter-intuitive as well-written code that has taken time in crafting often requires fewer lines of code.
How do we Measure Value?
If you derive a measure of productivity from velocity, then you will see a statistical improvement. However, this is not the same as a successful development.
Ultimately, Agile Frameworks like the “Scrum” process framework relies on an empirical approach. The Empirical process relies on Inspection, adaptation, and transparency, enabling a continuous feedback loop between development teams and the commercial context. A more meaningful measure of success should focus on real-world benefits rather than abstract measures of normalized indicators. But remember,
A release is required to realize the Value.
So, Am I saying metrics are bad?
No, I am not saying “metrics” are useless; they are not just management indulgences; they help you gather information, decide on corrective action, and, most importantly, figure out how to evolve. However, if you tend to satisfy ongoing Management hunger for reports, you create meaningless overhead. End of the day, Software is Complex, and that can’t be predicted, but only forecasted!
Then, what do I measure?
Measure the value of your Investment. One of the ideas that Ken Schwaber put across is known as “Evidence-based Management “- He says, Evidence-Based Management for Software Organizations is the first useful method for transforming software from an expense into a profitable asset. Some of the key things to measure, for example:
The Agility Index™ software enables you to measure the improvement in business outcomes and track the return of your investment.
Covering EBM is out of the scope of this article; I would recommend going through the below link for more Information on EBM.
Source of References
Recent Posts
Subscribe To Our NewsLetter
Request More Info