February 23, 2018

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”, this 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 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, at any point in time the total work remaining to reach a goal can be summed. Various projective practices upon trending have been used to forecast progress like burn-downs 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 is 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. 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 as a measure of 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 that we have, the biggest risk with this approach is that 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. There’s no credible means of translating it into a normalized figure that can 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 demonstrate an increase in productivity by massaging velocity upwards, if the goal is set as 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

If 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 very difficult to measure the outputs in any consistent way.

 

Most importantly, it is 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. This is not the same as successful development.

 Ultimately, Agile Frameworks like “Scrum” process framework relies on empirical approach, Empirical process relies on Inspection, adaptation and transparency, that enables continuous feedback loop between development teams and the commercial context. A more meaningful measure of success should take this into account and focus on real-world benefits rather than abstract measures or 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 indulgence, they help you gather Information, decide on  corrective action , most importantly how to figure out how to evolve. If you tend to satisfy on-going Management hunger for reports, you end up creating 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. Especially the,

  • 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 scope of this article, I would recommend to go through the below link for more Information on EBM, https://www.scrum.org/resources/evidence-based-management-guide

 

Source of References

www.atlassian.com

www.scrum.org/resources

www.benmorris.com  

www.hbr.org