Should we have a dedicated bug-fixing team?

Similar to the question about the dedicated innovation team, this is another question I’ve been receiving a lot in my coaching sessions, so its answer may also be of interest to more people. In this case, the short answer is NO. This one has no space for an “it depends” kind of answer. Let us dive deeper.

Your code, your bugs

If you build something, you are the only one responsible for its quality. If what you built is not working as expected, you are responsible to fix it. It is that simple. It doesn’t make sense to have a different team to fix bugs made by different people. The people most capable to fix a bug are the people who created the bug. By the way, this is the best incentive for people to create fewer bugs.

What about legacy systems?

In a legacy system, the team inherits a code that they didn’t write. Normally, the people who wrote the code are not in the company anymore. In this case, does it make sense to have a team dedicated to fixing its bugs? Ideally, NO. The legacy system should be the responsibility of one team, who will fix bugs but also work on improving and evolving the legacy system. One very common strategy to deal with a legacy system is the strangling strategy, i.e., to slowly drain the life out of a legacy system by gradually replacing parts of it with a modern implementation.

Another important aspect of legacy systems is that we don’t need to necessarily fix their bugs. Sometimes, fixing a bug in a legacy system can cost a lot, since no one has enough knowledge to debug the system. In some cases, instead of fixing the bug by fixing its root cause, we can apply some workaround fix that does the trick of making the legacy system deliver the expected result. In these cases, we can apply a strategy called “monitor and apply workaround”, i.e., as soon as we figure out a workaround for a certain bug, probably developed outside of the legacy system, we then monitor the undesired behavior and, as soon as the behavior appears, we automatically apply the workaround. It’s the idea that, depending on the general health of the patient, some illnesses are better managed with medicine than with surgery.

Should we dedicate X% of the time to bug correction?

Again, the answer is a plain simple NO. I already explained how important it’s to deliver good quality products:

Any user prefers to use a good quality product that behaves as expected. This is a sine qua non condition to provide a good user experience.

In addition to the user experience, there is another important aspect to consider when we talk about quality and bugs. Whenever someone needs to work on resolving a bug that was found in a digital product, that person needs to stop working on whatever they are currently working on in order to resolve the bug. This is an interruption in the workflow. If that person were able to deliver the software without that bug, they could continue to work on new things without interruption, which would make them more productive.

In this same article, there’s an interesting chart about the number of bugs fixed as a percentage of total deliveries at Conta Azul. It went from 45% to 65%, way more than 20%. When we saw this, we worked on decreasing this percentage, by improving the quality of what we deployed.

In another team, we tracked the percentage of new items deployed and deliberately created OKRs to increase this percentage. In 2 years we were able to go from 50% of new items deployed to 90% of new items deployed:

In my experience, instead of fixing the % of effort dedicated to bug fixing, it’s more productive to focus on creating quality code, without bugs. In order to do that, we should track the percentage of work spent in fixing bugs and actively manage this number to decrease.

Summing up

• Similar to the question about the dedicated innovation team, this is another question I’ve been receiving a lot in my coaching sessions, so its answer may also be of interest to more people. In this case, the short answer is NO. Your code, your bugs.
• If you inherit a legacy system, you’ll have to manage a code you didn’t write. Managing means not only fixing its bugs but also working on improving and evolving the legacy system, which will probably include a strangling strategy to gradually move features from the legacy system to new architecture.
• We should also not use a fixed percentage of time allocated to fixing bugs. It’s more productive to focus on creating quality code, without bugs. In order to do that, we should track the percentage of work spent on fixing bugs and actively manage this number to decrease.

Digital product education, coaching and advisory

I’ve been helping companies bridge the gap between business and technology through education, coaching, and advisory services on digital product development and management. Check here how I can help you and your company.

Newsletter

I write regularly about product management, product development, digital product leadership, and digital transformation. You can receive a notification whenever I publish a new article, without depending on any social network algorithms to notify you! Just subscribe to my newsletter.

Digital Product Management Books

Do you work with digital products? Do you want to know more about how to manage a digital product to increase its chances of success, solve its user’s problems and achieve the company objectives? Check out my Digital Product Management bundle with my 3 books where I share what I learned during my 30+ years of experience in creating and managing digital products:

• Startup Guide: How startups and established companies can create profitable digital products
• Product Management: How to increase the chances of success of your digital product
• Leading Product Development: The art and science of managing product teams

You can also acquire the books individually, by clicking on their titles above.