We are moving toward the "Agile" Transformation. One of our goals is to increase velocities across all our teams by X%. Have you heard this? 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 known for developing “Agile” products surveyed more 18,000 customers and Software development professionals, which 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 point in time. 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 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. 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. There are 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.
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 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 a successful development.
Ultimately, Agile Frameworks like “Scrum” process framework relies on the empirical approach. The empirical process relies on Inspection, adaptation and transparency, enabling continuous feedback loop between development teams and the commercial context. A more meaningful measure of success should consider and 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 indulgence. They help you gather information, decide on corrective action, and, most importantly, 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 your investment return.
Covering EBM is out of this article's scope, I would recommend going through the below link for more Information on EBM, https://www.scrum.org/resources/evidence-based-management-guide.
Source of References
www.benmorris.com
www.hbr.org