In a previous post about agile documentation, some folks might interpret “Working software over comprehensive documentation” to mean that there should be no agile defects written up. Shouldn’t all defects be fixed for “working” software within an iteration? If so, then there is no need to write up a defect. There is optimal collaboration within the sprint — the developers and testers work together to fix a defect on the spot, communicate face to face — and thereby there is no need for an actual defect to be written up. Right?
The only problem with this scenario is that it is ideal, but rarely happens in reality:
- There are many reasons for less than optimal collaboration. People get sick or have PTO, or team members just don’t get along or don’t communicate well.
- Defects are not fixed on the spot because the developer has moved on to other tasks or commitments and doesn’t want to go back and fix something at the time the defect is found. “I’ll fix it later, I’m busy now. Just write it up and show me later.”
- Face-to-face communication might be limited to video calls, due to people being in different office locations.
- Either a developer or tester quit and therefore no one remembers anything about it.
I mentioned previously that we need to leave the next person enough information to get started, whether it is requirements, test cases, comments in code, defects, etc. For defects this means the standard stuff to provide someone understanding of what the defect is, where it occurs, and enough characterization to be able to fix it. Agile Defects, per se, could be agile in the sense of less fields in a defect, but I still stand that they do need to be documented. I also think it is useful to know how many defects are made during the internal sprint cycle before the end of the sprint. Wouldn’t it be better for developers not to “write defects” in their code to begin with?