I was reading Mishkin Berteig's Agile Advice blog article Agile and Lean Defect Tracking today. It talks about an article by Lisa Crispin about defect tracking and whether it should be done in an Agile environment. Crispins's article is called To Track or Not To Track.
Crispin set out to find out whether defect tracking should be used, and came up with some surprising (to me at least) answers. My initial thought was "Why wouldn't you use defect tracking?". As I read further, I came to realise that there is merit in what Crispin writes. In my mind it really comes down to how the organisation wants to manage its workload.
The article got me thinking about what a defect is. I came to the conclusion that a defect is really a software feature that was incorrectly implemented. There may be several reasons why it was incorrectly implemented, but at the end of the day the software does not do what the users expect it to do. Therefore it's defective (in practice it's not as clear cut as that though).
As a project manager, I want my team to be actively minimising the number of defects that are being discovered in the software. This is because I view defects as a piece of functionality to be implemented - a "feature" of sorts. The fewer defects, the less work we've got left to do to complete the iteration and the project. In the past (at a previous job), we included the resolution of defects in the list of features being implemented in an iteration. In our case, most of our defects were identified by our customers - not a good thing. Our management wanted to know that we were addressing our customers problems and would refer to the defect numbers. To show our management that we were addressing the defects we simply included them in the iterations feature list. Doing so showed the development team that we were serious about resolving defects (something that wasn't always the case) and they could see that the list was getting smaller each iteration. Overall I think that how we implemented the process worked quite well.
I think that defect tracking has a place within Agile environments, but can see that it can be problematic if abused or not used properly. I can also see how not using defect tracking could be beneficical; however I suspect that the chances of losing information is higher when a system isn't used. It is more important to choose whether to use defect tracking based on the requirements of the organisation not simply because "everyone else is doing it". I use defect tracking because I believe it helps me do my job. Am I doing it effectively? Now, that's a damn good question and one I'm going to have to review.
BTW - I've added Crispin's article to the bibliography on this site for future reference.
Post new comment