Failure Driven Development
- by DevSolo
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 losely 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
