David Caulfield

A Framework to Manage Team Bugs

The Problem

If you lead a software team, then a significant part of your tasks will involve some sort of bug fixing or support for other teams. In particular, if your team works on a product used by a lot of customers, you can expect to sped 10% or more of your team's time fixing bugs from your customers.

When it comes to bug fixing, your customers expect a high standard from your team, so you should expect the same from them. As part of your team lead duties, you need to look for opportunities to reduce the team's work as much as possible. In my case, I discovered that the team spent longer trying to understand a bug's description than actually fixing it.

A poorly written bug means your team is getting distracted trying to figure out what the bug means instead of fixing it. Distraction leads to context switching leads to frustration leads to slower completion of work. And there are few things more distracting than a badly written bug.

Rather than trying to fix the bug, a lot of time is wasted trying to understand the bug's context and the steps leading up to the incident. In the end, your team practically writes the bad bug themselves!

This was the case for the product I worked on a few years ago. Although the product was relatively mature, there was very little structure around the processes used to make the product better.

A quick search through the bugs history showed poorly written one-liner bugs marked as closed with no explanation or code fix attached. Clearly, the developers were conversing directly with the stakeholders via email and not attaching the information afterwards.

When my team joined the product, the most frustrating part of our days was solving bug tickets which had no useful information attached. Furthermore, we had no method of prioritising our bugs against our current list of tasks - the loudest person won the priority.

After 2 months of this and identifying it as a major pain point in our retros, we decided to fix our bug process.

The Bug Template

Our bug template was revolutionary to our workflow. First of all, by filling in a template, the bug author was required to think about their problem.

What did I do leading up to this?
How could this have happened?

Occasionally, the bug author even figured out the solution by themselves while filling in the template.

Secondly, the bug ticket required some effort to create. A good rule we discovered was if you make it easy for someone to do something, they will do it. In this case, if you make it easy to create bad bugs, then bad bugs will get created.

By putting a list of questions to answer in the template, the author is less inclined to raise trivial questions since it would be quicker to figure it out themselves. Most importantly, you won't be left with some 'critical' bugs that just have a one-liner description.

Bug Logging Template
 
1  OVERVIEW
------------------------------------------------------------
1.1. Technical problem description
------------------------------------------------------------
Give an overview of your problem.

------------------------------------------------------------
1.2. Product impact
------------------------------------------------------------
What part of the product/project/system is this impacting?


------------------------------------------------------------
1.3. Conditions
------------------------------------------------------------
Are there any unique parameters or conditions you think are relevant? 

 
2   AFTER ANALYSIS
------------------------------------------------------------
2.1. Software version
------------------------------------------------------------
  What version of software did you find this in?
 
------------------------------------------------------------
2.2. Steps to Reproduce Fault (**Mandatory**)
------------------------------------------------------------
Please give exact steps on house we can reproduce this issue.
Give specific commands if necessary.
Attach screenshots if necessary.
 
 
------------------------------------------------------------
2.3. Logs
------------------------------------------------------------
Attach relevant log files

 
------------------------------------------------------------
2.4. Frequency of fault
------------------------------------------------------------
When / how often does this occur?

 
------------------------------------------------------------
2.5. Expected result
------------------------------------------------------------
What do you expect should happen?

------------------------------------------------------------
2.6. Actual result
------------------------------------------------------------
What actually happened instead?
 
3   REACTION
------------------------------------------------------------
3.1. System restore
------------------------------------------------------------
Did you take any steps to restore the system?

 
 
------------------------------------------------------------
3.2. Temporary fix / Workaround
------------------------------------------------------------
Did you find a solution or workaround?

Whenever you see a badly written bug, attach the following to the comments section:

"Hi Sam, We need more information to begin working on this quickly. Please fill out this template with relevant details." Then paste in the above template.

Prioritise Your Bugs

As the team lead, each day you should work with your team to identify the highest priority work. If critical bugs are coming in, you may need to down-prioritise other tasks.

I have a general rule I use to decide what to prioritise:

"If it hurts, put it first."

If the ticket is a big customer or is likely to cause your team embarrassment, then get it closed out asap. It is important to keep the pressure off your team as much as possible, so getting painful bugs closed quickly can give them the head space they need.

Furthermore, there is little point in having your team work on edge case bugs that were accidentally found in-house when there are customers shouting for a fix on another bug.

Argue Against the Bug

Before you assign any bug to your team, make sure it is something suitable for your team to work on. Don't confuse a 'loud' bug with a high priority bug. Very often, there are stakeholders that create tickets and need them worked on immediately. Always question the validity of their priority.

Firstly, you don't want to be the 'pushover team' that will hop on tickets when someone shouts loud enough. It is very beneficial to your team if you can disagree against tickets with the hope of either delaying their priority (especially if your have a large backlog) or get it moved to a more relevant team.

To argue against the bug, ask a few simple questions:

  • Is this bug for your team?
  • Is there enough info for someone to begin working on it?
  • What level of expertise is required here (senior / junior)?

By asking some basic questions, your team gets more context to the ticket and can empathise with the ticket author. If the ticket does not already have your template, make sure you attach it and ask the author to fill it out.

Emails are not Bugs!

As the team lead, I am often pulled into an email chain with stakeholders such as QA or customer support teams with questions such as:

  • "David - Can you get someone to have a look at these logs?"
  • "David - Can we secure someone from your team to look at this?"
  • "David - It is critical that we fix this bug by Monday. Who is available to work over the weekend?"

Do not take requests like this. My response is always the same:

  • "I'm sure we can help. Please raise a ticket with all relevant details so that we can track this."

Without a ticket, your team don't know where to attach their information or ask more questions. Moreover, if you revisit the bug in the future, without a ticket there is nothing for you to reference.


0 kudos