Pay raise linked to velocity?

Question

Is it a good idea to link a team's sprint velocity to bonuses or salary increases?

For example, if one increases the average sprint velocity by 10 percent at the end of a year?

Or are there other metrics that could be more useful?

Answer 1

Is it a good idea to link a team's sprint velocity to bonuses or salary increases?

No!

Velocity is a tool teams use to forecast things and plan future work based on how the team has done in the past, in similar conditions. It is not a performance target. It is not a management metric.

If you tie bonuses and salary increases to velocity, two things will happen:

1. The tool becomes useless; any forecasts and plans relying on it will drift away from what the team can potentially do. Because...
2. People start gaming the system. You will start with 100 story points per sprint and by the end of the year you will get 500 story points with no change in team performance or delivery.

And since a picture is worth a thousand words, I'll leave you with a Dilbert sketch on a similar note:

There are better approaches to measure developer and team productivity, and make pay raises or bonuses more meaningful when attached to those, but those have their challenges too, as it's hard to measure knowledge work from outside. There is a lot of information out there, and some work better than others depending on the context. Maybe you could start reading from these two links:

• Metric by which to hold developers accountable
• The ecstasy and agony of measuring productivity for Software Engineering & Development

Just remember that if it's easy to measure or really handy, it doesn't necessarily mean it's useful or meaningful.

Answer 2

There have been good answers already, but it is also worth mentioning that this approach would discourage any activity that wasn't measured by velocity.

A team might not include in their velocity things like training, knowledge sharing, helping other teams, answering questions from stakeholders, etc.

Answer 3

Why would you link pay to any measurable aspect of development work?

It seems to me that this starts from the assumption that some kind of incentive will deliver benefits to the firm in excess of the additional wages paid.

Nothing is likely to be further from the truth.

There's absolutely nothing about the productivity of development work that is measurable by any mechanical means.

And there is no evidence that paying developers by any measure of productivity, improves either the speed or quality of results. Ever. It's been tried so many times over so many decades.

A fundamental problem (but by no means the only one) is that developers are primarily engaged in work that is internal to their own minds, and the relationship between the occasion of that internal work and the effectiveness of any output is not amenable to any method of external measurement.

Effective developers are often self-motivated in the first place - motivated by a desire for some kind of craft proficiency. Most people with decent jobs have this motivation - it's not unique to developers.

How the criteria of that proficiency are conceived, and whether proficiency is attained, is a complicated expert judgment, and there may not always be agreement between any two experts, but there is no doubt that the judgments are constantly being made by the developer in order to direct their attention and activity in a way that promotes their effectiveness.

Mechanical measures of productivity never succeed in replicating the subtlety or constant adaptation of these judgments.

So what happens when you apply such measures and incentives, is you get a bifurcation into two types of developer.

One type adapts its behaviour in response to the incentive (including adapting towards gaming the measures), and ceases to be guided by any internal judgment (and perhaps even ceases to perform it). A considerable amount of brainpower that they should be applying to development, and usually would be, is then reallocated to this gaming.

The other type of developer maintains their internal judgment, but is either punished by the measures for actually doing their job effectively, or is at least constantly threatened by being punished by them. This distracts and demoralises to the point that either the developer leaves, or at least there is overwhelming resentment induced (and a major withdrawal of engagement and effort, in a way that cannot be measured).

In both cases, the business attempts to substitute their own crude measure of productivity for the subtle and dynamic judgments of the developers themselves, and in doing so either undermine one of the main skilled activities that developers are actually expected to perform, or provoke so much conflict over those judgements as to undermine motivation and divert attention from development.

I just wonder whether any reasonable argument will alter the course of those who are determined to measure the unmeasurable and find metrics where none exist.

Answer 4

Velocity != Productivity

Velocity is not a measure of productivity. It's a proxy metric for team capacity used for forecasting and capacity planning. More generally, it's a useful tool for estimating whether a given amount of planned work on the Sprint Backlog can be reasonably expected to be completed within a single Sprint.

"The Goal of a Sprint is to Complete the Sprint Goal"

CodeGnome's Scrum Tautology℠ says:

Always remember that the goal of a Sprint isn't to complete lots of backlog items. The goal of a Sprint is to deliver the Sprint Goal.

Trying to use velocity to measure productivity or efficiency is an anti-pattern. If and only if a mature team is doing their own Sprint Backlog selection and planning, then a variation of the Pareto Principle is more useful. For example, if the Scrum Team is meeting its Sprint Goals more often than not (e.g. 80% of the time) then you can measure the Scrum Team's ability to deliver effectively based on that. However, many other factors impact the ability of a team to deliver, so that wouldn't necessarily be a direct metric either.

