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.
8 comments:
As always Rob, insightful.
And completely true...
Nice post Rod. This beings to my mind the question of documentation. How did you clearly define the completeness of functionality that you would be providing. It seems that in you example there is only a few points of functionality, i.e. sending information to a device. But (to try and extend this) did you also need to define the range of information you could send (i.e. could you send control characters or non-asci)
I suppose my question is do you need to increase documentation to support this?
Hi James,
Well we are working in an XP style of development. The 'stories' (functionality) are kept as small as we can. So in this case we choose to implement the most minimal functionality possible that will add demonstratable value to the product. So in this case it was something like being able to just detect the connection.
So the discussion with our internal customer leads him to document other required functionality. We have an excellent customer. So, in this case, he will add a story for handling errors. Things are kept very visible.
Does that answer the question?
Not quite. My question is around directing the QA team. You're going to provide a limited set of functionality so it's important to document what is going to be there (i.e. with the story). It's also important to document what is not going to be there so the QA team don't report bugs on functionality that you know is not going to be there but they think should be.
So to reach this point do you find you need to produce more documentation.
I supposed the possibility is that the story is so well defined that the missing functionality does need to be stated. Normally i associate a story with slightly vague functionality, so i'd assume that documentation of not yet implemented features would be required.
Hi James,
The team I'm currently in does not work with a QA team but takes on most testing itself with further testing by the customer. But, I have worked with a QA team in a prior company and what your talking about was an issue.
The QA team I did work with was very good. The issue of 'what is expected' was very much a problem. But then the company had very poor quality. QA spent most of its time finding coding bugs as opposed to it real job of confirming fit for purpose in real life scenarios. The developers had a poor attitude to 'completeness' and the management took a 'defect density' approach with a huge defect database.
The things that did work, when allowed to, was to treat QA as a customer. Get a QA person into the team and attending every stand-up and planning meeting. Your right, this cannot be put into writing. It can be achieved through collaboration.
The other approach was to dice up the stories in another direction. If you cannot communicate what is not in there then deliver even smaller chunks with each being absolutely complete. e.g. Add an edit box to allow an IP address to be entered. No controls to do anything with this data are present so there is confusion :-). QA will then test range, copy, paste, persistence, etc. Just how you cut it.
I've got mixed feelings about QA teams. If the product is very difficult to test, e.g. requires 50 PCs to test then a QA team is required. But the fact of having a QA team seems to send a message to developers that QA is there to find defects and they have a safety net. In an XP style development frequent delivery is not an option, it is critical to success. If you have a QA team this means delivery to QA. So often this is left to the end of the project or some 'milestone'.
So ... the QA team must be integrated into the development team and not separate.
Somewhat longer response than I intended ... hope this is interesting/useful.
Rob
That is one very fine response.
It's so hard to find good help these days.
p.s. love the dogs
Developers should identify the defects in their source code in the early stage of the software development process. This may help people to save more time and money arising out of software defects. Developers can use static tool like Coverity Prevent for analyzing source code for fixing defects. Using Coverity Prevent developers can fix defects like memory leak, dangling pointer, uninitialized date etc. Coverity Prevent ,
used by the Department of Homeland security to scan many open source projects.you can get more info at at http://www.Coverity.com
Post a Comment