At our shop, we strive to be agile. And I'd say we are making great strides. That said, a few of us have spotted a pattern we have started calling Failure Driven Development.Failure Driven Development can basically be desribed as an agile release/iteration cycle where the bugs/features are guided not by tasks and stories with acceptance criteria, but with defects entered in the defect tracking software.Our team has a great Project Manager who strives to get the acceptance criteria from the customer(s), but it's not always possible. From my development chair, this is due to the customer either not knowing exactly what they want or (and this is the kicker) two different camps at the customer's main office conflict with how a story should be implemented. Camp A will loosely dictate that Feature X works like this, then Camp B will fail it due not functioning like that. Hence, the term FDD. The process is driven by failures.This leads to my question: Has anyone else encountered this and if so, any tips/suggestions for dealing with it?We have, of course, tried to get Camp A and B to agree prior, but everyone knows this isn't always the case.Thanks
What to do about Failure Driven Development?
agile;anti patterns
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. 