The best things in life are free, but that's for the birds and the bees

Compensation of agile teams (XP teams, scrum teams, what-have-you) is a tricky issue. Ken Schwaber takes a stab at it in "The Enterprise and Scrum" (if you haven't read it, the bad news is the lack of Star Trek references) where he ties parts of compensation to enterprise performance (doesn't even say "warp factor" anywhere) which is nice because you want everyone focused on the enterprise and not their individual role. Mary and Tom Poppendieck have a swing at it in "Implementing Lean Software Development" and make some nice points about promotion, influence and my favourite "Find better motivators than money" - something I particularly support because
1 - I'm not motivated by money (ok I like not being poor, but I prefer books & music to cash though I do like Pink Floyd's Money)
2 - It works with Prof Vroom's expectancy theory, which looks to have some reasonable thinking behind it and how can you doubt someone with onomatopoeia for a surname?

The problem with compensation is - IMHO - organisations couple compensation with organisational structure and motivation/incentive (can you couple three things?). The higher up the structure the more compensation, and the bigger and broader the bonus (eg retention bonuses). When you have a self-organising, cross-functional team the structure is removed. These teams are organised around enterprise/product/project goals so incentive for role based performance fractures the team mindset.

So here is an idea I have been toying with ready to be torn apart by better thinkers.

Salary should be a factor of responsibility and (positive) influence (ok that does mean the higher up you go in the org chart the more salary you should have). Individuals with great deal of organisation experience should have both of these, ie if you can influence how the organisation behaves you should have some overt responsibility for the outcome. This allows for people with different skills and preferences to be adequately payed without giving up their vocational passion to earn more by becoming a manager.

If there must be a bonus give it at the team level, if there are multiple teams give it at the project level. Then have the team decide how to adequately distribute the bonus. Wait, that was too easy, and you can't trust the team to look after that kind of thing - but you can trust them to deliver on a strategic, money making project.

Ok, how about do it like this. If there is monetary bonus it should be associated with the outcome of some work. Some of the benefit the organisation receives from this work should be taken to reward the team. I now depart from K Schwaber's idea in that I think the bonus should distributed dependant on your contribution, and not you seniority. Taking Kerth's Prime Directive (that's a touch treky "remember the prime directive number 2s") everyone has worked to the best of their ability and I think should be rewarded evenly, they are already being payed based on the difference in influence and responsibility so don't double up.

Distribute the bonus based on the number of days/iterations people were working on the project. If you're on the gig from day one, you receive the maximum amount, if you're on it one day it's the minimum. People who work across projects in a kind of consulting role should pick up the dosh from all the projects they touch.

To make this work all projects will have to have explicitly stated value that can be demonstrated, which is surely a good thing. Think of the pleasure of portfolio management.

A side effect would be that everyone wants to be on a small team doing a high value project. Which is ok, because why would you do low/no value projects, and to deal with the need to have longer project have these projects do multiple releases to deliver some return before the end of the project.

No one will want to work in BAU or Support, so get rid of it. "Developers should eat their own dog food" J Sutherland 2008. If you make it/design it/depploy it you're responsible for it. So this should keep people focused on delivery high quality results.

The product owners that regularly return their estimated value would quickly stand out, not just in the finance department, but when teams form everyone will want to work with these people.

There must be significant problems with this agile utopia, but I hate to contradict myself so I'm not going to think about it. I also didn't bother with expectancy theory and trying to work out the motivators for individuals, get over it - I did. There is nothing here about how to hire or review people if this is implemented, sorry about that.