What bug tracking system should we use is the wrong question to ask

Some times when you are kicking off new project you will hear people debate whether we should be using this tool or that. This could be everything which IDE is better (a classic) to which type of wiki to install.

Recently I witnessed a passionate discussion between the developers and QA over which tool they would use for bug tracking.

This is the wrong question to ask.

Instead of asking themselves how they are going to track bugs, teams should be asking themselves what they can do to avoid having any in the first place.

* Make the goal of your project not to require a bug tracking system.

* Don’t accept that bugs are going to be a part of your project.

* Make yours the first bug free project your company has seen.

That way no one will care how you track bugs because you won’t have any to track.

Then you can take your savings and enjoy an evening (or afternoon) at the pub instead.

Circling the wagons

If you’ve ever watched old Westerns, you’ve probably noticed that whenever the homesteaders get in trouble, they bring everyone together and circle the wagons.

Software projects do this too. Only usually, it’s when things are about to hit the fan. Only then do teams:

* bring everyone together
* cut off all outside distractions
* get them the resources they need
* prioritize and focus
* deliver something fast
* ask everyone else to get out of the way

Why wait till your project is in trouble?

Why not start your next project with the wagons already circled instead?

Co-locate your team from the start.
Talk to your customer instead of relying on written words.
Start with the most important stuff, and don’t sweat the rest till you get there.
Deliver something of value fast. How about in a week?

Agile gets much of its power from circling the wagons at the start of the project.

Not because they are necessarily in trouble. More because they want to stay out of it.