I would like to solicit thoughts on bonuses (and thank everyone for so many great thoughts on tool usage).
We are a small (and growing) team with a year of ad-hoc development behind us.
Our bonus budget has previously been distributed as:
- 50% of budget for “Christmas bonus” (it’s a Vietnamese dev team so this is actually a Tet bonus, but is equivalent to the more commonly known “Christmas” bonus)
- 2 others @ 25% of the bonus budget.
A bonus at Tet is a very cultural norm, so I don’t want to change that, but the other 50% is up for discussion.
My initial though is to tie a first 25% bonus (2-5 months from now) to some metrics of agile acceptance:
1) A stable and predictable velocity
2) Successfully completing the work committed to in the sprints (perhaps take the best result of the average of all sprints or the last 4 sprints when it’s time to issue the bonus)
3) The incorporation of automated testing (this is virtually nill now and a primary priority in moving to Agile)
Thoughts on that? And comes after that?
?) Bonuses based on some metrics of each iteration? Dispersed per iteration? Twice a year?
?) Bonuses based on releases (on the order of 2-5 months between releases)
?) Other ideas?
///////////////////////////////////////
I guess there should be nothing wrong with trying to use financial incentive to motivate people or to get developers to deliver more throughput. But what may be not natural in this approach is, rather than motivating Agile team members by appealing to their pride and sincerely giving them all the empowerment and support they need, we are talking here about using money as a main motivating factor for productivity. As far as I remember, this is not what is at the foundation of the Agile manifesto. Far from it.
Going beyond the morality question, I guess the question next will be to know how much of this productivity would be to produce software of quality rather than eventually trying to game the system to produce the best metrics possible to make money.
Last but not least, should we really need to resort to money as an incentive, I guess there should be no need to get teams to use Agile since anything else could do, as soon as people are interested in working hard to make money.
Just some thought for food.
///////////////////////////////////////
Metrics never really measure what we want them to. Rewards based on metrics risk encouraging people to game the metrics instead of doing what we really want them to do, which is work together to make the project successful.
For agile teams, it is a good start to give everybody on the team the same bonus in order to encourage team work instead of individual "heroism".
Here is an article that makes the point well:
http://www.leanessays.com/2003/01/measure-up.html
///////////////////////////////////////
Money is definitely one of the key motivators to most of us... and we cannot discount this factor.
Probably the best way to structure bonuses for Agile teams is someway that can promote collective ownership in teams and consequent team collaboration for collectively ensuring "productivity" as you call it.
My suggestion (I have tried it with the teams I coach and it works, and works well): A variable pay of say 25% that will be calculated based on customer feedback after each iteration. (customer could be product owner for Scrum teams). The customer rates the value delivered by the team in each iteration on a 10 point scale. Each point is 10 percentage point. Say if the team gets a feedback score of 8 for an iteration, all members get 80% of the variable pay for that period. If they get a score of 5, they get 50% of the variable pay.
This kind of a team bonus, will motivate the team to innovatively and creatively find ways to get the best feedback from the customer, and this would be a good way of ensuring continuous improvement of the team in their ability to deliver their best value to their customers
Ideas and feedback from members here to improve this are welcome
///////////////////////////////////////
Money is definitely one of the key motivators to most of us... and we cannot discount this factor.
It is only to a certain extent. If you are making enough money on which to live relatively comfortably, then putting up more money as an incentive can actually have detrimental effects on individuals and quite detrimental effects on teams.
This classic TED video of Dan Pink explains is much better than I can: http://www.ted.com/talks/dan_pink_on_motivation.html
///////////////////////////////////////
That was an excellent article, and I’m onboard with the team based metrics, now to define those.
· Customer satisfaction was suggested in another email, I might further interpret that as ensuring we have working software at the end of each release as a little more actionable.
· I can also set some goals based on our agreed upon code-base improvements such as constantly improving coding/code structure standards (and following those); implementing automated testing, etc.
· I would also think to include some improvement goals that the team identifies in retrospectives (generally assuming that these will be meet).
///////////////////////////////////////
Why is it millionaires haggle for more money even when they are being paid well and are living quite comfortably? In some societies, "money" is the only way out. So while money may not be a good long term strategy or possible a bad decision, what's the best decision that can be made given societal factors? I would think a bonus shared by the team is a good start
We are a small (and growing) team with a year of ad-hoc development behind us.
Our bonus budget has previously been distributed as:
- 50% of budget for “Christmas bonus” (it’s a Vietnamese dev team so this is actually a Tet bonus, but is equivalent to the more commonly known “Christmas” bonus)
- 2 others @ 25% of the bonus budget.
A bonus at Tet is a very cultural norm, so I don’t want to change that, but the other 50% is up for discussion.
My initial though is to tie a first 25% bonus (2-5 months from now) to some metrics of agile acceptance:
1) A stable and predictable velocity
2) Successfully completing the work committed to in the sprints (perhaps take the best result of the average of all sprints or the last 4 sprints when it’s time to issue the bonus)
3) The incorporation of automated testing (this is virtually nill now and a primary priority in moving to Agile)
Thoughts on that? And comes after that?
?) Bonuses based on some metrics of each iteration? Dispersed per iteration? Twice a year?
?) Bonuses based on releases (on the order of 2-5 months between releases)
?) Other ideas?
///////////////////////////////////////
I guess there should be nothing wrong with trying to use financial incentive to motivate people or to get developers to deliver more throughput. But what may be not natural in this approach is, rather than motivating Agile team members by appealing to their pride and sincerely giving them all the empowerment and support they need, we are talking here about using money as a main motivating factor for productivity. As far as I remember, this is not what is at the foundation of the Agile manifesto. Far from it.
Going beyond the morality question, I guess the question next will be to know how much of this productivity would be to produce software of quality rather than eventually trying to game the system to produce the best metrics possible to make money.
Last but not least, should we really need to resort to money as an incentive, I guess there should be no need to get teams to use Agile since anything else could do, as soon as people are interested in working hard to make money.
Just some thought for food.
///////////////////////////////////////
Metrics never really measure what we want them to. Rewards based on metrics risk encouraging people to game the metrics instead of doing what we really want them to do, which is work together to make the project successful.
For agile teams, it is a good start to give everybody on the team the same bonus in order to encourage team work instead of individual "heroism".
Here is an article that makes the point well:
http://www.leanessays.com/2003/01/measure-up.html
///////////////////////////////////////
Money is definitely one of the key motivators to most of us... and we cannot discount this factor.
Probably the best way to structure bonuses for Agile teams is someway that can promote collective ownership in teams and consequent team collaboration for collectively ensuring "productivity" as you call it.
My suggestion (I have tried it with the teams I coach and it works, and works well): A variable pay of say 25% that will be calculated based on customer feedback after each iteration. (customer could be product owner for Scrum teams). The customer rates the value delivered by the team in each iteration on a 10 point scale. Each point is 10 percentage point. Say if the team gets a feedback score of 8 for an iteration, all members get 80% of the variable pay for that period. If they get a score of 5, they get 50% of the variable pay.
This kind of a team bonus, will motivate the team to innovatively and creatively find ways to get the best feedback from the customer, and this would be a good way of ensuring continuous improvement of the team in their ability to deliver their best value to their customers
Ideas and feedback from members here to improve this are welcome
///////////////////////////////////////
Money is definitely one of the key motivators to most of us... and we cannot discount this factor.
It is only to a certain extent. If you are making enough money on which to live relatively comfortably, then putting up more money as an incentive can actually have detrimental effects on individuals and quite detrimental effects on teams.
This classic TED video of Dan Pink explains is much better than I can: http://www.ted.com/talks/dan_pink_on_motivation.html
///////////////////////////////////////
That was an excellent article, and I’m onboard with the team based metrics, now to define those.
· Customer satisfaction was suggested in another email, I might further interpret that as ensuring we have working software at the end of each release as a little more actionable.
· I can also set some goals based on our agreed upon code-base improvements such as constantly improving coding/code structure standards (and following those); implementing automated testing, etc.
· I would also think to include some improvement goals that the team identifies in retrospectives (generally assuming that these will be meet).
///////////////////////////////////////
Why is it millionaires haggle for more money even when they are being paid well and are living quite comfortably? In some societies, "money" is the only way out. So while money may not be a good long term strategy or possible a bad decision, what's the best decision that can be made given societal factors? I would think a bonus shared by the team is a good start
