You've addressed the why behind this process but not the how. There always will be dissenters who refuse to take this action and will make up reasons why they need all their bugs floating around. How do you address this? And how do you get to the root of why engineering leaders are often very afraid to take this step? Most of them aren't forthcoming about their real reasons. Often it's just fear.
I touched on the how (triage one last time and commit to fixing anything you aren't closing).
But the bigger issue you're noting is that people don't like change, or doing something they think is "risky". A starting step could be to close every bug older than n months. You could even make n a big number, but once nothing bad happens, you can reduce n until your closer to "fix it or forget it". A good alternate for n months is a target Average Bug Age.
That said, the good engineering leaders I know already work off of a zero bug backlog - so the challenge is trying to get a mediocre or bad engineering leader to make good choices - which is always one of the big challenges in organizational change.
First of all, I agree. When faced with a bug, we want to decide once whether to fix it and when. Any decision other than Now and Never is creating more work for someone.
Still, there are some (possibly) valid reasons for keeping a database of bugs. I've been part of the following scenarios. I'm interested in what people think about them.
- I just found four bugs. I'm going to fix one now and make sure I don't forget what the others were. Maybe I need my teammate to help with a couple.
- A customer just found a bug in something we're not working on now. I don't want to context-switch but want to fix it as soon as we get around to working on that product.
- We have a large group and people keep reporting a bug we decided not to fix. Don't they know we decided not to fix it?
- We're not sure whether to fix this one or not. We need more information to decide. I wonder if others have seen the same problem...
- We have a process for fixing bugs. It's changed over time. I wonder how good it is and what we could do differently to improve.
- I want to show my manager what I've been spending my time on.
I really enjoyed the piece about ABA. If I am reading it correctly, the longer a bug has been discovered and NOT fixed, the more likely it won't be remembered, prioritized, and fixed.
Sometimes this feels very similar to my experience lately with cleanup tasks at the end of a project, or in other words, tech debt.
Teams I used to be on (as a quality engineer) required each sprint to contain at least two bugs or tech debt items. Other teams I have been on used the "delete after N days, months, years" mentality.
As I currently straddle the wall I hate to admit still exists between quality and development at times (I changed roles from Staff QE to Android Engineer this year), I am trying to bridge that gap and demolish that wall. This is an interesting problem to me and how to make it work on my team is a tough question.
Mental muscle memory is hard to get people to push through sometimes...
I started a QA team for a small company. last year. We don't have a standing bug backlog.
The main reason for this is that we're a QA team not a DA team, as in Defect Assurance.
Our focus is on preventing bugs
by advertising upfront to the team what will be tested. We want to keep test cycles fast, reliable and passing 100%.
You've addressed the why behind this process but not the how. There always will be dissenters who refuse to take this action and will make up reasons why they need all their bugs floating around. How do you address this? And how do you get to the root of why engineering leaders are often very afraid to take this step? Most of them aren't forthcoming about their real reasons. Often it's just fear.
I touched on the how (triage one last time and commit to fixing anything you aren't closing).
But the bigger issue you're noting is that people don't like change, or doing something they think is "risky". A starting step could be to close every bug older than n months. You could even make n a big number, but once nothing bad happens, you can reduce n until your closer to "fix it or forget it". A good alternate for n months is a target Average Bug Age.
That said, the good engineering leaders I know already work off of a zero bug backlog - so the challenge is trying to get a mediocre or bad engineering leader to make good choices - which is always one of the big challenges in organizational change.
See also this blog post: https://www.mitchlacey.com/blog/managing-bugs-in-scrum-and-agile-projects/
First of all, I agree. When faced with a bug, we want to decide once whether to fix it and when. Any decision other than Now and Never is creating more work for someone.
Still, there are some (possibly) valid reasons for keeping a database of bugs. I've been part of the following scenarios. I'm interested in what people think about them.
- I just found four bugs. I'm going to fix one now and make sure I don't forget what the others were. Maybe I need my teammate to help with a couple.
- A customer just found a bug in something we're not working on now. I don't want to context-switch but want to fix it as soon as we get around to working on that product.
- We have a large group and people keep reporting a bug we decided not to fix. Don't they know we decided not to fix it?
- We're not sure whether to fix this one or not. We need more information to decide. I wonder if others have seen the same problem...
- We have a process for fixing bugs. It's changed over time. I wonder how good it is and what we could do differently to improve.
- I want to show my manager what I've been spending my time on.
I really enjoyed the piece about ABA. If I am reading it correctly, the longer a bug has been discovered and NOT fixed, the more likely it won't be remembered, prioritized, and fixed.
Sometimes this feels very similar to my experience lately with cleanup tasks at the end of a project, or in other words, tech debt.
Teams I used to be on (as a quality engineer) required each sprint to contain at least two bugs or tech debt items. Other teams I have been on used the "delete after N days, months, years" mentality.
As I currently straddle the wall I hate to admit still exists between quality and development at times (I changed roles from Staff QE to Android Engineer this year), I am trying to bridge that gap and demolish that wall. This is an interesting problem to me and how to make it work on my team is a tough question.
Mental muscle memory is hard to get people to push through sometimes...