Zero Bug Policy: Experience from My Porsche and How to Start
Software products are rarely ever finished. Building and releasing new features and functionalities are an essential part of a developer’s job. Less rewarding, more tedious and yet equally important is working on bug-fixes. In fact, developers are constantly looking at existing code to identify potential room for improvements and solve issues before they impact customers. At Porsche, we have recently adopted a zero-bug policy for our My Porsche teams. It is an excellent strategy for dealing with bugs. In the following, Janos Ansel, Release Train Engineer, will explain why this is the case.
What is meant with zero-bug policy?
Zero bugs is predicated upon one principle: eliminating all bugs. In reality, we all know bug-free code and software production is impossible. So, what does zero bug actually mean, then? It means that the known bugs or defects are zero.
If you’re like us at Porsche, you’re obsessed with the delivery of premium products and services, regardless of whether they are hardware or software based. In order to further improve the quality of our digital products and better meet customer requirements, the My Porsche team has adopted the zero-bug policy.
This approach is not new, of course. Philip Bayard Crosby coined the term “Zero Defect” in the 1960s to describe a flawless production process: “In a true zero-defect approach, there are no unimportant items.” Initially, this method was used in the aerospace manufacturing industry. Later, in the 90s, it was also adopted in the automotive industry.
Why it makes sense to adopt a zero-bug policy
First of all, we want to develop high-quality software that does justice to the Porsche Brand. And second, we do not want to manage defects. Managing defects is time-consuming, time we would like to spend on more useful activities.
Why is managing defects not a good idea? Often, you begin with qualifying or classifying defects in different categories, such as:
1. blocker: fixing time — as soon as possible
2. major: mostly within 1 or two sprints
3. minor: mostly within several sprints, greater or around 5
4. trivial: when you have time.
As you can see, bugs are prioritized according to urgency. Eventually, this leads to a growing list of defects. And most teams will start to go through this list on a regular basis, i.e. they will ask themselves the following questions on a weekly or so basis: “Is the defect still valid?”, “Is it in the right category?”, “Should we plan to fix it in the next sprint?” etc.
This is not only time consuming but also frustrating for the whole team, because it gives them a bad feeling, especially in respect to the product, which does not have the desired quality.
In contrast, the zero-bug policy gives us only two categories to work with:
1. defect: fix it right away
2. no defect: do nothing or it is an improvement.
In other words, the team or the developer checks defects as soon as they are found. If it is really a defect, it will be fixed right away.
Does this impact our sprint goal or velocity? Yes, of course it does. But it strengthens our product and over time the amount of ad-hoc occurring defects is decreasing. After introducing the zero-bug policy, we realized that we were actually forced to do more to find defects much earlier, thereby using or building more test automation.
How to start, if the bug list already exists?
There are two options. First, the easiest way is to close all defects and then start fresh with the zero-bug policy. However, it might be difficult to convince everyone, especially the stakeholders. Second, go through your list one last time and bring it into a prioritized order. Then, take a small number of defects into the next sprint. If a new defect occurs handle it with the zero-bug policy and take the next important defect from your list into the sprint and fix it immediately. This way, you always have your 0 in place. Repeat this process with all upcoming sprints. Eventually, you will reach zero bugs, because in each sprint you fix a specific number of defects.
To illustrate this with an example: You have 40 defects on your list. Start to schedule the five most important ones within the next sprint. 35 defects is now the new 0. So, what happens if a new defect occurs? First, you check the defect and put it into the defect list and in parallel the first defect of this list will be directly pushed into the sprint and has to be done before the sprint ends.
Thus, after the sprint you will have 35 defects left. For the next sprint, you plan to fix the next five defects and define 30 as the new 0. This method will be repeated until you really reach 0.
How does this help, you might ask? The team gets used to the 0-bug policy and the number of known defects is decreasing. Furthermore, in the future, you will always be really close to zero. Within My Porsche, we had a good experience with using this method and it saved us a lot of time and we increased our built-in quality.
Janos Ansel is Release Train Engineer at Porsche AG.
About this publication: Where innovation meets tradition. There’s more to Porsche than sports cars — we’re tackling new challenges, develop digital products and think digital with a focus on the customer. On our Medium blog, we tell these stories. It´s about our #nextvisions, smart technologies and the people that drive our digital journey.
