What software developers seem to hate most of all in this industry of delivering digital goods and services seems to be this:
Being told what to do and how to do it.
This isn't always the case and mostly the two are perfectly acceptable when not joined together. For instance, being told what to do is usually acceptable as without knowing what to do (as in go fix the payroll system) we may not have a job. The how can be more shady in acceptance, but it's not a far reach for a developer to know that to fix said payroll system they need to do it a certain way, but if the certain way requires the sharing of too much detail then you're bordering on micro-managing and that's just insulting to someone with enough intellect to make a computer say "Hello world!" in 30 different programming languages.
This is where the pundits behind agile have had the hardest time selling the manifesto. After all, they don't see that what they are evangelizing is process intensive or micro-management-centric. This is because they understand agile development at it's essence, not just it's definition or the definition of the processes behind it. Some have began to grok this and have taken strides to adjust the face of agile development as it is presented to the process-weary IT staffs of the world. [couldn't find the links I wanted to back up this statement so validity here should be questioned]
The logical, linear, cause-and-effect thinking software engineer hasn't had time to consider the essence of this concept. This is buzz, trending toward that of enterprise vendors selling SOA and web services to inept project managers who put more time into earning their PMPs than understanding what really goes into developing solutions in software for people to use. And not only is this buzz, but you're going to tell this intelligent software engineer that they need to do things a certain way. They need to work with a partner (must not be competent or worthy of trust), they need to always write tests and those tests should be written first (can't trust them to code like a big kid) and you're going to make them work in preset increments of time and make them stick to a schedule!
This is madness! How can a person of average to high intellect and moderate sanity even consider working under these conditions? All they see is definitions and those definitions bullet point processes and if all you can do is fence them in with process it must mean you think they can't function as an individual and after all, all they want to do is write code....
I may be rambling, but I think my point is easy to understand. Programmers don't want to have to follow strict guidelines and commit to too many things because what they do isn't hard architecture where things have been defined for years (a bridge of X dimensions will require Y resources and Z time to complete), they work in the realm of virtual architecture where they like to think things are complicated and undefined and there is no way to know when it will be finished until it's finished.
But that isn't the essence of agile development. So how do you sell essence to a group of people that believe in seeing hard facts but delivering virtual goods? That my friends is a job better left to someone more intelligent than myself, after all, I'm one of the guys you should be selling to.
Just saying.
