distributedlife

A criticism I have for the waterfall or v-model is that the people before you can have a mentality of throwing their output over the wall and then washing their hands of it. Their engagement is only reintroduced when there is an issue with what they have produced. If they have been allocated elsewhere this can take time for them to get focused. In other cases it can seem like a criticism of their work to have it come back after they have completed it. The issue with the last part is that the product creation is the effort of an individual for the team rather than by the team for the team.

I very recently came to the realisation that testers have the same mentality and the same responses when they raise defects. The get written and then cast over the wall to the developer. Washing their hands of it until the new code returns. Sometimes the problems isn’t fixed correctly or causes regressions elsewhere and we don’t understand why. Other times the defects comes back requesting more information or a clarification.

I feel we need to take a more collaborative approach to defect resolution. In some cases it can be as simple as sitting down with the developer to resolve an issue now, given that the fix is simple enough. Other times it will be an active effort to define the problem statement. This will help both you and the developer understand the what is wrong and why.