Bug Conference Call

My team maintains a suite of applications that are used by over 600 users. With this many users, there are bound to be many trouble tickets submitted. We are normally pretty good at resolving these problems, since maintaining this software is why we get paid. Our customer loses money every time our software does not work correctly. So you can imagine the urgency to fixing bugs quickly. Currently we have conference calls twice a week with the customer to review each and every bug.

Back in the old days, when we had foolishly released buggy software into production, we had many open trouble tickets at a time. That put pressure on the group in our customer organization that oversaw our maintenance. Unfortunately that meant the pressure was applied to our team even more. Every day I would have to spend a good deal of time in my customer's office getting grilled on the progress of every trouble ticket. To this day I regret that upper management in my company did not protect me from such torture. But I digress.

Our customer currently drives the review of the open trouble tickets twice a week. We do not meet physically. However everybody dials in to an AT&T teleconference. I think that many people are actually on the line when we hold these conferences. But mostly the host of this call controls the conference. There is usually one main representative from the users of our software. And there are leads from all the development teams associated with the system. Since we are on top of most of the current problems, these conference calls have been going quite smoothly lately. So well in fact, that I am planning on taking a nice vacation soon. See you later.

Bug Summary

Twice a week we review the list of outstanding trouble tickets with our customers. Our help desk assists with getting the team prepared for this meeting. So the help desk produces a daily list of all open trouble tickets. This list has a minimal set of information like the priority of the problem, which team it is assigned to, which developer is working the problem, etc.

Our customer performs a similar roll up of trouble ticket information into their own spreadsheet format. Their summary is more detailed. When you print it out, it is hard to read the text. So you have to zoom in to read anything.

I have found these aids somewhat beneficial when assessing where we are with all known issues in our applications. However the list is just a start. I have found that you need to use the list to determine which issues you need to do some homework on. If you are not familiar with the problems, and you don't know where we are in the resolution process, having the list by itself is useless.

Somehow I wish we could get a list that is more dynamic. I suspect our defect tracking system can do this. We just have to set it up. Might require generation of a custom report. But the advantage would be that, every time you ran this report, you would have the most up to date information. This could be worth doing.

Trouble Ticket Assignment

Our last defect tracking system was very flexible. You might say it was too flexible. Anybody was allowed to assign a trouble ticket to anybody else. This can in handy often. For example, if I met another team lead, and we both decided a ticket should be transferred to a member of their team, I could just assign the trouble ticket directly to the individual. Now I do not think this flexibility was a property of the bug tracking software we used. I suspect it was due to the way the software was configured by us.

The current defect tracking system we use is more restricted. Only those with team lead authority can assign trouble tickets. This causes pain sometimes. Suppose my team lead is out sick today. Then I need to hunt down somebody with the access if I want a trouble ticket assigned. This is true even if I need the ticket assigned to myself. The result is that the system is often inefficient. And that results in less trouble ticket resolution productivity. Plus it gets developers frustrated.

I wonder how other systems are set up. Perhaps it depends on the size of the project. I imagine that a small team does not need as many restrictions as a larger one. The funny thing is that our project is actually winding down. So we do not have a lot of developers left. But we still have trouble ticket assignment on lock down. It might be time to change the rules in our system. For now I have gained the ability to assign trouble tickets myself. This is because our team lead quit, and I got drafted to take over his duties.


In our old defect tracking system, pretty much anybody could assign any trouble ticket to anybody. I do not think this was a property of the bug tracking software we were using. It was most likely due to the way the system was configured. This flexibility was actually nice to have. If I went to another team lead, and they told me that somebody on their team could take over a trouble ticket, I could just assign the ticket to that team member.

The current defect tracking system we use is more formal. Only team leads and managers can assign trouble tickets. This has some benefits in that there is some control to the madness. But it has its drawbacks. When my team lead is out sick, I have to hunt down somebody who has the access to assign tickets. This is a waste of time that leads to inefficiency. I imagine we could change the rules in our system to give us more freedom.

I wonder what the norm is. Perhaps on smaller projects, things are not on lock down. The funny thing is that our project is winding down and we do not have that many folks left. This is one of the reasons I had to get the authority to assign tickets. Our team leader left the company, and somebody had to take over.