Mixing
How are salary differences decided in agile companies?
Clash Royale CLAN TAG#URR8PPP
.everyoneloves__top-leaderboard:empty,.everyoneloves__mid-leaderboard:empty margin-bottom:0;
up vote
4
down vote
favorite
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.
salary scrum
asked Aug 22 at 15:01
Ed_
2615
add a comment |Â
up vote
4
down vote
favorite
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.
salary scrum
asked Aug 22 at 15:01
Ed_
2615
10
What's preventing you from continuing to track individual performance?
– Snow♦
Aug 22 at 15:07
4
Compulsory link: joelonsoftware.com/2000/04/03/incentive-pay-considered-harmful
– DJClayworth
Aug 22 at 18:35
@Snow The fact that common agile methodologies like Scrum actively discourage singling out individuals and all but mandate dealing solely with a team as a whole.
– ivan_pozdeev
Aug 22 at 22:58
@DJClayworth the pay can't be a good incentive but it still has to be comfortable. See en.wikipedia.org/wiki/Two-factor_theory .
– ivan_pozdeev
Aug 22 at 23:00
add a comment |Â
up vote
4
down vote
favorite
up vote
4
down vote
favorite
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.
salary scrum
asked Aug 22 at 15:01
Ed_
2615
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.
salary scrum
asked Aug 22 at 15:01
Ed_
2615
edited Aug 22 at 16:56
asked Aug 22 at 15:01
Ed_
2615
asked Aug 22 at 15:01
Ed_
2615
asked Aug 22 at 15:01
Ed_
2615
2615
10
What's preventing you from continuing to track individual performance?
– Snow♦
Aug 22 at 15:07
4
Compulsory link: joelonsoftware.com/2000/04/03/incentive-pay-considered-harmful
– DJClayworth
Aug 22 at 18:35
@Snow The fact that common agile methodologies like Scrum actively discourage singling out individuals and all but mandate dealing solely with a team as a whole.
– ivan_pozdeev
Aug 22 at 22:58
@DJClayworth the pay can't be a good incentive but it still has to be comfortable. See en.wikipedia.org/wiki/Two-factor_theory .
– ivan_pozdeev
Aug 22 at 23:00
add a comment |Â
10
What's preventing you from continuing to track individual performance?
– Snow♦
Aug 22 at 15:07
4
Compulsory link: joelonsoftware.com/2000/04/03/incentive-pay-considered-harmful
– DJClayworth
Aug 22 at 18:35
@Snow The fact that common agile methodologies like Scrum actively discourage singling out individuals and all but mandate dealing solely with a team as a whole.
– ivan_pozdeev
Aug 22 at 22:58
@DJClayworth the pay can't be a good incentive but it still has to be comfortable. See en.wikipedia.org/wiki/Two-factor_theory .
– ivan_pozdeev
Aug 22 at 23:00
10
10
What's preventing you from continuing to track individual performance?
– Snow♦
Aug 22 at 15:07
What's preventing you from continuing to track individual performance?
– Snow♦
Aug 22 at 15:07
4
4
Compulsory link: joelonsoftware.com/2000/04/03/incentive-pay-considered-harmful
– DJClayworth
Aug 22 at 18:35
Compulsory link: joelonsoftware.com/2000/04/03/incentive-pay-considered-harmful
– DJClayworth
Aug 22 at 18:35
@Snow The fact that common agile methodologies like Scrum actively discourage singling out individuals and all but mandate dealing solely with a team as a whole.
– ivan_pozdeev
Aug 22 at 22:58
@Snow The fact that common agile methodologies like Scrum actively discourage singling out individuals and all but mandate dealing solely with a team as a whole.
– ivan_pozdeev
Aug 22 at 22:58
@DJClayworth the pay can't be a good incentive but it still has to be comfortable. See en.wikipedia.org/wiki/Two-factor_theory .
– ivan_pozdeev
Aug 22 at 23:00
@DJClayworth the pay can't be a good incentive but it still has to be comfortable. See en.wikipedia.org/wiki/Two-factor_theory .
– ivan_pozdeev
Aug 22 at 23:00
add a comment |Â
5 Answers
5
active
oldest
votes
up vote
30
down vote
accepted
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.
answered Aug 22 at 15:12
Joe Strazzere
225k107662932
8
I agree with this. Metrics are used, but they are different metrics. At my last job my goals were things like how do I enable the team to work better, how good am I am mentoring, metrics that show how I as the individual make the we (the team) better. It is not about how that I as the senior write fewer bugs, but how do I as the senior on the team enable the rest of the team to write fewer bugs.
– Bill Leeper
Aug 22 at 15:31
1
"That's simply not the case where I have worked." this isn't the case where anyone works. Qualifying performance and ability based on number of bugs solved is the stupidest thing I've ever heard.
– Edmund Reed
Aug 23 at 1:25
@EdmundReed unfortunately, this IS actually the case in a lot of places where people works... though it SHOULDN'T be
– xDaizu
Aug 24 at 8:42
1
@xDaizu oh yes, unfortunately I do know that this is how some places operate. What I was trying to say was that it is never an actual measure of anyone's performance, skill and ability, even if places treat it as such.
– Edmund Reed
Aug 24 at 9:09
add a comment |Â
up vote
4
down vote
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.
answered Aug 22 at 20:36
AnoE
5,147725
Indeed, metrics are so game-able we have Goodhart's law, from 1975: "When a measure becomes a target, it ceases to be a good measure"
– mbrig
Aug 22 at 22:30
add a comment |Â
up vote
3
down vote
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.
answered Aug 22 at 16:36
AffableAmbler
3,8482921
1
Individual metrics seem to be controversial—at least to team foundation users—visualstudio.uservoice.com/forums/…
– Nathan Goings
Aug 22 at 20:20
3
In some fields, there are no good SMART goals.
– David Thornley
Aug 22 at 21:15
1
@DavidThornley I find that extremely hard to believe. A goal like "have more technical knowledge in X field by the end of the year" works pretty much everywhere (exactly how you measure that varies more, but worst case a manger/team leader should be able to provide feedback)
– mbrig
Aug 22 at 22:28
@JoeStrazzere What about “demonstrate competency in technology x by completing objective y?â€Â
– AffableAmbler
Aug 23 at 15:27
I’m not a huge fan of performance reviews but where it’s not possible to give equal raises across the board, it’s helpful to have the rules of the game spelled out as clearly as possible, especially for those who may be new to the team.
– AffableAmbler
Aug 23 at 15:32
add a comment |Â
up vote
2
down vote
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.
answered Aug 22 at 15:49
Daniel
92126
add a comment |Â
up vote
-1
down vote
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
answered Aug 23 at 12:41
Ramnath
18429
add a comment |Â
StackExchange.ready(function ()
$("#show-editor-button input, #show-editor-button button").click(function ()
var showEditor = function()
$("#show-editor-button").hide();
$("#post-form").removeClass("dno");
StackExchange.editor.finallyInit();
;
var useFancy = $(this).data('confirm-use-fancy');
if(useFancy == 'True')
var popupTitle = $(this).data('confirm-fancy-title');
var popupBody = $(this).data('confirm-fancy-body');
var popupAccept = $(this).data('confirm-fancy-accept-button');
$(this).loadPopup(
url: '/post/self-answer-popup',
loaded: function(popup)
var pTitle = $(popup).find('h2');
var pBody = $(popup).find('.popup-body');
var pSubmit = $(popup).find('.popup-submit');
pTitle.text(popupTitle);
pBody.html(popupBody);
pSubmit.val(popupAccept).click(showEditor);
)
else
var confirmText = $(this).data('confirm-text');
if (confirmText ? confirm(confirmText) : true)
showEditor();
);
);
5 Answers
5
active
oldest
votes
5 Answers
5
active
oldest
votes
active
oldest
votes
active
oldest
votes
up vote
30
down vote
accepted
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.
answered Aug 22 at 15:12
Joe Strazzere
225k107662932
8
I agree with this. Metrics are used, but they are different metrics. At my last job my goals were things like how do I enable the team to work better, how good am I am mentoring, metrics that show how I as the individual make the we (the team) better. It is not about how that I as the senior write fewer bugs, but how do I as the senior on the team enable the rest of the team to write fewer bugs.
– Bill Leeper
Aug 22 at 15:31
1
"That's simply not the case where I have worked." this isn't the case where anyone works. Qualifying performance and ability based on number of bugs solved is the stupidest thing I've ever heard.
– Edmund Reed
Aug 23 at 1:25
@EdmundReed unfortunately, this IS actually the case in a lot of places where people works... though it SHOULDN'T be
– xDaizu
Aug 24 at 8:42
1
@xDaizu oh yes, unfortunately I do know that this is how some places operate. What I was trying to say was that it is never an actual measure of anyone's performance, skill and ability, even if places treat it as such.
– Edmund Reed
Aug 24 at 9:09
add a comment |Â
up vote
30
down vote
accepted
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.
answered Aug 22 at 15:12
Joe Strazzere
225k107662932
8
I agree with this. Metrics are used, but they are different metrics. At my last job my goals were things like how do I enable the team to work better, how good am I am mentoring, metrics that show how I as the individual make the we (the team) better. It is not about how that I as the senior write fewer bugs, but how do I as the senior on the team enable the rest of the team to write fewer bugs.
– Bill Leeper
Aug 22 at 15:31
1
"That's simply not the case where I have worked." this isn't the case where anyone works. Qualifying performance and ability based on number of bugs solved is the stupidest thing I've ever heard.
– Edmund Reed
Aug 23 at 1:25
@EdmundReed unfortunately, this IS actually the case in a lot of places where people works... though it SHOULDN'T be
– xDaizu
Aug 24 at 8:42
1
@xDaizu oh yes, unfortunately I do know that this is how some places operate. What I was trying to say was that it is never an actual measure of anyone's performance, skill and ability, even if places treat it as such.
– Edmund Reed
Aug 24 at 9:09
add a comment |Â
up vote
30
down vote
accepted
up vote
30
down vote
accepted
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.
answered Aug 22 at 15:12
Joe Strazzere
225k107662932
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.
answered Aug 22 at 15:12
Joe Strazzere
225k107662932
answered Aug 22 at 15:12
Joe Strazzere
225k107662932
answered Aug 22 at 15:12
Joe Strazzere
225k107662932
answered Aug 22 at 15:12
Joe Strazzere
225k107662932
225k107662932
8
I agree with this. Metrics are used, but they are different metrics. At my last job my goals were things like how do I enable the team to work better, how good am I am mentoring, metrics that show how I as the individual make the we (the team) better. It is not about how that I as the senior write fewer bugs, but how do I as the senior on the team enable the rest of the team to write fewer bugs.
– Bill Leeper
Aug 22 at 15:31
1
"That's simply not the case where I have worked." this isn't the case where anyone works. Qualifying performance and ability based on number of bugs solved is the stupidest thing I've ever heard.
– Edmund Reed
Aug 23 at 1:25
@EdmundReed unfortunately, this IS actually the case in a lot of places where people works... though it SHOULDN'T be
– xDaizu
Aug 24 at 8:42
1
@xDaizu oh yes, unfortunately I do know that this is how some places operate. What I was trying to say was that it is never an actual measure of anyone's performance, skill and ability, even if places treat it as such.
– Edmund Reed
Aug 24 at 9:09
add a comment |Â
8
I agree with this. Metrics are used, but they are different metrics. At my last job my goals were things like how do I enable the team to work better, how good am I am mentoring, metrics that show how I as the individual make the we (the team) better. It is not about how that I as the senior write fewer bugs, but how do I as the senior on the team enable the rest of the team to write fewer bugs.
– Bill Leeper
Aug 22 at 15:31
1
"That's simply not the case where I have worked." this isn't the case where anyone works. Qualifying performance and ability based on number of bugs solved is the stupidest thing I've ever heard.
– Edmund Reed
Aug 23 at 1:25
@EdmundReed unfortunately, this IS actually the case in a lot of places where people works... though it SHOULDN'T be
– xDaizu
Aug 24 at 8:42
1
@xDaizu oh yes, unfortunately I do know that this is how some places operate. What I was trying to say was that it is never an actual measure of anyone's performance, skill and ability, even if places treat it as such.
– Edmund Reed
Aug 24 at 9:09
8
8
I agree with this. Metrics are used, but they are different metrics. At my last job my goals were things like how do I enable the team to work better, how good am I am mentoring, metrics that show how I as the individual make the we (the team) better. It is not about how that I as the senior write fewer bugs, but how do I as the senior on the team enable the rest of the team to write fewer bugs.
– Bill Leeper
Aug 22 at 15:31
I agree with this. Metrics are used, but they are different metrics. At my last job my goals were things like how do I enable the team to work better, how good am I am mentoring, metrics that show how I as the individual make the we (the team) better. It is not about how that I as the senior write fewer bugs, but how do I as the senior on the team enable the rest of the team to write fewer bugs.
– Bill Leeper
Aug 22 at 15:31
1
1
"That's simply not the case where I have worked." this isn't the case where anyone works. Qualifying performance and ability based on number of bugs solved is the stupidest thing I've ever heard.
– Edmund Reed
Aug 23 at 1:25
"That's simply not the case where I have worked." this isn't the case where anyone works. Qualifying performance and ability based on number of bugs solved is the stupidest thing I've ever heard.
– Edmund Reed
Aug 23 at 1:25
@EdmundReed unfortunately, this IS actually the case in a lot of places where people works... though it SHOULDN'T be
– xDaizu
Aug 24 at 8:42
@EdmundReed unfortunately, this IS actually the case in a lot of places where people works... though it SHOULDN'T be
– xDaizu
Aug 24 at 8:42
1
1
@xDaizu oh yes, unfortunately I do know that this is how some places operate. What I was trying to say was that it is never an actual measure of anyone's performance, skill and ability, even if places treat it as such.
– Edmund Reed
Aug 24 at 9:09
@xDaizu oh yes, unfortunately I do know that this is how some places operate. What I was trying to say was that it is never an actual measure of anyone's performance, skill and ability, even if places treat it as such.
– Edmund Reed
Aug 24 at 9:09
add a comment |Â
up vote
4
down vote
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.
answered Aug 22 at 20:36
AnoE
5,147725
Indeed, metrics are so game-able we have Goodhart's law, from 1975: "When a measure becomes a target, it ceases to be a good measure"
– mbrig
Aug 22 at 22:30
add a comment |Â
up vote
4
down vote
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.
answered Aug 22 at 20:36
AnoE
5,147725
Indeed, metrics are so game-able we have Goodhart's law, from 1975: "When a measure becomes a target, it ceases to be a good measure"
– mbrig
Aug 22 at 22:30
add a comment |Â
up vote
4
down vote
up vote
4
down vote
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.
answered Aug 22 at 20:36
AnoE
5,147725
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.
answered Aug 22 at 20:36
AnoE
5,147725
answered Aug 22 at 20:36
AnoE
5,147725
answered Aug 22 at 20:36
AnoE
5,147725
answered Aug 22 at 20:36
AnoE
5,147725
5,147725
Indeed, metrics are so game-able we have Goodhart's law, from 1975: "When a measure becomes a target, it ceases to be a good measure"
– mbrig
Aug 22 at 22:30
add a comment |Â
Indeed, metrics are so game-able we have Goodhart's law, from 1975: "When a measure becomes a target, it ceases to be a good measure"
– mbrig
Aug 22 at 22:30
Indeed, metrics are so game-able we have Goodhart's law, from 1975: "When a measure becomes a target, it ceases to be a good measure"
– mbrig
Aug 22 at 22:30
Indeed, metrics are so game-able we have Goodhart's law, from 1975: "When a measure becomes a target, it ceases to be a good measure"
– mbrig
Aug 22 at 22:30
add a comment |Â
up vote
3
down vote
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.
answered Aug 22 at 16:36
AffableAmbler
3,8482921
1
Individual metrics seem to be controversial—at least to team foundation users—visualstudio.uservoice.com/forums/…
– Nathan Goings
Aug 22 at 20:20
3
In some fields, there are no good SMART goals.
– David Thornley
Aug 22 at 21:15
1
@DavidThornley I find that extremely hard to believe. A goal like "have more technical knowledge in X field by the end of the year" works pretty much everywhere (exactly how you measure that varies more, but worst case a manger/team leader should be able to provide feedback)
– mbrig
Aug 22 at 22:28
@JoeStrazzere What about “demonstrate competency in technology x by completing objective y?â€Â
– AffableAmbler
Aug 23 at 15:27
I’m not a huge fan of performance reviews but where it’s not possible to give equal raises across the board, it’s helpful to have the rules of the game spelled out as clearly as possible, especially for those who may be new to the team.
– AffableAmbler
Aug 23 at 15:32
add a comment |Â
up vote
3
down vote
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.
answered Aug 22 at 16:36
AffableAmbler
3,8482921
1
Individual metrics seem to be controversial—at least to team foundation users—visualstudio.uservoice.com/forums/…
– Nathan Goings
Aug 22 at 20:20
3
In some fields, there are no good SMART goals.
– David Thornley
Aug 22 at 21:15
1
@DavidThornley I find that extremely hard to believe. A goal like "have more technical knowledge in X field by the end of the year" works pretty much everywhere (exactly how you measure that varies more, but worst case a manger/team leader should be able to provide feedback)
– mbrig
Aug 22 at 22:28
@JoeStrazzere What about “demonstrate competency in technology x by completing objective y?â€Â
– AffableAmbler
Aug 23 at 15:27
I’m not a huge fan of performance reviews but where it’s not possible to give equal raises across the board, it’s helpful to have the rules of the game spelled out as clearly as possible, especially for those who may be new to the team.
– AffableAmbler
Aug 23 at 15:32
add a comment |Â
up vote
3
down vote
up vote
3
down vote
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.
answered Aug 22 at 16:36
AffableAmbler
3,8482921
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.
answered Aug 22 at 16:36
AffableAmbler
3,8482921
answered Aug 22 at 16:36
AffableAmbler
3,8482921
answered Aug 22 at 16:36
AffableAmbler
3,8482921
answered Aug 22 at 16:36
AffableAmbler
3,8482921
3,8482921
1
Individual metrics seem to be controversial—at least to team foundation users—visualstudio.uservoice.com/forums/…
– Nathan Goings
Aug 22 at 20:20
3
In some fields, there are no good SMART goals.
– David Thornley
Aug 22 at 21:15
1
@DavidThornley I find that extremely hard to believe. A goal like "have more technical knowledge in X field by the end of the year" works pretty much everywhere (exactly how you measure that varies more, but worst case a manger/team leader should be able to provide feedback)
– mbrig
Aug 22 at 22:28
@JoeStrazzere What about “demonstrate competency in technology x by completing objective y?â€Â
– AffableAmbler
Aug 23 at 15:27
I’m not a huge fan of performance reviews but where it’s not possible to give equal raises across the board, it’s helpful to have the rules of the game spelled out as clearly as possible, especially for those who may be new to the team.
– AffableAmbler
Aug 23 at 15:32
add a comment |Â
1
Individual metrics seem to be controversial—at least to team foundation users—visualstudio.uservoice.com/forums/…
– Nathan Goings
Aug 22 at 20:20
3
In some fields, there are no good SMART goals.
– David Thornley
Aug 22 at 21:15
1
@DavidThornley I find that extremely hard to believe. A goal like "have more technical knowledge in X field by the end of the year" works pretty much everywhere (exactly how you measure that varies more, but worst case a manger/team leader should be able to provide feedback)
– mbrig
Aug 22 at 22:28
@JoeStrazzere What about “demonstrate competency in technology x by completing objective y?â€Â
– AffableAmbler
Aug 23 at 15:27
I’m not a huge fan of performance reviews but where it’s not possible to give equal raises across the board, it’s helpful to have the rules of the game spelled out as clearly as possible, especially for those who may be new to the team.
– AffableAmbler
Aug 23 at 15:32
1
1
Individual metrics seem to be controversial—at least to team foundation users—visualstudio.uservoice.com/forums/…
– Nathan Goings
Aug 22 at 20:20
Individual metrics seem to be controversial—at least to team foundation users—visualstudio.uservoice.com/forums/…
– Nathan Goings
Aug 22 at 20:20
3
3
In some fields, there are no good SMART goals.
– David Thornley
Aug 22 at 21:15
In some fields, there are no good SMART goals.
– David Thornley
Aug 22 at 21:15
1
1
@DavidThornley I find that extremely hard to believe. A goal like "have more technical knowledge in X field by the end of the year" works pretty much everywhere (exactly how you measure that varies more, but worst case a manger/team leader should be able to provide feedback)
– mbrig
Aug 22 at 22:28
@DavidThornley I find that extremely hard to believe. A goal like "have more technical knowledge in X field by the end of the year" works pretty much everywhere (exactly how you measure that varies more, but worst case a manger/team leader should be able to provide feedback)
– mbrig
Aug 22 at 22:28
@JoeStrazzere What about “demonstrate competency in technology x by completing objective y?â€Â
– AffableAmbler
Aug 23 at 15:27
@JoeStrazzere What about “demonstrate competency in technology x by completing objective y?â€Â
– AffableAmbler
Aug 23 at 15:27
I’m not a huge fan of performance reviews but where it’s not possible to give equal raises across the board, it’s helpful to have the rules of the game spelled out as clearly as possible, especially for those who may be new to the team.
– AffableAmbler
Aug 23 at 15:32
I’m not a huge fan of performance reviews but where it’s not possible to give equal raises across the board, it’s helpful to have the rules of the game spelled out as clearly as possible, especially for those who may be new to the team.
– AffableAmbler
Aug 23 at 15:32
add a comment |Â
up vote
2
down vote
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.
answered Aug 22 at 15:49
Daniel
92126
add a comment |Â
up vote
2
down vote
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.
answered Aug 22 at 15:49
Daniel
92126
add a comment |Â
up vote
2
down vote
up vote
2
down vote
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.
answered Aug 22 at 15:49
Daniel
92126
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.
answered Aug 22 at 15:49
Daniel
92126
answered Aug 22 at 15:49
Daniel
92126
answered Aug 22 at 15:49
Daniel
92126
answered Aug 22 at 15:49
Daniel
92126
92126
add a comment |Â
add a comment |Â
up vote
-1
down vote
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
answered Aug 23 at 12:41
Ramnath
18429
add a comment |Â
up vote
-1
down vote
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
answered Aug 23 at 12:41
Ramnath
18429
add a comment |Â
up vote
-1
down vote
up vote
-1
down vote
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
answered Aug 23 at 12:41
Ramnath
18429
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
answered Aug 23 at 12:41
Ramnath
18429
answered Aug 23 at 12:41
Ramnath
18429
answered Aug 23 at 12:41
Ramnath
18429
answered Aug 23 at 12:41
Ramnath
18429
18429
add a comment |Â
add a comment |Â
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
StackExchange.ready(
function ()
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2fworkplace.stackexchange.com%2fquestions%2f118009%2fhow-are-salary-differences-decided-in-agile-companies%23new-answer', 'question_page');
);
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Sign up or log in
StackExchange.ready(function ()
StackExchange.helpers.onClickDraftSave('#login-link');
);
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
10
What's preventing you from continuing to track individual performance?
– Snow♦
Aug 22 at 15:07
4
Compulsory link: joelonsoftware.com/2000/04/03/incentive-pay-considered-harmful
– DJClayworth
Aug 22 at 18:35
@Snow The fact that common agile methodologies like Scrum actively discourage singling out individuals and all but mandate dealing solely with a team as a whole.
– ivan_pozdeev
Aug 22 at 22:58
@DJClayworth the pay can't be a good incentive but it still has to be comfortable. See en.wikipedia.org/wiki/Two-factor_theory .
– ivan_pozdeev
Aug 22 at 23:00