Calibrate your development agility and service quality using root cause analysis

In this fast world, where time-to-market is as crucial as the product/solution itself, defect reduction becomes one of the key objectives for customer delight and competitive edge. Defects are injected or unnoticed at various levels of the SDLC that often results in rework impacting quality and client satisfaction. While everyone is discussing about Shift Left strategies and agile approach, we should not forget to identify robust methodologies to address and curb the avenues of defect injection at the ground level. It is believed that defects are less injected when delivery mangers have  appropriate control over the actions in the initial phase of the projects and ensure that stakeholders rigorously follow the best practices – meticulous preparation and update of Requirement Clarity Index, successful cross functional team meetings, openness to reverse knowledge transfer, proper handshake and sign-off, lucid and timely preparation of Requirement traceability matrix to track significant changes introduced in the project, test management tools updated with test scenarios and test cases well in advance to the test case execution, diligent maintenance of defects/issues logs in a defect management tool, analytical triage of issues etc.

While all this helps in gaining better clarity in the understanding of the requirements, cross-functional dependencies, and work flow, Root cause analysis helps curb defect injection release on release. It enables to learn from the past mistakes, improvise and work on the untapped gray areas which caused defect injection. Defects reported in the earlier release are usually considered to do root cause analysis.

7 Steps to root cause analysis and effective planning for subsequent release:

  1. Collect defects whose root causes are identifiable
  2. Classify the root cause under different buckets
  3. Categorize the buckets under more generic categories. Examples of generic categories are defect due to lack of process, lack of knowledge base, skill knowledge, lack of proper documentation, lack of communication etc.
  4. Analyze and identify the groups which are major contributors to the defects.
  5. Analyze to find when these groups of RCA could have been injected for example possibility of defects introduced due to lack of skill could be early in the project phase.
  6. Follow it by a brainstorming session to find the factor which contributes to the root cause category
  7. Address these factors to limit the growing list of defects.

Case study to examine root cause observed across IT companies and its reaping benefits

Picture2

Above chart depicts process and skill gap are the major causes for defects.

Picture3

The above chart shows that defects were introduced mostly during development and design phase

Essentially, the last step gives us the problem statement which, when resolved, will drive us to defect-free environment. For instance, from the shared graphical illustrations, it is evident that the lack of process and skill gap contributes largely to the growing injection of defects mostly in the initial phase of the software development life cycle.

To address the problem we now need to brainstorm and find the factors which majorly contribute to the problem, continuing with “repeated why” technique of brain storming to get to the bottom of the problem and derive probable solution.

Q1: why large density of issues identified during testing phase?
Probable answer –
issue during testing phase is identified because similar testing was not done by developer after development.

Q2: Why did developer not test similar scenarios?
Probable answer –
Developer did not have enough domain knowledge to prepare and test the scenarios tested by tester.

Q3: Why lack of domain knowledge should inject so many issues?
Probable answer – It is observed that there are significant rise of similar type of architectural issues which could have been avoided if the development team had better domain and architectural knowledge.

Q4: Why team does not have better domain knowledge?
Probable answer – It needs separate, dedicated session where experts and top raters share their knowledge with the beginners and underperformer at the beginning of the project.

Action items and solutions can then be derived from the brain storming session-

Picture1 (2)

RCA is a proven method to measure and control quality. Systematic practice of this method will not only aid in better quality and improved productivity but also increase project-wide visibility.

 

 

Anirban Choudhury

Consultant – Business consulting, VirtusaPolaris. Anirban has an extensive techno-functional background. He has worked for more than 6 years in the IT Industry coupled with experience in working with CMMI level 5 companies on critical projects through the complete software development life cycle across multi domains.

More Posts