Sometimes it takes another person to connect the dots for you, and it wasn't until I saw Arlo Belshee deliver his #BugsZero talk at Agile Singapore 2016 that something changed. Up until that point, making bugs an avoidable occurrence was a light with a dimmer switch at about 50%; now it was fully on. 

For a number of years, up until that point, I'd worked on teams that had very few bugs in their production environment, few enough per year to be countable on one hand. To get to this point, we had to adopt behavior driven development and worked closely with our customer. We used Continuous Integration and Delivery and avoided long-running feature branches like a very contagious disease.

Previously, we had identified a great deal of technical debt in our system, but by using a Technical Debt Heatmap, we had made it visible. We had then managed to slash out technical debt by regularly tackling it every Sprint, either as part of user story when making changes in that area or by deliberately going on time-boxed bug hunting missions.

It wasn't until we started pair-programming in earnest that things really began to change for us. With the two minds are better than one philosophy, we began to smash it out of the park. Pair-programming isn't a compromise regarding productivity. And it certainly doesn't reflect a programmer's ability to do their job. Pairing is powerful; it shortens feedback loops, makes solving complex problems universally easier, creates a disciplined approach, and produces code that is more likely to be simple and bug-free.

We didn't just pair with other programmers, we also paired with our Product Owner and/or subject matter experts. Having our Product Owner co-located with us significantly improved our feedback loops and decision-making process. If we can't get our Product Owner to co-locate with us, we should consider going to co-locate with our Product Owner. It's amazing what we can learn by osmosis when sitting in our customer's space.

Once we'd become well-practiced at pairing and understood its benefits well, taking the next step to mob programming seemed more logical than anything. We naturally fell to working this way on a number of occasions. 

The long-term effect of this level of quality is significant for any software application, making bugs a thing of the past allows us to focus on new features and enhancements. Plus, getting there isn't as hard as we think it might be, it just requires a mindset shift to realize that bug reports are feedback telling us something isn't right. If we incorporate that feedback, analyze its root cause and action ideas to stop these types of bugs from occurring, we will lessen the chances of this pattern repeating. As we continuously improve our approach, we will start to throttle the number of bugs that we receive to zero. 

In the next chapter, we'll look at a different form of continuous improvement; how we can become the best Agile team member that we can be.