Defect Driven Development Continue......

Defect Driven Development (DDD) sounds similar to TDD (Test Driven Development) which is a major function of Agile. But in fact DDD is not fall under Agile Rule. As per my experience I can say that the main principal of DDD falls under Level 5 of TMMi, which is “Defect Prevention” and “Quality Control”. DD actually comes in the picture when the entire functionality as per requirement has been implemented with 2 rounds of SIT (system Integration testing) and you are in the process of creating Final Candidate Build / Release followed by inviting business users for their Acceptance testing. Just 3-4 weeks before testing a FC Build / Release, you do “Triage” of open defects with the help of Business, Development and Test Managers and prioritise the defects which needs to be fixed before FC Build / Release gets prepared.

Even if TDD eliminates 75% of the defects – and how likely is that – the situation is qualitatively the same. You still need to expose the product to testers and field users – “Defect-Driven Development.”

Defect Driven Development (DDD), is also a software-development methodology based around using a project's defect tracking system to track not just defects, but also software features. The central concept in DDD is that from a user's perspective, the biggest defect in a piece of software is that a “necessary feature is missing”. Whether those feature works as it should is critically important, but actually is a secondary concern in the project lifecycle.

The primary advantage of DDD is that it addresses the need for both project governance and transparency, which are generally quite difficult to achieve without rigid project lifecycle methodologies and considerable overhead, usually at the cost of productivity. Because DDD uses a project's ubiquitous defect tracking system that developers already use, but in a novel way, it is a lightweight methodology that can be easily adopted without the need to introduce significant new processes or tools.

I have personally used this methodology in my previous company Cincom and found that this really helps in fastening the Final Release Cycle with Quality and meeting the 100% customer’s expectation. I formulated this approach because, the engineering teams work under very demanding circumstances including wide geographic distribution (UK, US France) and native language differences, and we needed better ways to track project progress and feature implementation before the final release cycle. My product management team has created a virtual image of Mrs. Smith (who was doing manual work before started working on software product) while writing the use cases and the same was used during the analysis of Defects Review also like How Mrs. Smith will use the functionality....what will be there in her mind before using the same.....etc.

We should think of defects as good things that help us achieve what users really want and need.

Assumptions and Prerequisites

There are a few assumptions and prerequisites needed to make DDD work. On the whole, the list is quite short, and covered by most defect tracking systems in widespread use:

• Project uses a defect-tracking system.
• Developers are familiar with and committed to using the defect-tracking system.
• The defect-tracking system allows for assignment of defect to an individual, who can then track his assigned defect easily.
• The defect-tracking system allows defects to be designated as dependent on or blocking another defect, and can automatically help users traverse dependency graphs of defects.
• Pre-emptive notification (for example, email) of changes to defect status or addition of new defects.

How It Works

1. Setup a Defect Triage Team. The member should be Development Manager, Test Manager and Product Manager / Business Development Manager with BA’s (If any).
2. Create a list of all Open Defects with Priority and Defect ageing by running a query.
3. Circulate the defect list to the Defect Triage Team.
4. Setup a meeting. If the entire team is at one location then books a meeting room with System connected to the internet and having Defect Tracking Tool installed else setup a conference call with the Defect Triage Team.
5. Start reviewing the defect which has priority as “Critical”.
6. Discuss every defects with customer prospective, analyze the same that what happen if Mrs. Smith will come across with those issues and then take a call   

            a.  Whether the defect is a real defect or an enhancement.

b. In case of Defect, is Priority Ok and customer will really suffer or     the same should be of lower priority and can be defer for the next release.

c. In case of defer, update the defect with the status a “Defer for next release”.

d. In case the defect is really a critical, assign the defect to the Development Manager. Once the meeting will be over Development Manager will discuss those defects with development engineer and identify the ETA followed by assigning the defect to the development engineer and update the ETA.

e.  In case of Enhancement, assign the defect to the Product Manager / Business Development Manager for further action. If Product Manager / Business Development Manager wants those enhancements should be fixed then create a document for the same enhancement which has estimation from Development Manager and Test Manager. If those enhancements can be implemented without impacting the release date then start auctioning on the same and put the information for those enhancements with the Steering Committee pack / deck and discuss the same in details during the next Steering Committee meeting.

                       i.   After estimation, if you find that the same is impacting the release date then take the same to the CCB (Change Control Board) for further action followed by discussing the same in Steering Committee meeting. If stake holders are agree with changed release date then take an action else defer that defect for the next release.

f.  Do the same activity for High, Medium and Low priority defects also and follow the steps 6.

g. At the end of Defect Triage meeting, you will see a major change with the status of Open Defect.

