The power of the defect retrospective

Posted by in Management category on for Beginner level | Points: 250 | Views : 9218 red flag

Consider this typical situation in a software development project. The project deadline is looming on the horizon. The development team is sitting on a huge pile of defects which is required to be fixed urgently and QA (Quality Assurance) sign-off is required to achieve the project deadline. Much as the development team is trying hard to meet the deadline by putting in extra hours every day and working on weekends, a disturbing trend emerges. On a daily basis, more and more defects are getting reopened and new defects are getting injected due to the defect fixes being applied. This is a classic case of the defect spiral taking place. This is one of the most de-motivating periods for both the development and QA teams. In the effort to speed up work to meet deadlines, the team only ends up perpetuating the same problem it is trying to solve.

Let us see further how we can solve this problem, or rather, prevent it from occurring in the first place.

Getting on top of requirements

What is a defect?
While there are many complex ways to answer this question, I found the below definition clear and simple.

“A defect is a deviation from requirements.”
The starting point, then, of preventing defects from getting logged is ensuring that the entire team which will be working on the backlog thoroughly understands the requirements in detail. One thing that has always worked for me is collective team discussions, closed room meetings held with the primary objective of fleshing out all the core requirements and publishing the questions to be submitted to the Business Analyst or the actual end users. Analysing all aspects of requirements can never be an individual job, getting the whole team involved at an early stage ensures that nothing slips through the cracks. 
Key steps to be followed:
  • Get hold of the sprint backlog
  • Get all the developers into the Team room and dissect each User Story and list down gaps
  • Post the entire set of questions coming out of the requirement and impact analysis on the team wiki (if you are not using one, well, then you are probably wasting too much precious team time on emails and con calls)

Missing Acceptance criteria

As part of the requirement and impact analysis, sniff out all the missing acceptance criteria for each User Story. For each missing acceptance criteria which you find at this stage, you will be preventing many defects from getting logged later on.

As illustrated above, every User Story has multiple acceptance criteria, every Acceptance Criterion translates into multiple Unit Test cases which when executed thoroughly leads to a defect free delivery. This is one of the core principles of defect free delivery.

Plan out / estimate the unit testing effort at the sprint planning stage itself

Make sure all your time estimates include sufficient time for performing unit testing for each user story. If you have a good track record of delivering defect free code consistently, none of the stakeholders will question you on these efforts.

Moreover, there are many software contracts which have clauses like “ZDC – Zero Defect Code”, “100% code coverage”, etc built into the contract. It is not possible to achieve compliance with these clauses without having a rock solid unit testing strategy in place.

Ensure high Unit testing coverage

This is a paradigm shift in thinking for the individual developer who has been conditioned to think all along that “testing is not my responsibility”. Getting your developers to move from this foundational belief to “Quality is everyone’s responsibility” is a journey in itself, one which will take some time, probably 2-3 sprints. The whole structure falls in place when the team starts taking pride in achieving close to zero defect deliveries and this becomes part of the team culture. Each developer needs to ensure that for the User Story he has volunteered to work on, all the acceptance criteria mentioned  are getting tested  based on the unit tests he / she has written. This is crucial.

Put a defect RCA(Root Cause Analysis) definition in place

As part of the defect lifecycle, for every defect that is logged by QA please ensure that the individual developer responsible is mandatorily required to choose the root cause of the defect from a list of pre-defined root causes.
A sample listing of potential root causes is provided below:
1RequirementThe requirement has not been clearly understood, the team’s assumption does not match with the business user’s expectations.
2Impact AnalysisThorough impact analysis has not been done and implicit requirements have been missed out
3Wrong implementationThe defect was caused due to an incorrect coding implementation
4Testing errorThe test case was incorrect effectively resulting in an invalid defect getting logged
5ConfigurationThe defect was caused by incorrect static data setup
6Existing bugThis is an existing defect in the system which is probably also present on the live environment
7Injected defectThis defect has been injected due to a different defect fix.
8EnvironmentThe defect has occurred due to a code base lining issue, server level configuration, etc
You could use this as a baseline for creating your own RCA matrix as per your project needs.

Conduct weekly defect retrospectives

Some practices that have worked well for me are listed below:
  1. Ensure that all the developers attend the meeting
  2. Time box the meeting to 1 hour
  3. During the meeting, go through each and every defect, check if the RCA is correct, ask the question what could have been done better to avoid logging of the defect, etc.
This is a very effective meeting as it sensitises the developers towards adopting a more responsible approach towards their work and also ensuring that they deliver defect free code of high quality. Ideally, try to cover all the defects logged in the defect retrospective meeting.

Once you do this consistently, an interesting trend will commence. You will notice that the defect count will show a sharp dip and developers will be extra careful towards ensuring that they do not introduce any new defects. Within 3 sprints, you will observe a drastic reduction in the volume of defects and once this is achieved, it will stay that way.

Why is the defect retrospective so powerful?
  • It’s basically reflection, consistently holding up the mirror and seeing things as they really are.
  • It’s unadulterated, undiluted feedback
  • It is self-corrective by design

Have a strongly defined check-in policy in place

Most of the ALM (Application Lifecycle Management) tools in use nowadays, for e.g. Microsoft TFS provide you the ability to customize the code check-in policy as per the requirements of your project. Some effective customizations are mentioned below:
  • Ensure that every check-in is mandatorily reviewed by the team lead and at the point of checking in the code, the name of the person who has reviewed the changeset ia mandatorily recorded.
  • The purpose for which any check-in is being made also needs to be mentioned as part of the check-in comments for e.g. for a defect fix the defect id needs to be mandatorily mentioned.
  • Activate Email check-in notifications
    - This serves a  dual purpose:
    - For every check-in that is committed, all the team members, the team leader and the project manager get an email alert providing low level details about the changeset which was just checked in. It provides details on which source code files were modified, which files were added, etc.
    - This triggers off a rapid, self-corrective mechanism. The moment someone does a bad check-in, other developers swoop in to get it corrected since they the impact immediately due to the email notification.
All these customizations are very effective in bringing in greater accountability and discipline in the development team since all their actions are openly visible and as you might be already aware, high degree of visibility is one of the key pillars of Scrum. 

Page copy protected against web site content infringement by Copyscape

About the Author

Full Name: Sainath S
Member Level: HonoraryPlatinum
Member Status: PanelMember,Member,ITIL,PMP
Member Since: 3/10/2009 3:02:15 AM
Country: India
Regards, Sainath S,
Sainath S,PMP,CSM(Certified Scrum Master), ITIL V3F,COBIT 4.1F is a practising Project Manager and has diverse experience in leading global projects from inception to final delivery and closure. Find useful information on Project Management on his site

Login to vote for this post.

Comments or Responses

Login to post response

Comment using Facebook(Author doesn't get notification)