The most popular metric for agile software development teams, by quite a margin, seems to be velocity. Yet, experienced agilists don’t find velocity particularly useful. Even some of the authors of the Agile Manifesto who played a part in defining velocity, as well as story points and planning poker, have moved on. But today, as large organizations undertake major initiatives to “transform” into agile organizations, there is a strong emphasis on velocity as a key metric.
Despite the advice of leading agile consultants and coaches, and books like Doc Norton’s Escape Velocity and my own Software Development Metrics, corporate leaders stress the importance of velocity in their transformation programs, and require their software development teams to track and report it.
There is no mention of velocity in the Agile Manifesto. The Scrum Guide doesn’t mention it. Neither does Large Scale Scrum. The Scaled Agile Framework (SAFe) mentions velocity in the context of iteration planning as one way to establish a team’s delivery capacity; but does not suggest setting a target for velocity or using it to judge or assess teams. This is consistent with the original intent of velocity as an empirical observation of a team’s performance, and not a target.
Velocity’s popularity
What accounts for the popularity of velocity in large enterprises, as those organizations attempt to improve their business agility, especially in the face of advice to the contrary by those who are most knowledgeable about “agile?”
I suggest it comes back to the old diffusion of innovation curve (also known as the innovation adoption curve) proposed by Everett Rogers in his 1962 book, Diffusion of Innovations, which is still in print and now in its 5th edition (2003). Here’s one representation of the curve, from ValueBasedManagement.net:
The people who came up with the Agile Manifesto can be seen as innovators, per Rogers’ model. The corporate leaders of the year 2021 are in the laggard group, described on the linked site as “traditional people, caring for the ‘old ways'” and “critical towards new ideas,” who will only accept a new idea after it “has become mainstream or even tradition.”
Indeed, today’s corporate leaders bend the ideas of agility until they mesh neatly with 20th-century management assumptions and practices. Velocity as used in large organizations is quite different from velocity as originally intended.
What is velocity, anyway?
A quick-and-dirty definition of velocity may be the amount of work a team delivers in the space of a single iteration, when they are using a time-boxed iterative process.
There may be a few nits to pick in that definition, but I think it’s close enough for jazz. Velocity depends on a time-boxed iterative process model. So, what’s that, then? It’s an iterative process (as opposed to a linear one, or “waterfall”) that has two salient characteristics: (1) the iterations are all the same length, and (2) the team delivers something in each iteration (at least).
What’s the length? What’s “something?” What does “deliver” mean, exactly? Those definitions may vary from team to team, but in general velocity is an observation of how much the team has delivered iteration by iteration – an observation, not a plan, not a target, and especially not a whip to try and force the team run faster without changing any of the constraints that determine their delivery rate.
So, what’s the problem?
The problem is that people use velocity to set targets and to carry out performance assessments of personnel. When velocity is used that way, it loses all meaning. People “game” the numbers to avoid punishment. Whatever value velocity might have offered is lost. Compounding the problem, many managers don’t understand the value has been lost, and they depend on the numbers reported to them to make consequential business decisions.
Is “stable” velocity a good thing?
One of the most common characteristics of traditional organizations is that they have no idea what their delivery capacity is. Their internal business “partners” dump work into the IT department as if it were a bottomless pit. No one can plan in a predictable way. So, one of the first orders of business in an agile transformation is to stabilize the current process. That’s an idea that will be familiar to Lean practitioners.
One indication of stability (and an enabler of predictability) is that a team’s delivery is steady. That is demonstrated when their velocity ceases to jump up and down from iteration to iteration.
That is a starting point for improvement rather than an end goal; but because of the way large organizations conceive of their “transformation” (a linear path through a maturity model of some sort, with a predefined end state), few organizations ever move beyond that point. Believing they now “know” agile, they release their coaches, leaving them with no guidance regarding next steps.
To be fair, stabilizing delivery performance is a significant step forward, and it’s only natural for people to feel as if they have accomplished a great deal by achieving predictability in planning. Often, many other problems either go away or become more clearly visible at this stage. It feels like victory! In reality, they may only have succeeded in positioning their running shoes in the starting blocks, but it still feels like victory. It certainly beats running barefoot across rocky ground, as they had been doing before.
But because they apply industrial-era thinking to their agile initiatives, most large organizations achieve mixed results. So they try again.
And again.
The industry remains in a perpetual state of just beginning to use an agile approach. It’s rare for any organization of appreciable size to progress beyond the introductory level with these methods, even after multiple transformation intiatives spanning a decade or longer, and spending tens or hundreds of millions of dollars. The emphasis on velocity as a key metric surely ranks as one of the primary causes of this situation.
Terminal velocity
So, we could say that once a team has stabilized its delivery performance, that’s as good as their velocity will ever get. It’s their terminal (final) velocity.
The question then becomes: How can we have fun with it?
The Glenn Research Center of the National Aeronautics and Space Administration (NASA) has a graphic showing how to calculate the terminal velocity of an object falling to earth from on high. It looks like this.
If we correlate the variables with characteristics of a software team and its organization, fun will ensue.
A falling object accelerates until it reaches its terminal velocity. That’s the point where drag and weight are the same. The frontal area of the object plays a part in determining terminal velocity; a more-streamlined object falls more easily through the air. The air is a gaseous medium that is thinner at higher altitudes, so the calculation considers gas density.
What’s the terminal velocity of a software delivery team? Let’s say:
- W (weight) is the team’s work-in-process (WIP).
- D (drag) is the net effect of organizational constraints on the team’s work, such as (a) the use of outmoded practices such as stack ranking of employees; (b) cross-team dependencies created by management’s focus on resource utilization rather than throughput; (c) access to necessary resources (I mean resources, not humans), such as test environments, databases, test data, development tools, and the like; (d) understanding how work flows through a system (queuing theory); and, last but not least, (e) the mandate to track velocity.
- ρ (gas density) represents the organization’s general level of understanding of agile, lean, systems thinking, software engineering principles, and “respect for humanity” in the Toyota sense.
- A (surface area) is the net effect of the team’s intrinsic characteristics, including (a) number of team members, (b) extent of cross-skilling among team members, (c) level of collaboration in the team’s working methods, and (d) technical practices the team applies to the work.
Based on those correlations with physics, we can say the team reaches terminal velocity at the point that they can’t take on any more work. That velocity may be higher or lower depending on D, W, ρ, and A.
As a falling rocket descends, it passes through ever-denser atmosphere. As a software delivery team plummets inexorably toward the cold, hard ground, and management applies more and more 20th-century-style pressure to deliver, the value of ρ increases; poor understanding of the relevant principles creates increasing friction.
The additional friction heats up the team. It may become so hot that key team members have no choice but to eject. Their exit from the team increases the surface area, A, which reduces their velocity.
Woulda, coulda, shoulda
Leadership could respond to the problem differently, of course. They could restructure to reduce cross-team dependencies. They could emphasize team-level performance assessment over individual assessment. They could encourage a softening of boundaries between functional silos. They could work with stakeholders to reduce WIP and improve flow. They could load the teams according to queuing theory to avoid creating a logjam. They could ensure the organization has the necessary tooling and training to carry out the work more smoothly. They could invest in appropriate automation to reduce the time spent on repetitive and routine tasks, freeing up more time for value-add work. They could foster the kind of working environment that people want to be part of.
They could.
But if they did, what would we do for fun?