bugs and credit card debt

I've got two challenges that seem totally unrelated but have some striking parallels. One is credit card debt and the other is bugs on software projects. I have to say the idea of considering a bug list as a debt was first introduced to me in the book "Waltzing with Bears". These days with a new found awareness and sense of fiscal responsibility I wonder if I can leverage that into a better quality practices.
In a "traditional" project teams often work away according to a plan. Very often things don't go as expected and one of the places that suffer is any time planned for bug fixing. Or there is an accepted sentiment that "...they are just bugs and we can fix them at the end after all the hard work is done" we've got to stay on schedule. (In my experience more often than not a significant design flaw or requirements snafu is uncovered in the process of bug fixing and these issues are really harder than building new function. These are dirty problems people tend to avoid unless pushed by an experienced manager or agile mentor. )
Some teams even may have a bug review with the customer or product manager near the very end of the project. These are often difficult as during this review the only choice the customer has is to extend the schedule to fix the bugs or accept the bugs as known issues to be fixed in the next version. Hence they tend to want to avoid these sessions as they only present dilemmas not an opportunity for active decision making.
Some teams consider it OK to build up a large bug count. They also probably consider it OK to keep their charge balance at or near the credit limit. I recently pointed out to my lovely spouse that despite payments of a 100 dollars a month the balance of on a certain credit card had only decreased by 60 dollars in the last three months. In my minds eye that's almost 80 dollars a month wasted that could have spent on other things on tangible goods rather than interest payments.
The team that runs with a big bug back log faces the same waste. Granted there is the "cost of quality" analysis. We are not going to have a perfect product and fix every bug. But if in the course of doing business we make accommodation like:

• Skipping that error when it is reported again and again in the automated test run.
• Talking to one another via speech, email or instant messenger,or what ever about bugs that hang on for months.
• Some one else rediscovering the bug and attempting to report it only for the bug report to be deemed a duplicate.
• Reading past the old bug in the bug report when looking for new bugs. Considering what other bugs might be resolved by and open fix. A large open bug list makes the incremental cost of every new bug larger as the database grows.
• Writing up the bug as a known issue for the read me or release notes when we finally complete the project and didn't get time to resolve it.
• Not discovering other bugs that are masked by the bug due to people avoiding that functional area where the known bug was reported.

All of these things sap the productive energy of the project team like the 80 dollars a month lost in my family budget.

How do I cope.

1. Be vigilant and visible with test results. Keep them visible and on going.
2. Raise the threshold for what is considered a bug. Sure it would have been better if it worked that way.... but that wasn't in the user story and never discussed till now. Can we plausibly just make that part of user story backlog.
3. As part of the post sprint review, consider the new bugs that are still outstanding. Decide now if we can ship or put the product into production with these bugs. Don't be a fence sitter. It is OK to have up to 20% as "maybes" but if the customer/product manager can't accept certain bugs recently introduced then they get fixed before new user stories are added. This is part of what it means for each sprint to produce a potentially shippable product.
4. Remind the team what a crunch they use to have at the end of other projects. Use that as a motivator to not put things off and not be overly optimistic.

If I'm not running my credit card debt near the limit. I can be agile and make a decision to take advantage of great sale on new patio furniture or I can redo the basement the way I'd really like to after suffering from a flood. If I'm agile I pay as I go and I have choices. I have head room to respond when the unexpected happens. I can take advantage of business opportunities arise because I'm always just weeks, not months away from shipping or going into production.