Finding holes in the process

Ever done a process review? It's one of those things that gets done, formally or informally, when a software company is trying to grow from small to large. In my experience, the most likely way it happens is, a manager or two or three get together and decide on some tool that they like, or have used before, and that they think would be useful for source control, or bug tracking, or building, and then they pass the edict down to the programmers: "Okay guys, from now on we use OnTime for all bug reports." The programmers nod politely and get on with the business at hand, and may even enter a few things into OnTime if they remember.

Ina few months, the managers realize that nobody's paying much attention to OnTime, and they go and bug the programmers. "Hey guys, let's use this bug tracker, ok? We paid a lot of money for it." The programmers start entering a few more things into OnTime, if they remember, but they grumble about it. Why waste time on this busywork, they think? The programmers aren't happy, the managers aren't happy, and communication is breaking down badly.

How do you avoid this? Don't just nod politely when the tool is introduced; attack it. Of course, if it's a tool you've not used before, you won't be able to see what any weaknesses are. But try to understand the workflow. Bug the manager until he makes it clear for you. He'll probably end up saying something like "Each bug goes from Entered to Accepted to Fixed to Tested to Released".

That's a pretty standard workflow. But now you can start to poke holes in it. Has anyone thought through the failure steps?

"Okay, so what if it's a bogus bug? I'm not going to accept it then."

"Hmm, that's true. Maybe we should add a Rejected state."

"Sounds good. What if Testing fails?"

"Umm, the test group should just set it back to Entered, and it can cycle through again."

"Okay, but what if that happens the week before the release? Do we need to put off the release until the bug gets fixed? Or can we hold off on it until the next release?"

"Ummm..."

Processes tend to break down around the failure points. If every bug took the path Find/Fix/Test/Release, software development would be very simple, and the workflow would be completely linear. But on every step of the line, it needs to be clear what will happen on a failure. Does it go back to previous step? Farther? Can we ignore it? A clear workflow with known failure paths will go a long way towards making any software project smoother.