I recently attended an OpenSpace event organized by the Software Association of Oregon (SAO). The event talked about a variety of topics teams encounter while developing in an Agile environment. Here are my notes from the third session, The Bugs We Don't Fix, hosted by Merlyn Albert-Speyer.Initially I thought this discussion was going to be an enumeration of those annoying types of bugs that slip through testing, are reported by customers, and are eventually stored in the huge Indian Jones-like bug warehouse. We started with a short list of bugs that are reported, but ignored:
- Management says the bug is too low priority, and so the development team should ignore it
- The team simply has no time allocated to fix it, so it’s left un-done.
- Bugs that aren’t reported to development. (It’s another discussion to talk about why this happens)
- Someone said “one man's bug is another man's feature.”
- There was a case given where fixing the bug in a graphics engine caused the surrounding system to blow up. The system developers had built the system to accommodate the bug – fixing it caused more problems than leaving it.
- One person cited Joe Yoder’s anti-pattern “the big ball of mud.” Software that’s such a mess it’s too risky to tinker with it.
Then Andrea Callison and Tom Pearson of phTech announced that they don’t have a bug database.
They work off a system that is honest with the users. If the development team simply can’t get the bug fix into the product, or won’t be able to release a patch to fix the bug, they return that bug to the user with an explanation why. They claim that users accept the explanation, appreciate it even. At least the development team has been honest in explaining why the bug won’t be addressed. After the bug is returned to the user (or user representative?) it’s the responsibility of the user to submit the new story to the development team for the next version of the software. As they say "anything that matters will come back" into the new product.
They also have some other interesting ideas
- MMF - minimal marketable feature
- Stories have a warranty period. They'll fix it for free if it's still in warranty (which I’m assuming means within the past couple of sprints)
So, they are in effect saying that once the product has been released, it’s a blank slate. Any new changes will be submitted as new user stories to the development team. They only mentioned in passing that James Shore also has a method for reducing bugs during the sprint – a “no bugs” mentality.
This topic inspired some ScrumMasters who are hoping to get out from under the dead weight of the bug database. Still, while it’s not 100% Agile, my feeling is that the bug database is a useful reference. Additionally some people wondered whether multiple ongoing small projects handled in this manner will eventually lead to a degradation of the product? No one had clear data on this question.
In any case, dropping the bug database is a mind-blowing idea which I’ll have to investigate further.
No comments:
Post a Comment