Over a million developers have joined DZone.
{{announcement.body}}
{{announcement.title}}

Velocity Anti-Patterns – Demand for Higher Velocity

DZone's Guide to

Velocity Anti-Patterns – Demand for Higher Velocity

If your supervisor has just told your dev team that they need to go faster, this might be just the article to explain why velocity isn't so changeable.

· Agile Zone ·
Free Resource

Discover how TDM Is Essential To Achieving Quality At Speed For Agile, DevOps, And Continuous Delivery. Brought to you in partnership with CA Technologies

This is far and away, the most common Velocity Anti-Pattern, and quite possibly the most harmful. It manifests itself in a number of different 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 as "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 on the same computer at the same time. Not everybody punches in at 8 am and out again at 6 pm. 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?

See how three solutions work together to help your teams have the tools they need to deliver quality software quickly. Brought to you in partnership with CA Technologies

Topics:
agile ,velocity ,scrum ,anti-pattern

Published at DZone with permission of

Opinions expressed by DZone contributors are their own.

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

{{ parent.tldr }}

{{ parent.urlSource.name }}