Mar 9, 2009 / Agile Bug Management Anti-Patterns
10 commentsAgile development books often skip bug management practice. However, there are several dangerous misunderstandings (anti-patterns) that are quite common. It is better to recognize the problem early and fight to win. Here are three common bug management anti-patterns in a development process.
Bug fixing phase inside iteration
Symptom: You have several days at the end of iteration fully dedicated to bug fixing.
If you have a bug fixing phase inside an iteration, you have mini-waterfall in each iteration, which is not a very good idea (in agile we blame waterfall for good reason, don’t we?). Story should be tested as soon as it is completed.
Bug fixing iteration
Symptom: You run several iterations with almost no or little bug fixing and then one (or even two!) iterations fully dedicated to bug fixing.
Bug fixing iterations kill your iterative development. It is even worse than mini-waterfall. Such iterations increase your work in progress dramatically. You have nothing done during several iterations before bug fixing iteration. You have nothing to ship. Moreover, bug fixing iterations reduce motivation, people don't like to fix bugs for 2 weeks or for the whole month.
No “Zero open bugs” rule in user story’s Definition of Done
Symptom: You have open bugs in a completed iteration.
You may have decided that some bugs discovered during story development are unimportant and can be postponed to future releases/iterations. This is a very dangerous practice that leads to bugs accumulation. Moreover, it may be a reason for Bug fixing iteration (see above). The best strategy is to have “Zero open bugs” rule in Definition of Done for user story.
Labels: agile, bug management, process, qa
posted by Michael Dubakov @ 3:29 PM
10 Comments:
Symptom: You have open bugs in a completed iteration.
What do you suggest you do in this situation? Prolong the iteration?
If you have iterations, it is required to not include user story into the iteration and move it to the next iteration. It should not be released with open bugs.
If you do not have iterations, just fix all the bugs and mark it as done and ready for release.
Heh, this must be nice at places where you have full control of everything. However, most of the rest of us aren't so lucky, so there's no way this could possibly work for most teams.
For one thing, most teams already have a backlog of hundreds, if not thousands of bugs; the fantasy of "just don't create new bugs" fails to address that. It also fails to address bugs you miss; even if you commit to "zero bugs", what do you do when a bug is discovered two weeks after your "bug-free" release?
And on top of that, how do you define "bug"? For instance, what if your customer can't find a feature in your app/site: Do you devote programming time to adding more links to that feature? Do you write a tutorial and add it to your "Help" page? Do you assume the customer is an idiot and change nothing? And then regardless of what you do, what do you do when another customer has the same problem in a month?
Such bugs are very different from the clear and obvious "your app isn't working the way you intended it to" bugs, and often times fixing them makes little or no business sense at all. At the same time, there's no magic way to separate the bugs that make business sense to fix and bugs that don't. What most teams then do is prioritize their backlog of bugs, and work through them on their "bug fixing" time, whenever that may be. Your anti-patterns demonize both backlogs and bug-fixing-time, but don't supply any explanation of what to replace them with.
Any sort of bug strategy would need to address all of the above and more; otherwise it's not a strategy at all, just some guy saying "Hey, I fix everything I consider to be a bug, aren't I great?" And if there's no strategy behind them, then anti-patterns are just one person's pet peeves; for an anti-pattern to be meaningful, there has to be a (presumably productive/useful) pattern that it conflicts with, and I see no such pattern here.
"Zero open bugs" would also be difficult to implement in organizations where the QA cycle by a separate team occurs after the full iteration. Bug fixing would always occur at the end of an interation.
@Jeremy
Hmm, in general the goal of this post was to show what problems exist.
It does not provide any solution, but your comments focuses on solutions more.
I will make several posts that address that. Anyway, some comments.
>>It also fails to address bugs you miss; even if you commit to "zero bugs", what do you do when a bug is discovered two weeks after your "bug-free" release?
There is no such a thing as "zero-bugs" release. In 99% of cases you WILL have bugs in production.
>>At the same time, there's no magic way to separate the bugs that make business sense to fix and bugs that don't.
Yes, there is. Product Owner should do this job. There are several strategies to deal with bugs found in productions.
Most common way is to ask Product Owner.
>>Such bugs are very different from the clear and obvious "your app isn't working the way you intended it to" bugs
You've provided correct bug definition here. Otherwise it is an enhancement (user story or feature). We all know how to deal with user stories.
@John
Yes. Absolutely. Such organizations have this anti-pattern and serious problems with development process as I may suspect.
Agile is crap and developers are useless.
@ anonymous
We shipped our product with over 1,000 regressions as we were doing big bang integration at the end of a Waterfall iteration. We have since moved to a product called Accurev and bug counts themselves are down dramatically. Agile and continuous integration with good unit testing is also a big plus. I can't imagine going back to the old way.
Signed,
Useless
Not having testers inside the iteration is a smell.
@Nilanjan
Absolutely. Testing should start right after User story completion.
Post a Comment
<< Home