During a recent dinner conversation in my home, one of my guests asked what I do and I started talking about agile software development. There was a general response as to why doesn't everyone develop software this way, as if it was so logical it would be common sense.

The reaction startled me a bit, especially since I see so much resistance to agile software development. I think much of this resistance comes from the emotional baggage of those considering agile development.

Many people considering agile development are doing so because they?ve had bad experiences and problems with software development. This problematic history is marked by dysfunctional work environments, failed projects, missed deadlines, extreme pressure, blame assignment, and general tension.

For example, a common management opposition to pair programming is "Why would I pay two people to do the work of one?" This frequently can be interpreted as "I already pay two people to fail to do the work of two people, now you want me to pay two people to fail to do the work of one person." There is so much distrust of the developers? productivity that management may fear pair programming granting permission to produce less.

Another example of emotional resistance is from a project manager. He may wonder, "Do I still have a job in XP?" or "How will people know I am doing a good job?" Developers have similar fears. In a pair programming environment, there is less room to be the "hero" or show off programming prowess. You can't take individual credit for a successful application when there is no code ownership.

Sometimes the resistance comes from the transference of previous experience. For example, I once outlined an automated testing approach to a group and someone reacted very badly. He flatly claimed it would not work and had no value. It was revealed later, he had tried something similar and it failed. He identified the two ideas as equivalent and had a "it's happening again" reaction, which blocked his ability to assess the actual approach outlined and not just his assumption of it. Furthermore, if the approach I outlined did work (and it really was similar to his own), then he is faced with confronting a new type of failure; maybe he was the flaw and not the idea.

In all these examples, there is an emotional resistance to agile development. The irrationality of emotions requires a different approach; you can't simply present a logical framework and expect that reason alone will be sufficient to generate acceptance.

I often hear "How can I sell agile development to...?" Maybe it is better to ask, "Why aren't they buying into agile development?" The human component of a team is much more important than the process. The better one understands the human dynamics of a team the more successful the project will be.