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

 

Approach	Pros	Cons	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…

Making Agile successful in not so "Agile supportive" environment

Environment is must for Agile or any other framework to succeed. But there can be many deterrents which may hinder successful adoption of Agile. To start with 

• Not having experienced team because of some of or other organizational constraints. 
• Leadership not committed to Agile, Just want team to work in Agile way.
•  Not having an awesome test infrastructure.

Not having experienced team because of some  or other organizational constraints   ( Team having high no of freshers and junior folks )  

Everything at the end of day is business and most of the leadership gets influenced by the account books. Either they don’t want to invest or constrained by budget to start Agile journey with junior team. Agile is framework which tries to simulate software engineering to a highly efficient machinery and it follows the same principles, GIGO ( garbage in garbage out) if you don’t invest in team and don’t hire the right folks you won’t be seeing the desired output.

However that doesn’t mean that a junior team cannot succeed, they may struggle for initial couple of months or may be 1-2 years and then can start performing awesomely. Most of the changes Agile suggest requires lot of unlearning and then learning new things eg shifting from most of manual testing to automated testing,learning to produce and deliver small every sprint etc  which may come as a silver lining with junior team as they don't have to unlearn anything.

Here are some of the things that you can try  to lead a team with junior folks successful.

• Train them rigorously and have dedicated mentors available every moment and share knowledge between members every week. A mentor should not be mentoring more that 3 folks at a time and his assignments should be decreased by  at least 50% as he will be investing more than 50% time in mentoring folks.

• Create a safety net and encourage then to share their mistakes every day and try to solve them instead of ignoring or asking them to work on it without providing suitable support.  

• Leadership spending at least ( 5-8 hours weekly ) with them to boost motivation and give them a feeling  somebody is there don’t worry.  New folks should be giving demos,trainings etc every week which will help leadership in accessing how they are progressing and it helps in grooming the new folks.

• Listen to grapevines every moment – people have tendency to hide things encourage them to share the failure and try to turn it into success.
• Have patience with the team , Dont expect them to deliver in a day.  Patience doesn't mean below standard work is acceptable, Be ready to change the entire team if you don't see positive movement every week.

2. Leadership not committed to Agile, Just want team to work in Agile way.

Leadership is the biggest bottleneck in adopting agile. Strong commitment is required from Leadership to make Agile successful. Movement to Agile means at least two fold work for leadership, Stretching much more than the team,  Be available 24*7 to the team etc.

Some signs that leadership not committed in Agile

a)      Leadership ( managers, scrum master, architects, product owner, sponsor) not aware of Agile are not investing in trainings ,ramp up. They are just asking everyday about team status not aware what is happening . They need to be aware of daily progress and that should not come from status meetings.

b)      Leadership not taking care of their roles and responsibility just want some delivery very sprint.

• Product owner is not part of standups, not working with team , not aware of what problems team is facing on day to day basis. PO should be working with team and should be aware where team is stuck etc. He should be team face during leadership and should be driving the release plan etc.
• Scrum master just playing a passive role in standups , planning etc. He /She is not able to understand what is team doing where are they really stuck, do they need help. People are generally shy to say I need help SM should be able to gauge it on a day to day basis and should get the appropriate help asap
• Managers are still the typical waterfall manager that just want the status and not engaging the team in understanding the problems and solving the same.
• Sponsor/PO are not changing the priorities/scope as the team is progressing. They just want team to deliver what they think of. Instead of throwing the EPIC to team that I want XYZ epic delivered by XX date

It should be more of gauging the team velocity and prioritizing the features as per that.

Agile can only succeed when leadership is committed to it and is ready to take atleast twice the work load from team. Leadership is generally the biggest impediment in moving to agile as they have to be lot more patient , solve lot more problems every day and are the once
The only way to get some good coaching for the leadership and is possible  hire a full time coach for initial months. Leadership is the biggest bottleneck for enabling agile and a very strong leader is required to step in to move the leadership towards the agile path

3. Not having an awesome/any automated test infrastructure.

Agile means delivery sprint ( max 2-3 weeks, people are successfully executing 1 week sprint also) and with  manual testing you cannot do continuous development and delivery.

•  Start Small , Monitor everything : Automate UT cases , If there is lot of legacy for every new code written start writing automated cases. It is hard and team will try to push back on the account of time etc , somebody should be there to believe in it and continue to motivate team to write UT cases for every line of code change be it a defect fix or a feature development.

           Have them running on a daily basis and any failure need to be fixed on highest priority.

• Build End to End automated usecases running after every build : For a legacy product it will be hard to write UT cases and coverage will be pretty low yielding low value. In parallel start building some end to end use cases. Identify your top usecases and start automating them.  They should be running on a daily basis

Soon you will start seeing some value out of it when due to some bad fix regressions breaks etc and it will also help you cut the regression time at the end of release.