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.
