Today I was involved in such a discussion with a person from another team. It was a good discussion between intelligent experienced people who each could put a good case for their position. In reflection some time later it occurs to me that the issue is that we hold different mind models of processes, mostly based on experiences, that in particular give very different meaning to what is a 'defect'. The difference is not on severity or priority but on a fundamental definition that is consistent in each mind model (view) but completely different.
When I talk about zero defect development my 'defects' are just as real but are very different to defects in a non-zero defect team. Take for example my work today (which I have mangled for commercial confidence reasons) ...
This week our team's customer asked us to implement a feature to read and write some very basic configuration data to a network device. This was our first story to talk to such a device so it did require us to create the structure used to communicate to devices over a network. So as to reduce the scope (get the story size down to a nice small chunk of commercial value) we asked the customer if we could, in this story, assume that the device is powered and available before we connect to it and there is no communication fault during the transactions. This eliminates all the error handling like:
- Cannot connect
- Not responding
- Returned error codes like invalid command etc
So is the product defective at this point? From my 'zero defect development' point of view ... no. It is not defective as:
- It has given the customer what he asked
- It has, due to collaboration, given the customer what he expected.
- It can be used, that is, we have added commercial value.
The import issue to me is that I feel good. I get a positive feedback working this way as my customer is happy, the work added is visible and the missing functionality is also visible and manageable as another story. Nothing is hidden, the process is positive.
If on the other hand we discovered that a previously implemented feature is now broken then we can still easily maintain zero defect by removing the feature. This may mean a zero or negative velocity but it is keeping true working functionality visible, developers are not accepting low quality, and the project visibility (and hence predictability) is high.
What I perceive as the 'traditional' approach is less collaborative. It asks developers to just do everything in one hit and anything missed is logged as a defect. This gives negative feedback. It is setting up developers for failure and by maintaining a defect list is communicating that 'defects are normal, managed, and acceptable'. It is very hard to get predictable development as defects are wild cards. It is hard to realise the benefits of higher quality development (avoid the defects in the first place) as the process is giving negative feedback.
So in zero defect development development is possible by agreeing to reduced scope in advance and making what is missing more visible. Less surprises, smaller positive steps. In other words zero defect development is possible by avoiding the risk of failure in the first place. It is collaborating to win.