Team Work and Defects

For the purposes of this post I'm using Defect in its broadest sense. 

The Product Owner, Tech Lead, and Developers should be consciously working together to reach a goal. Identifying something as a defect should not be pejorative.  It should be a means of improving process and ensuring cost effective delivery of features. It is not personal. It is a way to see that there is a flaw in the system that needs to be investigated. 

From the vantage point of the Product Owner, identifying a defect is important to ensure both system correctness and to manage cost. If a development team cannot consistently deliver on the specified requirements, or if that consistency is derived of trial and error approaches, a product or feature may become impracticable for the needs of the business. A product owner should ask, did I specify this completely? What additional verifications could I have specified to have avoided this. 

From a Tech Lead's perspective a defect signals a flaw in workmanship. They should ask, did we ask the right questions when preparing to do the work? Did we make the correct verifications after the work was complete? Are we missing a test? What kind of automation and tools could we bring to bear to prevent this type of issue from occurring again?

Developers should be asking themselves, how did I not understand the requirements? Should I adjust my testing strategy to keep the acceptance criteria in front of me? What questions did I fail to ask? What processes and procedures did I fail to observe? What processes could I suggest to the team for preventing this kind of issue?

All of these questions should be asked openly and feely. A team operates as a unit, not a collection of independent contributors. For each perceived defect we should have an open and frank discussion about the nature of issue and attempt to identify the source using techniques like 5-Whys or Eight Disciplines

Finally, remember that none of this is personal. We get emotionally attached to our work as a consequence of caring deeply. This often leads to accusatory and defensive behaviors when discussing defects. Our natural inclination to avoid conflict isn't much help either. Try a different tack when approaching defects.

First, when declaring something to be a defect, propose the issue rather than declaring it. There may be a vantage point from which it does not appear to be a defect. Additionally you may be making a declaration without all of the information. 

When discussing the whys of a defect, avoid becoming defensive. Try to state the facts of the situation as plainly as possible without adding emotionality to them. Be as objective as possible. 

Finally, get comfortable with saying 'I don't know'. We cannot know everything despite our best efforts. So if someone makes an assertion in either direction, ensure that you've considered your response. The real response to any assertion can always be 'I don't know'. Be honest with your self and your team and avoid speculation and hyperbole when discussing the 'why it happened' portion of a defect. Keep it simple.