Make sure while Triaging a defect the TEAM is aware about the Product Release date and all the action should be taken accordingly. It will be to keep a release date a week earlier as a contingency during the defect triage meeting to mitigate any last moment change.

Effects

Overall defect counts start high and go down

Summary

At this point, the general concept of DDD should be clear. In summary:

• DDD is not really very different than the process most projects already follow. The difference is primarily in timing of and perspective in using the defect tracking system: The defect tracking system is used from the very beginning of the development process to track features.
• Clear owners are defined for each deliverable, whether that's an overall feature, code, designs, icons, docs, or something else relating to the project.
• Because defects are dependent on other defects, owners have a natural reason to talk to colleagues and resolve issues rather than go off on their own.
• Defects can be refactored into sub-defects as needed in a right-sized manner for the project. Sometimes, a feature can be wholly implemented by one person, so only one defect is needed. But in the cases where multiple people are involved, that can be expressed with clear ownership.
• The information in the defect tracking system can be mined to create a dashboard of overall project status.
• Defects filed by customers, QA, and others can be related back to the parent feature. This means that both unimplemented features and defects appear in the same dashboard. This is critical for getting an overall picture of the completeness of the project.
• Defects can be assigned and reassigned as needed to gather more information, or to transition work from one person to another, even across widely separated time zones and organizational boundaries. The overall project status remains the same, however.

Consistency of implementation

Because features and defects are in the same place, the developer's primary task list is the set of defects assigned to him. This puts him on the same pages as his manager, architect, and tech lead; there is no sudden changeover between feature implementation and defect fixing, as they are aspects of the same thing. And because the features in the tracking system really describe constraints and deliverables, engineers are still free to innovate like before. The defect tracking system gives him a place to capture his thinking, ask questions, and communicate about what he's doing beyond a very loose notion of "done" or "not done".

Better engineering and QA relationship

In traditional engineering organizations, the engineering/QA relationship is adversarial in nature, or tends to become that way, because the roles are distinct and responsibility is tightly bounded. Part of this comes from the fact that developers may feel caged by having to work on defects instead of new features, and QA engineers may feel disenfranchised when voicing user concerns that are ignored.

DDD has the potential to remove the adversarial component from this relationship in two ways. First, defects are part of the standard development process from the beginning, rather than coming in near the end. Developers have less reason to react negatively to issues filed there because they have been socialized to it from the beginning of the project, and they are accustomed to the idea of both missing features and defects as contributing to user dissatisfaction.

Second, QA engineers can be much more involved in the ongoing feature work because it's well-documented and there is a means by which to be heard. They can comment, add new features and requirements to the set, and even work on developing features rather than feeling powerless until a feature has been implemented. They can feel that their voice has been heard throughout the process, and so there is less reason for them to have to say, "I told you so" when something is implemented or designed poorly.

By making features transparent to developers, QA, and management, and futhermore by giving a concrete means to discuss features and design openly before completion, DDD can offer a formal channel for user advocacy to flow into the design process, not only from QA but from anyone with access to the defect tracking system.

Advantages

There are numerous advantages to the DDD approach:

• Development transparency from the beginning of the development process. As features are completed, the defects are closed. As defects are filed, they can be related back to the feature using the dependency mechanism, and the feature can be reopened as a visible indicator of status.
• Issue and task tracking are automated. The defect tracking systems have excellent methods for assigning defects to developers in an easy-to-track way and notifying interested parties of changes in state.
• Full organizational involvement. Engineering managers are good at making sure defects get closed; the key to this is giving them something they can track. Furthermore, docs and QA need a way to track their deliverables as they relate to project features. Because anyone can either add themselves as interested parties to a defect, or can file their own defects with dependencies, this becomes much easier.
• Cross-organizational coordination. When working across teams and geos with large numbers of features and designs, it becomes imperative to track design decisions and status in a more formal way. Emails are easily lost, and if the right aliases are not used (and archived), then design decisions are all too easy to remain detached from other organizations.
• Better design tracking. All features have a unique defect number, and all discussion (or summary of discussion) can be added to one place for all to see. Design discussion will still occur face-to-face and over email, but relevant decisions can be recorded and then easily tracked in the defect.
• Easy prioritization during traige. All defect tracking systems have the concept of a priority which can be used to indicate the importance of a feature in the final product.
• DDD is very effective when used in iterative development. For example, the umbrella defect for each iteration can contain all the tasks which need to be done before that iteration is complete. When a feature task is complete, QA can add blocking defects on the iteration, so that the release iteration will be stable and closed, thus providing a usable set of functionality that has been tested.

X                                                       

                                                           XXXXXXXX