This is far and away, the most common Velocity Anti-Pattern, and quite possibly the most harmful. It manifests itself in a number of differing fashions, but the basics are the same: Somebody determines that the team needs to get more done in less time. So they send out the message - “We are going to need more velocities.” This person is usually an authority figure and typically doesn’t do the actual work being asked of the team. And they clearly don’t know what velocity is. More velocities? Aw C’mon, really?

Why we need “more velocities”

In some cases, the need for higher velocity is based on a set scope for a set date and some basic math with significantly flawed assumptions. Take the total work to be done and divide it by the team’s average velocity. If the number of weeks to complete the work exceed the number of weeks between now and the deadline, then the team needs to get more done in less time. All of this typically under-represents the volatility of the velocity, fails to take into account systemic issues, is based on estimates made with very little information, and assumes a known and locked scope.

In other cases, a potential for higher velocity is observed, which then creates a demand for higher velocity. These observations are steeped in a lack of true understanding of creative work and an adherence to a Tayloristic output-centric management style. The team can be seen “loafing”. There are times where nobody is actively writing code. There are times where more than one individual is working on the same basic piece of work at a given time. Sometimes, we can even see two or more people working at the same computer at the same time. Not everybody punches in at 8am and out again at 6pm. Some people don’t eat lunch at their desks. And who knows what people are actually doing when they “work from home?” This team can clearly move faster - we just need to give them a little push.

And in yet other cases, the need for higher velocity is borne of expectation. Everybody knows that when a team goes agile, they get faster. It’s a fact. It has been written in numerous agile books, especially books on scrum. I mean, I just wrote it here. So it must be true. And if it is true that teams get faster, all we need to do is help them get there.

These are but a few of any number of reasons why we might expect or “need” the team to move faster. This thinking is, unsurprisingly, flawed. Velocity is not about measuring the team. It is about having a course-grain forecast. Rather than a tool to rate and push a team, it is a tool to help make key business decisions. Which features can we cut back on? What is truly priority? How else might we organize the work, support the team, or think about the product?

Unfortunately, these are hard decisions. They may force us to make tradeoffs. They may result in our having to change our public message; to move a date or to reset market expectations. It is far easier to defer the hard decision and ask a team to “step up”. It is easier to abdicate the responsibility and push it to the team.

In most cases where the need for an increase in velocity is articulated, there is an underlying unspoken premise. The belief that if properly motivated, we can do better. Re-phrased, the belief that we are not already operating at our best.

Given we need to hit a deadline with a set scope
When the team is not moving fast enough to hit the deadline
Then the team is capable of moving faster

This is logically flawed. The conclusion is baseless and is in no way supported by the precedents. Just because we want a team to move faster does not mean that they can. And quite often, pushing a team to go faster ultimately slows them down.

Attempts to entice more velocities

Leaders (and teams) attempt to achieve velocity increases in numerous ways. Most, as you can imagine, have unintended side effects on the teams and none significantly improve the actual flow/delivery of value to their customers. Here we explore a few ways teams might be encouraged to increase their velocity. Unfortunately, no matter how well intentioned, using such techniques still has a negative impact.

This content and much more on velocity and agile metrics is available in my book, "Escape Velocity"