I had the pleasure to work on a very large programme of work for the past two years and I witnessed how programme has changed its structure for handling bugs. Therefore I am sharing such result on this blog post.

Very Large Agile project – year 1

200 engineers (Devs and QAs):

–        10 functional teams with 18 people each

–        1 maintenance (bug killer) team with 20 people

An average of 300 open bugs

Weekly meetings for prioritizing bugs

Bug Killer team is fully allocated and has the challenging goal of reducing the number of open bugs.

Bug Killer team attrition rate was higher than the  functional teams.

Despite of the best team effort, the average of open bugs never reduced.

Very Large Agile project – year 2

200 engineers (Devs and QAs):

–        10 functional teams with 20 people each

Month 1: 300 open bugs

Month 2: 280 open bugs

Month 3: 260 open bugs

Month N: an average of 20 bugs

Bugs are directed to the functional team closely related to the bug functional area.

Test coverage and test effectiveness increased over time.

Developers got closer to the operations team, and improved tools for chasing bugs.

Should I have a separate team for handling bugs?

No, not really. At least this was my experience. I have to confess that I started on year one and was very comfortable with the separate maintenance team model. I and other programme  leaders took the challenge of reducing the average bug numbers.  As an experiment, we tried to stay without a separate maintenance team for two months. We never went back to the old model.