Click here to Skip to main content
Click here to Skip to main content

Tagged as

Agile Development Environments and Developer Compensation

, 25 Jan 2011 CPOL
Rate this:
Please Sign up or sign in to vote.
Suggestions regarding compensation in an agile environment
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.

License

This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)

Share

About the Author

George Stragand
Software Developer (Senior)
United States United States
George Stragand is a software developer and manager who has had a 20+ year track record of delivering commercial software on time. In 2012, George published the Pocket Guide to Hiring Geeks, following up the 2010 publication of Agile Development & Business Goals which details his approach to agile development. George maintains his own website where he posts about the topics he is passionate about: software development, cars, guns, guitars and yes even banjos!

Comments and Discussions

 
GeneralYou've nailed the drawbacks, and the benefits. Yes, a team ... PinmemberGeorge Stragand13-Jul-11 9:14 
GeneralHow do you balance the performance of a team vs. individuals... PinmemberMember 420047612-Jul-11 9:56 
GeneralReason for my vote of 4 Good food for thought. PinmemberDrew Rhoades1-Feb-11 4:40 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

| Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.141223.1 | Last Updated 25 Jan 2011
Article Copyright 2011 by George Stragand
Everything else Copyright © CodeProject, 1999-2014
Layout: fixed | fluid