What's a Raise Intended to Accomplish?

A raise is basically a way of rewarding individuals for performance and reducing organizational turn-over. Scrum is team-based, meaning the whole team either succeeds or fails together—no bike-shedding on whether "failure" is an agile concept or not, or whether it's all just "validated learning," please.

It you want to reward the whole team based on their ability to deliver, and assuming that this is in fact a fair representation of the team rather than a butterfly effect of the overall process, you could certainly tie raises for all the team members to their effectiveness.

On the other hand, if you want to reward individuals differently, you now have two problems:

1. You are actively working against the notion of collective ownership and commitment that is at the heart of Scrum and other agile frameworks.
2. You need a non-proxy metric that is based on individual merit rather than team merit, but will therefore be biased towards some types of team contributors more than others.

Collaborative activities are inherently harder to measure. Doing pair programming, automation, or user story decomposition are all team-supporting activities. Will those performing essential support roles be rewarded for their contributions too, or will financial rewards only accrue to those whose contributions are most visible outside the team, e.g. writing the most lines of code or shepherding the most index cards across the kanban board?

To use an American football metaphor, glorifying only the people who score the most touchdowns de-legitimizes the contributions of all the other people on the team who made their accomplishments possible. What about the people who opened the way to the goal line with strategic blocks? What about the quarterback who made a series of unexpected but strategically optimal passes? What about the person who pretended to have the ball, ending up under a thousand pounds of opposing players so that the "hero" could run the whole length of the field unopposed?

When you think in terms of whole-team collaboration, it should be evident that treating raises as "prize money" turns individual team members into winners and losers. This changes the whole incentive structure from one that promotes team-based accomplishments into one that promotes individual gain. That will inevitably damage the esprit de corps that makes agile, whole-team approaches effective in the first place.

In short, you're trying to map metrics of individual merit onto a framework that is optimized for team cohesion and collaboration. Don't do that!

Fix the Company Culture

A raise is a financial reward. Rather than rewarding individuals, reward the team. You don't even have to wait until some annual review to do that. As some examples to consider:

1. If a team delivers a working product ahead of schedule, they've saved the company some amount of money. Why not provide a prorated share of those savings equally among the members of the team?
2. If your costs go down because the whole team has improved product quality or takt time, then why not reward the team with a prorated share of the cost savings?
3. If you sell more units because of the team hitting their forecasts more often or being more adaptive to changes in the market, why not create a profit-sharing plan?
4. (Not recommended, but...) Scrum Teams are supposed to be self-managing. If there's money to be distributed as a reward, let the team figure out what they consider a fair way to distribute that reward. They are in the best position to know who has contributed the most to the team's success, after all. Let the team decide who should get what share of the bonus money.

In short, the notion of individual meritocracy is not itself antithetical to agility. However, the notion that you can measure individual contributions within a collaborative process is problematic at best.

You can't fix this on your own. It's an organizational and organizational culture problem, and must be fixed at the organizational level. The team can and should work with the organization to find a better process. Give them a seat at the table with the parts of the organization involved in this process, and give them the opportunity to work out a fair—"fair" being whatever seems fair to both the company and the entire Scrum Team—solution to what is not at all a simple problem. Scrum is based on empiricism, so be willing to experiment until you find out empirically what works best for this team in this company!

Summary

If you can, discard the notion of individual pay raises in favor of whole-team rewards. Otherwise, the organization must revisit how it defines merit and what they are actually trying to incentivize, and align their financial reward system based on that.

In most cases, raises are retention tools rather than rewards. Create ongoing incentives rather than annualized ones, empower your teams, and make the team a great place for people to work, learn, and grow. Money certainly matters, but it isn't the only retention tool you have. Make sure that the organizational goal (retention) is aligned with the team members' individual goals and you'll end up with a better retention tool than if you try to create an individual hierarchy of meritocracy within a flat ensemble group.

Please do not do that. You will only undermine the framework, the incentives to collaborate, and the sense of collective ownership and commitment that is at the heart of any effective framework that fosters agility.

Answer 5

You've had some good answers and I agree with them. More sensible would be to find another measure of real value delivered by the team, for example OKRs based on deliverables or satisfaction surveys of users or stakeholders.

Answer 6

I agree with Bogdan's answer. The only caveat to that is whether the velocity metric is tied to a performance fee in the contract, whereby if the contract is awarded an extra fee for great performance, I would share that fee across the team by way of a bonus. That is not unlike normal profit-sharing bonus programs.