Gunjan Doshi

Last week, I visited a software development team at a major financial firm. They get audited frequently and have to adhere to strict SEC regulations. They have to keep track of every defect that gets generated, the impact of the defect and all its history.

This is how they fix defect:
1. The QA team has to first formalize the defect in a report.
2. The defect report gets submitted to the project manager.
3. The project manager schedules and assigns the defect to a programmer.
4. The programmer then fixes the defect.
5. Upon fixing the defect, the programmer has to fill out two forms.
6. The QA team has to sign off on the forms and close the defect.

The QA team sits on a separate floor making face-to-face communication with the programmers difficult. To add to the woes, the QA team supported three other projects. The manager was also concerned that making the process light could have a negative impact during the inspections.

Let us contrast this approach of fixing defects to the one followed by typical agile teams. First of all, agile practices like pair-programming, test-driven development, acceptance-testing, collective-code ownership, continuous integration etc. make it really hard for defects to sneak through. However, once in a while, a defect does manage to sneak in.

Last year, I coached a team doing green-field development. There were six members on the programmer team and six on the customer team. Their agile approach to fixing defects was:
1. Whenever a defect was discovered, the customer team wrote a story on the index card.
2. They walked to the programmers and explained the story.
3. If the defect was related to a story from the current iteration, the programmers fixed it in the same iteration.
4. If the defect was related to a story from the previous iteration, which was the case most of the times, the customers put that defect card along with the stories in the next iteration.
5. In the next iteration planning meeting, the work to fix the defect gets estimated.
6. Programmers write failing unit test, which once made green, indicate that the defect is fixed.

Few weeks ago, I happened to talk to the present coach on that project. He had changed the way they tackled defects. I liked that approach. The moment they found a defect, the team started working on it. It is similar to QA technique from Toyota. There is no scheduling done, just fix it!

Tags: No Comments