Velocity Anti-Patterns - Enticing More Velocity

DZone 's Guide to

Velocity Anti-Patterns - Enticing More Velocity

Velocity increases are one of indirect benefits of Agile, but what happens when managers ineffectively enforce velocity increases?

· Agile Zone ·
Free Resource

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.

Increase Awareness

The number one motivational technique is simply to increase awareness. We make the team acutely aware of the deadline, the desired scope, and how near or far they are to hitting the target. This is a simple and passive technique. The idea here is that if people know what is required, they will rise to the occasion.

Burn down charts and burn up charts are a common technique for showing the team how they are doing within an iteration or towards a release. No one can be accused of pressuring a team by simply making data available, right?

But no matter how seemingly benign, this approach invokes the Hawthorne Effect, which practically guarantees the measurement will improve, but does not guarantee the overall results will improve.

I am not saying that you should not use charts or make data available to the team. What I am saying is that you need to be aware that the team will tend toward behavior that "improves" the measurements by which they feel they are being evaluated.

More often than not, velocity will appear to increase. This is often the result of some increase in the average estimate of a story, resulting in higher velocity numbers but no measurable increase in value. The team begins to wonder if they're estimating correctly. Maybe that 3 is really a 5; we're not entirely positive how complex it is. Better to be safe than sorry. We don't want an artificially low velocity—you know, like we used to have.

Measurements should be data the team considers valuable and wishes to see rather than data that management wants for evaluation or demands for process consistency. If management is going to mandate certain measurements, educate the team on what the measurements are and how they serve the team and the organization. Finally, if management is going to mandate certain measurements, then make sure the mandated measurements are well-balanced.

Velocity Goals

So we've shown the team how they are doing. We gave them the burn charts and they still didn't go fast enough. What is a good Scrum Master to do? Well, help them with the math, of course.

"Hey, team. We can see that our burn chart is looking less than ideal. If we want to hit our deadline—and we do want to hit our deadline—it looks like we're going to need to increase our average velocity from 22 to 26 as soon as you can. Whaddya say? Can we count on you to work smarter, not harder?"

This, of course, isn't the only way targets are set. Some managers take a more dictatorial approach.

"Okay team. I didn't want to have to do this, but you people can't seem to figure it out on your own. So much for 'self-organizing'. Your velocity sucks. I've looked at your burn chart and you can't possibly make it. Effective immediately, velocity must increase to 26 points. I don't want to hear any whining. You've been lollygagging long enough. Now get back to work."

The language is different, but the intent is the same and the end result is likely the same. Velocity will very likely go up. And again, this does not mean the end result will improve.

In fact, what happens is that we've now invoked Goodhart's Law. In setting a target for a lagging indicator in an attempt to control the system, what has actually happened is we've changed the system, thereby changing what the indicator means. As a result, the measurement is no longer the same as the measurement we were using before and the target doesn't mean what the manager thinks it means.


Rewards for increased velocity fall into a category of their own. Here, we must have some level of awareness. After all, we can't assess an increase in velocity if we have no measure. And we additionally have a target. If we're offering a reward for an increase in velocity, there must be a target or even set of targets to which awards are tied. So we've invoked both Hawthorne Effect and Goodhart's Law.

As we know from prior discussion, this means both that the velocity will increase artificially (or temporarily) and that the velocity measurement will not mean what it once did. But it gets worse.

You see, in knowledge work, financial rewards actually impede performance. That's right. Financial incentives impede performance.

In 1971, Mark Lepper and colleagues at Stanford ran a study wherein they invited students to work on puzzles and games. After a period of time, they started to reward students for their performance. There was a pronounced improvement in performance among some of the students. Then, the rewards were taken away and the students who had shown improvement regressed to levels below their original capability. Some of them stopped participating altogether.

At first glance, one might conclude that the incentives improved individual performance and the problem was not their use, but the fact that they were discontinued. But this is not the case. You see, while some people's performance went up temporarily, the overall performance of the group sagged when incentives were introduced and only worsened when they were then retracted. Extrinsic reward structures for work people found intrinsically motivating made performance worse.

Numerous other studies, including those spearheaded by University of Rochester psychologists Edward Deci and Richard Ryan, have shown that rewards often undermine our intrinsic motivation to work on interesting, challenging tasks—especially when they are announced in advance or delivered in a controlling manner.

For those select few who actually display an increase in performance on cognitive tasks when offered extrinsic rewards, the reward levels tend to lose impact over time. Whatever incentives are offered eventually become the "new normal" and maintenance of existing performance levels will require increases in reward. This is not a sustainable model.

Velocity Shaming

While really just a variant on rewards, Velocity Shaming gets a special subsection all to itself as it reveals a more serious leadership shortcoming.

The term reward suggests some form of positive reinforcement. With velocity shaming, we forego the positive reinforcement and instead shame or cavil the team for failure to meet expectations. If the caviler is a seagull manager who swoops in occasionally and craps on the team, then shaming will occur perhaps a few times per quarter and will be about failing to average sufficient velocity. If, on the other hand, the caviler is a micro-manager, the shame-fest will probably occur several times within a single iteration for failure to track to a velocity goal.

The more they pay attention, the shorter the shame cycle. The shorter the shame cycle, the more harm done.

There is holding a team accountable, and there is just plain bad leadership. For most teams, the inability to move quickly is systemic. From cross-team dependencies and arduous process to insufficient support, staffing, and funding, teams are often burdened with herculean tasks that their leadership could make easier. Shaming a team for their inability to function to your liking in a system which you as management support through inaction is a special kind of awful.

If you are in charge of a team and you do this, and you know who you are. Stop it.

Stop it now.

agile, burn charts, goodharts law, hawthorne effect, velocity, velocity goals

Published at DZone with permission of Doc Norton , DZone MVB. See the original article here.

Opinions expressed by DZone contributors are their own.

{{ parent.title || parent.header.title}}

{{ parent.tldr }}

{{ parent.urlSource.name }}