Bug Busting: Unleashing the Power of Context-Aware Strategies for Efficient Management

When it comes to discussing software, one topic that often gets avoided is bugs. It seems that no one likes to engage in conversations about this issue, which can cause frustration and get in the way of the perfect software. Perhaps it’s because bugs represent flaws or imperfections in the well-designed code. Additionally, discussing bugs might draw attention to potential vulnerabilities or weaknesses in a system, which can be uncomfortable for developers and users alike. Still, acknowledging and addressing bugs is essential to software development and maintenance, and this article shows the importance of considering the developers’ context-switching cost when prioritizing multiple bugs.

As a manager, it’s easier to prioritize the backlog when tackling just a few bugs because we can add them to the team cadence. But that’s not always the case, sometimes the backlog is bigger than we’d hoped for due to a couple of different reasons such as:

• Prioritizing functional features over addressing all potential issues when working with a tight deadline;
• Lack of automated tests, making us rely on manual tests that are prone to human error;
• When an MVP (Minimum Viable Product) becomes the main feature, and we don’t correct the technical debts that can pop up later as bugs;

These are just a few examples, but they can increase the likelihood of bugs slipping through.

At Syngenta, we have successfully overcome this phase, and our products consistently maintain high-quality standards. However, it is important to acknowledge that way back when, some events, like Bughunts — one of our quality control activities — increased backlog. In your company, are bug-hunting sessions a part of your routine? First, what is it?

Bug hunting is a fun and engaging activity in which we get our workers together to simulate end-user scenarios, gaining valuable insight into how clients use the product. The primary objective is to identify opportunities for improvement and potential bugs. Typically, two main scenarios can unfold during this event.

1) If no issues come up, it indicates that the software is of good quality. However, it’s important to recognize that achieving perfection is unlikely, and bugs may go unnoticed until encountered by end-users.

2) On the other hand, if bugs are found, it presents a great opportunity to rectify them before clients notice. This discovery should also trigger a reevaluation of the quality processes during the development phase, raising the question of how to improve to catch these issues earlier.

In your perspective, which of these two scenarios is more concerning?

I see the first scenario as more worrisome because it implies that potential problems may have gone unnoticed due to various factors. These factors can range from participants lacking interest in thoroughly exploring the product to a lack of understanding about how customers use it. Consequently, only the main routes are tested, leaving room for undiscovered issues. This leaves the customer with the inconvenience of identifying and reporting, which is far from ideal, and you should at least double-check the quality processes in place to guarantee that your software is really that great.

This article isn’t about how to find bugs but rather what to do with the ones you find, which is the second scenario. So, great! Let´s get to it! Now, which bug should we prioritize?

According to the literature, we have some possibilities going from the PO‘s feelings to the direct impact on the client. A recurring suggestion is to address the ones with the highest cost-of-delay¹ first while leaving less critical issues, such as layout changes or text sequence adjustments, for later. Once prioritized, their resolution can be planned within sprints or your Kanban backlog. Alternatively, you can consider organizing a dedicated event, like a Bugsmash, where teams focus on solving as many problems as possible within a set period.

However, I have mixed feelings about this approach. The literature² emphasizes the importance of avoiding wasted time and context-switching when we are developing a feature. Yet, when it comes to correcting the problems of the features, we often disregard that each one represents a specific context. Thus, we ask our developers to solve issues scattered across different features, services, and even languages, switching back and forth throughout the day. For example, in the image below, the manager asks John to solve Bug A1 in feature K(purple card) in React Native, B1 in feature P(pink cards) in Kotlin, and Bug C1 in feature Z(grey cards) in React web. I have seen it happen, and you might too.

Meanwhile, your backlog for feature P consists of [B1, B2, B3, B4], closely related in context because they happen in the same feature with close user cases and the same language. But they ended up getting mixed up in the prioritization and addressed in different moments due to evaluating just the cost of not resolving them for the client instead of also considering the cost of your developers switching across the code.

This difficulty led me to propose a change in our bug management approach. I suggested grouping and solving bugs within the same affected feature in sequence, expanding the view of context-switching to consider all the issues in one feature as being in one context. In other words, when working on feature P or starting to resolve bug B1, we address all bugs linked to that particular context. Something like this:

This helps reduce the cost of developers going back and forth throughout the code because of different bugs in very different features. This shift in mindset was tested during a Bugsmash event using the possibility of linking issues by “Relates to” in Jira. During this test, we got rid of twice as many bugs than before, which accounted for more than half of the backlog in just one to two days, while ensuring that no critical items were left behind.

In conclusion, the idea is to also take into account the cost of switching from feature to feature when thinking about backlog prioritization. So, I would like to highlight the following key takeaways:

• As managers, we are responsible for thinking strategically and finding intelligent solutions to problems while minimizing potential team overload.
• It is important to remember that not everything must strictly adhere to predefined guidelines. Adaptation to your specific context often plays a crucial role, so consider the unique circumstances of your situation.
• By fostering a mindset of flexibility and adaptability, we can find innovative solutions that align with our specific needs and environments.

Let’s continue exploring ways to enhance our bug resolution processes and drive continuous improvement within our teams. So, if the proposed approach resonates with you and can bring benefits, feel free to use it. If you have other ideas or suggestions though, I’ll be happy to hear from you. Good luck and happy bug-busting.

¹ If you want to read more about the Cost of Delay: https://community.atlassian.com/t5/App-Central/Risk-Reduction-Vs-Time-Criticality-metrics-difference-in-WSJF/ba-p/2149303

² You can read more about it here: https://www.atlassian.com/agile/kanban/wip-limits or here: https://www.scrum.org/resources/blog/financial-cost-task-switching)