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
- 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
- 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
- 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
- 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
|
|||
Fixed ( one or two) number of days
for defect fix every sprint
|
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 )
|
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