I think the concept of the zero-defects mindset confuses people. Many agile proponents say that it inhibits creativity and risk-taking, and thus should not be an agile practice. However, the goal is not so much to produce no defects, but to focus on doing the best work possible.
First of all, what is the zero-defects mindset? Let’s go straight to the source for Microsoft’s definition:
“A best practice or principle of a successful team, it means the project team commits to do work at the highest quality possible at the time it is being done, and each team member is individually responsible for helping achieve the desired level of quality. The zero-defect mindset does not mean that the deployed solution must be “perfect” with literally no defects; rather, it establishes perfection as a consistent goal for the team to strive for.” [Microsoft Solution Accelerator glossary]
Many misunderstand this. The problem is people hear “zero-defects” and think, “That’s impossible! You can’t mandate perfection. People are only human and make mistakes. You shouldn’t punish them for making mistakes.” Consequently, they think this rule reinforces bad behavior.
For example, Mary Poppendieck tries to use an analogy to the armed services. If you read that article, the point she is really trying to make is that decision-making should be pushed down to front-line workers (this is the business concept of empowerment, which has been around in business for a while now). I don’t see how that contradicts Microsoft’s definition above, do you? Also, there is a huge difference between heroism in the military, where people can die, and developing software. That is just too big a stretch for logic.
Joel Spolsky, former Microsoft employee and founder of Fog Creek Software, explains what the intended objectives of the zero-defects mindset really are:
“To correct the problem, Microsoft universally adopted something called a “zero defects methodology”. Many of the programmers in the company giggled, since it sounded like management thought they could reduce the bug count by executive fiat. Actually, “zero defects” meant that at any given time, the highest priority is to eliminate bugs before writing any new code. Here’s why.
In general, the longer you wait before fixing a bug, the costlier (in time and money) it is to fix.” [The Joel Test]
Fixing bugs first, before writing new code… now that’s an agile principle if I’ve ever heard one. Even with Test-Driven Development we know there will still be some defects that slip through somehow. After all, you can’t predict how unpredictable the users will be! But the end goal is 100 percent unit and acceptance test coverage with automated unit tests. Sounds as close to the zero-defects mindset as you’re going to get.