How focus on Velocity inhibits Agility !!

If you/your team/organization is working in Agile ways of working for the business operations/product development then you would have definitely heard about term called “ Velocity” …

Defining Velocity

Let’s define what is “Velocity” in a layman term and what world (outside Agile) understands from the word -

As per Physics (Kinematics theory), Velocity is a physical vector quantity to define where we need both magnitude and direction i.e. how fast and which direction.

As per Wiki aka Wikipedia -

Velocity is a measure of how fast something moves in a particular direction. This requires us to interpret the velocity as a physical vector quantity. To define it we need both magnitude and direction. For instance, if an object moves east at 9 metres per second (9m/s), we would say that its velocity is 9 m/s to the east.

To calculate the Velocity you always need to identify the Speed which is an absolute value ( magnitude) ; direction the object moves in a given time-frame. Depending on the frame of reference or time-frame the velocity can be defined with mathematical concepts for making the correct analysis. If you are not concerned on direction of your movement then only Speed is enough (unidirectional).

Velocity Determination

To calculate the average velocity of an object, we divide its displacement (its change of position) by the time it took to change position.

Now let’s define “Velocity “ in “Agile” world so that we have a shared understanding of what the community and thought leaders have to say.

The various glorious inconceivable Agile definitions on Velocity :

The team’s velocity for an iteration is equal to the sum of the size of all the stories completed in an iteration — Dean Leffingwell’s, Scaled Agile, Inc., the SAFe.

Velocity is a capacity planning tool sometimes used in agile software development. Velocity tracking is the act of measuring said velocity. The velocity is calculated by counting the number of units of work completed in a certain interval, the length of which is determined at the start of the project. [1] -wikipedia.com

Velocity is an extremely simple, powerful method for accurately measuring the rate at which scrum development teams consistently deliver business value. — VersionOne

At the end of each iteration, the team adds up effort estimates associated with user stories that were completed during that iteration. This total is called velocity. — Agile Alliance

1) Velocity measures how much functionality a team delivers in a sprint.

2) Velocity measures a team’s ability to turns ideas into new functionality in a sprint.

- Mike Cohn, Mountain Goat Software

The project velocity (or just velocity) is a measure of how much work is getting done on your project. To measure the project velocity you simply add up the estimates of the user stories that were finished during the iteration. It’s just that simple. You also total up the estimates for the tasks finished during the iteration. Both of these measurements are used for iteration planning. — Extreme Programming.org — Don Wells / Kent Beck

Velocity is the ratio between an ideal-time estimate and the actual time that it takes to do something. It is a measure of estimation accuracy, not of output or work. In fact, treating velocity as an output indicator is actively destructive. It leads to initiatives to “improve the team velocity,” which may typically lead to dysfunctions.

There is an interpretation in many orgs that Velocity is the measure of Team’s productivity !! Do you think Velocity is the measure of Productivity ? Let’s explore…

What is productivity?

As defined (n): the state or quality of being productive

- the effectiveness of productive effort, especially in industry, as measured in terms of the rate of output per unit of input.

Velocity is not a measure of Productivity

The problem with this approach is that velocity is a planning/forecasting 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 significantly between teams. There’s no credible means of translating it into a normalized figure that can be used for meaningful comparison.

You get what you measure

Given that velocity is such an arbitrary measure it is easy to game. 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. Worse still, they may start cutting corners to deliver things with fewer story points. This can lead to a build-up of technical debt that will undermine future productivity.

You see similar behavior 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 can 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.

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.

Velocity — Good or Bad ?

Velocity is neither good nor bad as long as it remains specific and made private to the team and is never utilized for any purpose outside of the team. The unit to measure it and the decision to measure it or not should be left to the Scrum team, which is self-organizing and can make their own decisions.

Let’s understand with some examples on how a powerful Velocity metric can turn from Good, to Bad, to Ugly.

The Good: Along with other inputs like team capacity, prior commitments, Velocity helps Development Team decide how many Product Backlog Items they may forecast for current Sprint. Velocity also helps Product Owner to gauge how quickly a team may work through the backlog, because the report tracks the forecast and completed work over several iterations. The Product Owner may revise the forecasted delivery timelines based on the variations in velocity of the Development Team.

Velocity is absolutely awesome and GOOD metric when it is used by ONE AND ONLY the Scrum team themselves to understand their progress, their strengths and how they can improve Sprint over Sprint to become better. Leveraging Velocity for any other purpose by people outside the Scrum Team may quickly result in this metric being abused and making it BAD.

The Bad: I have had instances where leaders have asked me questions like, “If two teams have similar skillsets, shouldn’t their velocities be similar?”, “Team A’s Velocity is 2 times that of Team B’s — shouldn’t Team A work on the remaining Product Backlog Items for faster delivery?” This prompts me to explain to them that each team would use their internal consensus to estimate the size of tasks at hand. Such sizing of efforts may differ from team-to-team due to differences in the reference points for these two teams. Size of task ‘X’ for Team A may be larger than its size for Team B, because former may be used to slicing efforts to smaller sizes and thus resulting in ‘larger’ estimates. This may make Team A’s velocity appear higher than Team B’s velocity.

Leveraging velocities for such comparisons will not yield any benefits. In fact, such comparisons make teams very uncomfortable, as they quickly understand that leaders are using this metric to measure the collective team and possibly their individual productivity.

The Ugly: When Leadership decides to use improvement in Velocity as a measure to gauge Development Teams’ performance and teams become aware about it, things become ugly. Now Development Teams will start fudging the sizes of their PBI’s / tasks to ‘bloat’ their velocity, just to ensure they appear to meet (may be even beat) their target velocity. At this point transparency will cease to exist in the team ensuring mechanical Scrum implementation resulting in sub-optimal metrics and delivery.

Metrics are not a bad thing, but the wrong ones are

Metrics are not just a management indulgence. They help you to identify problems, decide on corrective action or figure out how to evolve in the future. However, it is difficult to arrive at a productivity measure that can be reasonably applied across the board for software development. By satisfying the on-going management hunger for reports and dashboards you risk creating meaningless overhead and distorting development.

Conclusion:

Velocity is an output and not outcome. Velocity is a good metric for Scrum Teams to leverage for its internal purpose with the idea of continuous improvement. The moment this metric is used for any other purpose, the teams and organization will lose the benefits that Scrum has to offer. There is no good or bad velocity !!

Below are the key takeaways from Velocity measurement/calculation

• Velocity does not show whether clients’ problems are being resolved, nor whether value is being delivered, as reflects volume of output.
• Velocity only shows how much team is occupied in a given sprint/time-frame.
• Focusing on velocity inhibits organizational agility.
• Do not focus on the value that is actually delivered to the market.

In a complex environment nothing replaces empiricism. When there are more unknowns than knowns; we do not know what would happen. Inspection and Adaptation with Transparency at the last possible moment is the approach to go with.

In my experience Velocity has been weaponized against agility and adaptability. It appears when the creation of value is less important than the ability to measure output. In iterative agile development a feature is done when the customer says it is done, not when the developer says it is done..

Please note — Metrics are not a bad thing, but the wrong ones are … So don’t forget the fact You get what you measure , stop thinking about ‘Output’ think about ‘Outcomes’ that assist your business !!

References -

Source:

• https://www.scrum.org/Resources/Scrum-Glossary
• Wikipedia
• Google Images & Sources

Originally published at https://www.linkedin.com.