Many software projects seem to me to have inherent opposing forces present at all times. Analysts wrestle with business folks about what’s needed, developers wrestle with analysts about too much / too little documentation, QA folks wrestle with developers about the sufficiency of unit testing, management wrestles with development about cost and schedule, and on and on.

Many of us are naturally repelled by conflict. We try to prevent it from happening, and when it does happen, we try to get away from it as soon as possible. (With the sole exception of people from New York.) On a software project, the easiest way to avoid conflict is to burrow in a cave and do work. Unfortunately this is totally contradictory to the collaborative best practices that make Agile projects work, and rather than avoid conflict, it just defers it.

Agile projects tend to expose conflict early and attack it head on. Since this is unnatural and uncomfortable for many people, it can slow the adoption of Agile practices. Embracing Yin-Yang and cultivating opposing forces on a project into an efficient process with quality results is the very first hill to climb when starting your first Agile project.