How are salary differences decided in agile companies?

Question

We are starting our agile path and now that our company is switching to a flatter structure, we need to decide how salaries will be determined. Before the switch we were using seniority, individual metrics, and bug count as performance indicators but all of that are anti agile. The thing is, salaries are not uniform in this company, but how can we justify those differences in a agile environment? how can we decide to give (or not) a rise to someone when he ask for it, without knowing his individual performance? I'm curious about how is this tackled in other companies.

Just to avoid being stoned I'm not in charge of any of that, I have been asked to help in the proposal of the new structure.

Answer 1

how can we decide to give (or not) a rise to someone when he ask for it, without knowing his individual performance?

In every company where I have ever worked, the individual's manager determined the raise based on a number of factors - place within a salary range, individual performance, market conditions, company conditions, budget, etc, etc.

None of them had anything to do with Agile/Not Agile.

You seem to imply that individual performance is measured solely by bug counts and "individual metrics". That's simply not the case where I have worked.

Answer 2

Agile has nothing to do with payment.

There is a reason why companies often have line management and separate project/team management.

Especially for developers, testers and such, making salary too dependent on "goals" is inviting gaming the system... a lot. I guarantee you, if you have anything like bug counts, code quality (as checked by an automated system) and so on, then you will find that those metrics do decrease/increase as wanted, but the overall effect will most likely not be what you like. People will always find ways to get the metrics just right, and by directly tying them to salary, you make this their prime motivation.

For more abstract jobs, like more architectural positions (which are super important if you don't happen to have a bunch of high level developers who can just wing this stuff), there is little to measure.

Also, many more human characteristics should rightfully lead to a higher salary. I.e., having some top notch employee who can not only program like the devil himself, but also is able to communicate greatly with other developers and customers; plus likes to give astounding presentations; plus has great architectural insights; plus blogs regularly in the name of the company... even if he is "just" another SCRUM team member, you actually do want to give him a very noticeable incentive to stick around. And just picking out some goals once a year will not be a great instrument to do so.

Such goals work great in the sales department, as those guys have one job - sell stuff. Very measurable in hard numbers. Not so much for developers.

So keep the management of your salaries as they presumably were before - in the hand of the direct manager, who is obviously allowed to take the behaviour of the person in the new Agile environment into account. But keep it human... i.e., maybe stay away from outright punishing people that take a bit more time to get used to the new ways (unless you want to get rid of them, obviously...); and at the same time don't go overboard increasing salaries left and right just because someone is taking this stuff up quickly. Going Agile is going to be in favour of your developers anyways, i.e., if you get a lean and mean machine going, their work life should have improved anyways... After some time, your managers will surely get a feeling for who are the ones that make the new company really tick.

Answer 3

Have managers set individual SMART goals for each team member and establish objective metrics to determine how well they meet or exceed these goals. As far as I know, there is nothing in agile that goes against individual metrics.

Answer 4

While it is true that a manager can still engage with and determine the raise for any individual in an Agile (or more particularly, Scrum) team, it does pose some problems depending on what your organization did before.

You mention individual metrics and bug count. In a highly-collaborative team (which frequently happens when a team successfully transitions to an approach like Scrum) the lines between individuals blurs. If one developer helps another solve a problem, who gets credit for that one? How do you know? In my experience (over a decade) working in and with these kinds of teams, one thing I've universally seen is that abstracted metrics no longer give the kind of insight they once did. For example, I see some teams try to track the number of backlog items complete, which no longer tells the story of what's really happening on the team. Bug count isn't necessarily bad, but it usually only tells a piece of the story.

Usually what needs to happen is that managers need to become more engaged. If a manager is around the team (as opposed to off in a separate office) and they are observers to the team's activities, they have a very clear idea of who is doing what.

Now, there are other movements like "Holocracy" or "Teal Organizations" which are often grouped together with Agile that do suggest big changes to raises and salary. These approaches may make small shifts to the paradigm like using team 360 reviews instead of manager reviews or large changes, like leaving salary entirely in the hands of the team. The book "Reinventing Organizations" by Frederic Leloux is a decent overview of some of these changes, but this kind of change is not necessarily required to adopt Agile.

Answer 5

In scrum, there are only 3 roles - product owner, scrum master and developer. The team is expected to be self organized. Incentives and Pay Hikes are left for HR and leadership to decide. They could apply some organization level eligibility criteria and set these as goals:

Example: Minimum # of months worked in a given year (If someone has been out for more than, say, 3 months in a year, then they will not be eligible)

For this to work, the grades and promotion criteria should be consistent. Example: Any new joiner can be 'Junior Developer'. They will be promoted to 'Developer' grade after 3 years if he/she has consistently met all eligibility criteria every year. After another 3 years, the grade can be 'Senior Developer' and so on.

In this setup, there is no appraisal on the 'work done' by individuals within sprints. There are only common criteria or goals which makes someone eligible or otherwise. The incentive % or pay hike % will also be common based on grade/experience plus company's performance and won't tie with rating of any kind.

There are certainly drawbacks in this setup as it could pave way for increased attrition as someone with a niche skill-set might expect higher incentive and quicker promotion. This could be worked around by having different titles: Developer - Database Architect, Developer - Automation Tester. Based on the market supply/demand, the company/HR could classify some as niche and tweak their criteria as needed and could also allow employees to move the ladder horizontally (Database Architect to Automation Tester) once they acquired the skill.

'Focus' is one of the 5 values in scrum which implies that no one works outside of their sprint goal. Hence, we cannot rate someone for 'extra' work they performed beyond their assigned duties. This is in sharp contrast with the traditional appraisal process.

In summary, the system should be in such a way that it doesn't break the concept of 'self organizing' team and also doesn't aid conflict between team members.

Here's what Jeff Sutherland(co-creator of scrum) says about employee review process:

There are a lot of reasons not to do performance appraisals. Google doesn't do them. Instead each person has a web page with picture, bio, and three month goals. Each person self-evaluates on the web page. It is well known that employee performance ratings in all organizations are inflated. This process is designed to produce realistic, provably accurate, ratings. Ratings tend to reflect how well the employee sucks up to the manager, rather than whether or not the employee generated a great product that led to lots of sales and happy customers. We have to get away from motivating employees to please the manager, and get them to please the customer.

http://jeffsutherland.com/scrum/2006/11/agile-performance-reviews.html