Economy-Driven Task Assignment

In the beginner's mind there are many possibilities, but in the expert's mind there are few.
-- Shunryu Suzuki (quoted in Little Zen Companion, by David Schiller, 1994)

About a year after I started working as a project manager (after numerous years toiling as a programmer), I'd come up with several ideas for making the software development process a little more efficient. Since then, of course, I've learned that only highly formalized and rigidly documented processes produced by a big committee and blessed by the new groups of auditors required to evaluate compliance with the new rules are acceptable... but hey, those naive early days were creative.

I was reminded of one of those ideas today when I read an interview on Gamasutra with Aaron Loeb, COO of Planet Moon Studios, developers of (among other games) the wonderful Giants: Citizen Kabuto. In this interview, Loeb describes Planet Moon's experience with the Scrum mode of agile software development. It's something a group where I work is using, and I'm always interested in improvements to my own development process that I won't be allowed to implement, so I spent some time today reading about Scrum.

One of the ideas in the Scrum process is that, instead of a lead or manager assigning tasks to the developers in a group, the developers themselves are expected to select tasks from the pile of current tasks (the "sprint backlog"). This reminded me of the idea I'd had back in my project managing youth... but with a twist.

My notion was to apply economic theory to software development to maximize the efficiency of the process. Specifically, at the start of a new release cycle I'd provide descriptions (and any requirements) for all known tasks, sorted by priority. Over the next couple of days, each programmer would then bid on each task (in priority order) with an estimate of the number of hours they thought it would take them to implement that task. At the end of the bidding period, the low bidder for each task would be assigned that task. Once the number of hours for a developer reaches the alloted number of hours in the schedule for that release, that developer would exit the bidding process and the task would be assigned to the developer with the lowest remaining estimate for that task, and so on until one developer remains. That developer would then be assigned tasks from the pile in priority order until their workload (in estimated hours per task) reaches the limit for that release.

Bearing in mind that these would be estimates only, and estimates are likely to be off somewhat, this should -- theoretically -- result in the maximum amount of prioritized work being performed in the available time.

Of course there are some gotchas in the process described above. Some special-case provisions would have to be made; for example, what if for the next prioritized task every developer estimates that the task will require more time than anyone has remaining for the next release? Either the task will have to be deferred to a subsequent release (which may not be appropriate), or someone will have to have one or more assigned tasks unassigned and replaced with the new, larger task (which requires a lead/manager to interfere with an otherwise automated process). Another structural issue with this process is that very efficient developers would tend to be assigned a large number of small tasks, while the less efficient developers would get stuck with working a few big tasks -- not necessarily optimal for group dynamics over the long term of a project.

But there's a more fundamental issue to be resolved. Namely, what's the incentive to be the low bidder? There's no penalty for doing so, since everyone gets loaded up with roughly the same amount of work (in estimated hours). But that also means there's no incentive to figure out the most efficient way to code an enhancement or bugfix. So perhaps the developer with the lowest average number of hours per task in each release should get some kind of bonus or goodie. Some might feel that this would generate an inappropriately competitive group environment, but you can hardly have an economic solution without providing some kind of tangible advantage for one behavior over another.

Of course, a manager who can't reward one developer and not another according to documented results isn't likely to appreciate an agile software development environment in the first place. An environment where everyone has to be treated exactly the same regardless of results is probably not a place where process efficiency is a goal.

For the more agile workplace, I still wonder whether this economic approach could be tweaked into functionality, and whether it would actually work as I imagine it might.