Agile Development and Compensation
Developing software using agile methods has become extremely popular in companies regardless of size. The promise of quickly usable software that meets changing business needs is a very seductive sales pitch for software developers, management and business leaders. While there are many challenges to adopting agile software development methods, none gets less press than the question of developer compensation.
This is extremely curious, since all other positions within a company where performance is critical are compensated based on performance. It is hard to imagine a sales organization that is not on a commission plan. CEOs, Senior VPs, VPs, Directors and other high impact positions all have part of their compensation driven by performance.
Yet even in many software companies, the developers creating the core product that drives the company, are on a compensation plan that has little or no monetary incentive component. Yes, many developers have stock options in the companies they are employed by and many have a year-end bonus riding on company performance. But the difference is that both the "ka-ching" moment for stock options and the overall measurement for company performance are viewed as something only the high priests of finance understand; developers think they shouldn't worry about the details of how a company gets sold or what it means to have a successful year. Developers themselves are sometimes guilty of viewing themselves somehow "above" sales and the rest of the business. Reminding developers, via their compensation, that nothing happens until someone sells something is sometimes necessary.
Worse yet, many developers view their compensation as if it was merely "time and grade", slogging through years of minor single-digit pay increases. Sadder still, many jump to another employer for less than a 10% increase or even a loss of salary so they can work on what they feel is "something cool".
Throw into the mix the concept of development sprints, and management quickly gets confused. It's easy to spot confused management who are making a transition to agile methods, because they are managing projects as if they are broken into two-week (or shorter or longer) death marches. When you hear the development crew referring to management as PHBs (Pointy Haired Bosses), more than just death marches are going on in the development shop; the death-march sprints have eroded trust in management.
So how can this gap in paying for performance be bridged? It takes some radical thinking that is uncomfortable at first for both developers and management but in the end works out to benefit all involved.
First, agree what is included in each sprint. Both management and developers must go through the effort of producing real effort estimations that both sides can agree upon. Then write it down and make it a formal contract between management and developers. It should be viewed as a binding contract, and as such any variation or change should open the door for renegotiation of the terms of the contract. Both sides must take this seriously.
Second, address the compensation side. Start by putting 5-10% of a developers' salary away to be deferred and paid on completion of the contract agreed upon in the first step. In the future, put all raises only into the bonus for each contract (unless someone is grossly out of whack for the current market). And once this is done, put your money where your mouth is; don't wait until the end of the year to pay the bonus, pay it on the next normal paycheck the developers receive.
Addressing the compensation of software developers when adopting agile software development methodologies is necessary to ensure everyone in the company is focused on the bottom line and is contributing at their highest level to drive a profitable company.