Tuesday, February 24, 2015

Handling defects / Bugs in Agile.. Achieving the unachievable Zero defect Target !!!!!!!!!

People have all the reasons to justify that their product is quite different/complex and they have to live with 100's of defects. But is it really the case or just  lack prioritization and well defined process.
Some leadership teams just accept that they are part and parcel of the system and stop making effort to tackle them. Defects/Bugs are a reflection of the quality of any product but unfortunately it’s where most teams/leadership losses focus and prioritize features over defects.  
Huge pile of defects is much costlier and time consuming at one go and sometimes the reason for the downfall of the product/company.

We can categories the defects into following categories 
  1. Legacy product running into field for 1+ years and have 100’s ( sometimes 1000’s) of open defects with severity ranging from Critical to Enhancement
  2.  Fresh product but because of some or other reason your defect backlog is increasing and is crossing single digit figure.


1. Legacy product running into field for 1+ years having 100’s ( sometimes 1000’s) of open defects with severity ranging from Critical to Enhancement

     Generally the product over time accumulates a huge pile of defects. Even if ( in best case) severity 1,2,3 are in single/double digits the no of enhancements defects can be in hundred’s. It clearly shows that leadership ( in agile Product owners) are hesitant to take a call and clearly demarcate which we are going to fix (enhance functionality) and which we will not.

Triaging defects should be one of the most important activities that need to be done every week or max every month. The notion of triage involves the prefix “tri”, which means “three”. In medical triage, emergency patients are divided into three classes: those who will probably live, whether they receive treatment or not; those who will likely die, whether they receive treatment or not; and those for whom immediate care may make a difference. Triage is a quick rule of thumb to decide how to allocate limited care resources when the demand is far too high.
How to start with the defect reduction journey
  1. Prioritize the defects based on severity and priority and make it a practice.    
    •   Prioritize them regularly (if possible weekly max monthly). It has to be done by all stakeholders Architects, PO and Managers.  
    •    Create User Stories / Requirements out of enhancement defects, don’t keep them hanging
  2.  Start assigning them to various sprints and chalk out a plan to get to single digit defect count.· 
    •  Don’t make a Five year plan; A Six month plan is the longest you should plan.
    •  If your plan goes beyond it you need to prioritize again and take a call between defects and Features.
 In large teams (3+ scrums) challenge is also how to approach towards fixing legacy defect fixing some ideas
Fine tuning
One/Two Scrum teams concentrating on defect fix others working on features
Features are moving at the expected pace and you will be able to deliver features in market
Team over time will get expertise in defect fix and you may get better quality.

Generally people working on defect fix get demotivated and want to work on features.
 In a huge project generally features per release are concentrated on some areas , Rest of the team will have limited understanding of the product and will get system understanding at much slower pace.

Rotate defect teams every 3-4 sprints, People will get motivation and will build much better cross functional understanding.
Fixed ( one or two) number of days for defect fix every sprint
Every team getting a cross functional understating.
 Team motivation is good.
Most of the complex defects are not solvable in 1-2 days which means either they are dragged over multiple iterations or fix is many times not proper
Take this method only when the product is very small, Have lot of unit tests. Pressure to fix defects in 1-2 days increases chances of collateral and testing very limited scenarios.
Don’t use it for complex projects.
Scrum teams divided module wise and they fixing defects based on their areas
( Junior teams should be taking this approach for initial 1-2 years )
Deep ownership of modules and in addition to that particular defect fix teams are self-driven to refactor code  etc to improve quality.
Defects fix are faster and better quality fixes less chances of collateral
Team working on limited modules, hard to build whole product competency.
Bottlenecks in the system, if there is a surge in particular module defects there may be limited hands to fix the same
Rotate the team in various modules over 3 or 6 months depending on the complexity of the product and learning curve.

 2. Fresh product but because of some or other reason your defect backlog is increasing and is crossing single digit figure.

If you are working on fresh product you need to monitor your defects very closely. If you are not getting defects and they are very limited double check the testing, automation. Induce some Gorilla testing phase ( include some incentives like the team/person who gets most defects goes for a party or so)  and in case you see a defect surge there then something is not right.
In case the defect trend if higher and they not resolving on sprint boundary ie they crossing single digit, it requires immediate action as the software is not done. The PO is accepting US without team achieving the DONE which is the worst thing in Agile.
These are some arguments that you may get from team. They are generally signs of some deeper problems and needs to be addressed.

1.      Defects was caught in last 1-2 days of sprint that why we were not able to fix. ( testing only on last day!!)

One common cause is that the team has a separate testing process that happens after the Sprint. This notion is terribly dangerous. It means that the team can never know whether it is done or not. Therefore it can never ship an increment of done software. But Scrum says we must. Therefore the process is broken.

Another possible reason — the only possible real reason, actually — is that the software was not sufficiently tested during the Sprint. Downstream testing or not, if we test the software well enough, the downstream people won’t find any problems in our code. So we’re not producing done software. Therefore the process is broken.

2.      Defects are from some code developed in earlier sprint we need to change design to accommodate them (design is too fragile).

Don’t easily tolerate ever increasing defect count, at the end of any Sprint. Naturally, we are human, and it will happen from time to time. And every time that it happens, we need to do the same thing, roughly this:
  • Give the new defect to the Product Owner to prioritize into future Sprints;
  • In the Sprint Retrospective, figure out what part of our process allowed the defect to slip through our testing;
  • Improve our process so that that defect, and defects like it, will not slip through.
Typical improvements can be
  • Have acceptance criteria up front: see “definition of ready”;
  • Improve those criteria as indicated to ensure defects like this don’t get through;
  • Slice stories smaller, so that acceptance criteria are easier to write and check;
  • Improve programmer-level testing to provide a second net of tests to prevent problems like this;
  • Use test-driven development to provide programmer-level testing more reliably.

To end with:
The leadership should be focused on keeping the defect count low and constant.
PO needs to prioritize and take calls frequently and if effort required to overhaul/redesign/refactor some modules he/she should be investing in the same.
Old saying “A stitch in time saves Nine”..
Happy Fixing…

No comments:

Post a Comment