Fix your process, don’t manage it

There are lots of bug/issue tracking systems in existence.  For example, Wikipedia’s comparison of bug and issue tracking software scrolls to 15 full screens on my computer.  If you look at that list, in addition to licensing, system requirements, etc., one way these apps are classified is whether or not they support a customizable workflow.  Many of them are called out for features such as “extensive workflow”.

I have no doubt that a customizable workflow is important.  But I think it’s a smell when heavy workflow customization is an important feature of bug tracking software.  These features are only really important when you’re using the tool to manage a complex process.  Rather than finding something to help you manage a complex process, simplify it.

Let’s consider a fairly typical workflow.

1. A defect or feature request comes in.  It is marked as “high priority”, as they always are.
2. Someone investigates it and either addresses it, rejects it, or validates it.
3. A fight ensues over whether it’s a defect or new feature.
4. Someone decides how to schedule this – slate it for a future release, fix it immediately, or leave it open indefinitely?
5. A developer gets assigned to work on it.
6. The developer tries to fit this in with the fifteen other things he’s working on, and ultimately either makes his own decision or asks his boss, who tells him that everything is priority 1.
7. The developer investigates the issue, changes the code, tests it, commits it, and gets on to the remaining fifteen priority 1 issues.
8. A tester picks up the change, looks at the ticket, comes up with his interpretation of the need, and tests the developers code.
9. The documentation specialist picks up the change, looks at the ticket, comes up with his interpretation, writes a document, calls the developers, rewrites the document.
10. Repeat for the next issue.

Keep in mind, even this is a fairly simple workflow.  We didn’t get into UAT, performance testing, integration, build and release management, etc.  But it’s still far too complex.

Along the way, the issue tracking tool can gather metrics on how long the issue spent in a variety of states, perform automated routing and resolution based on many factors, and spam the world every time the issue’s status changes.

Instead of finding a suitable configurable and sophisticated tool to manage this process, focus on simplifying it.  Treat exceptions as exceptional, and don’t worry about a process and tool that can handle every imaginable scenario, regardless how rare.  Use a simple process.  Remember that code is written, tested, and documented by actual people, and help them work together.  Hold them all responsible for the results.