An argument against why all teams should have the same velocity score.

In agile teams use velocity scores to understand their current rate of change.

Velocity: The velocity of an object is the rate of change of its position with respect to a frame of reference and is a function of time.

https://en.wikipedia.org/wiki/Velocity

To achieve the same velocity across all teams, one would first have to define a standard frame of reference. A frame of reference for a team of software professionals could be the combination of, and not limited to

• Their manager.
• The applications they are maintaining.
• Their programming style.
• The tools to which the team has access.
• The participant's general ability to communicate effectively internally and externally.
• The customer, the team, is serving.

Realistically the only way velocity scores could tell the truth about groups of engineering teams would be if everything about the environment is identical. For instance, each team would need to have the same amount of and understanding of technical debt, make the same design decisions, and have the same relationships with the business team. Their managers would need to think the same way about engineering practices, adopt the same tooling, and each engineering team would require the same mix of professionals.

Why working towards an average velocity is a bad idea

Individual point-scoring deteriorates accountability between the team's members

When team members are being measured by how many points they are earning during a sprint, they lose the motivation to collaborate. Engineering practices like paired programming become impossible when each individual is required to contribute to a point quota. Conversations within the team might look like this:

Why would I spend time helping you close your four-point ticket when I am already behind by two points for the current sprint?

How about I help you once I finished my work since I am trying to get promoted this year?

I have not closed as many points on my own this increment because I have been onboarding new team members

Shifting focus to an arbitrary point system like velocity changes the conversation of progress from being based on the customer's benefit to the individuals participating in doing the work.

The team will size based on points earned instead of the effort necessary to complete an objective

Being points-driven encourages sandbagging of complexity scores. Updating the doc-site is now four points of effort. Removing a comment from the code base is now two points of effort. No one wants to fix bugs unless they have some point value associated with them (traditionally, we avoid pointing bugs, but that is another topic altogether). Every conversation with an engineer on a team will require a ticket with points because velocity points have become a currency between individuals. Having our people acting in this way puts value in the wrong places. Instead of getting a new feature in front of the customer, we spent two weeks removing code comments or writing docs very few people will read.

People may avoid complex problems

Teams focused on velocity points are adverse to taking on ambiguous work. The problem with people avoiding complex problems is two-thirds of software engineering is discovering complexity and problem-solving. People will only want to show that they are earning points in a linear or additive way, where doing research does not always allow for that to be clear, and someone doing something new for the first time might see that as taking too much risk. Engineers will unknowingly make what used to be normal tasks seem more tasking than they should be, solely to keep their points average in check. The conversations between product and tech deteriorate because the product team is told that everything is too difficult, slowing product development, taking fewer risks in the process, and stifling the potential for innovation.

We want to encourage our engineers to try on more complex problems in a safe to fail way. Engineers taking on new challenges will improve their ability to solve problems and gain experience that benefits the company their products and their team.

Why leaders might be motivated to work towards an average velocity

It is a naive discussion point from leaders to work towards an average velocity. Leaders who focus in this way lack trust and wish that velocity could tell them how effective their organization is. However, what tends to happen is teams slow down, become fearful, and lose accountability to each other, and, worse, they lose sight of their customer.

If we look back at the Agile Manifesto we can understand again why an average team velocity is a worrisome concept:

"Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done."

Manifesto for Agile Software Development

Companies that have managed to average their velocity score have only succeeded in moving the attention away from building software to scoring arbitrary points. People are no longer motivated to produce software but to complete "tickets." People are not encouraged to become accountable to each other since they are only accountable for scoring velocity points.

Monitor velocity within the context of the team, not the organization

Velocity scores help teams understand how much effort they are completing. Velocity Points are a part of the team's feedback loop, allowing them to hold themselves accountable for their general productivity. Low-velocity scores could be a signal of an issue; however, leaders should first ask questions about those teams and seek out experiments that could help them along.