Agile – Difference Between Acceptance Test-Driven Planning and Development

Every line of code I write is using test driven development. If management isn't on board with writing tests first then I don't tell management about it. I feel that strongly that test driven development is a better process.

Wildly conflicting requirements is not unusual in the corporate world. And this is frequently the reason for business process automation projects to "fail." It can be as simple as "the policy and procedures manual says to do X" while the people that actually do the work do Y. Making the software do Y means that the people paying for the software will insist that the software is defective from their perspective. Making the software do X means that the people who actually get the work done cannot get the work done.

Normally, most development companies will choose what the managers say over what the workers state because that's how the bills get paid. In the ideal world, there is no impedance mismatch between written and actual policies; in the real world much office work is informally partitioned and undocumented.

Camp A will losely dictate that Feature X works like this, then Camp B will fail it due not functioning like that.

The mismatch between CampA and CampB is a political issue and not a software issue. Solving the problem is going to involve talking to people and getting one clear winner.