I have worked with a lot of teams made up primarily of contract developers. Not teams from consulting firms, but teams of “assorted” contractors from assorted staff augmentation firms.
Folks that have been doing “short term” staff aug work for a while – (by my definition not longer than a year) – have an hourly mindset. That is, they get paid by the hour. They know that they are the last to show and the first to go – meaning they are only hired when needed, and are rolled off as soon as the work is done. They sometimes have slack periods between gigs, and are almost always willing to bill overtime while they are engaged.
One problem with composing teams from these contractors is that their motivation is primarily mercenary. The payment structure disincents them from finishing faster, or from delivering any more or better quality than will keep them employed on your gig.
When attempting to bring agile practices to teams composed this way, the incentives run against you. Most do not really want to learn or adopt different techniques. Many appear to not really want to improve their skills. Most would rather be directed, than to be self-organizing. Most are not used to the short periods of development, the frequent measurement, the consistent time pressure, that agile tends to bring.
My latest concept to help staff aug contractors bring their best game is to “pretend” that we are not hourly, but doing fixed bid work. Incent the developers by allowing them to bill extra hours unworked, for early delivery. Here is the game:
1) Start each sprint by composing subteams and stories prepared and sequenced
2) Provide a 2 hour incentive to each team member, for a feature that is delivered earlier than projected based on the estimate, passing QA.
3) Have all feature teams bid the each story, awarding the story to the lowest bidder.
4) Project and commit a delivery date for each story with the winning team to establish the contract.
Options here are to impose a 2 hour penalty for non delivery, to increase the incentive to 2 hours per day early or late, etc.
You can have the developers pick teams, or you can nominate team “captains” who pick, or you can organize the teams yourself.
Remember that for this game to work, remember your goals are to get more working features implemented with quality sooner.
Postscript – I am not advocating actually doing this. But using it as a model to recognize that we don’t incent developers to deliver.
No Comments