I’ve often told teams of folks working within the boundaries of some larger process that if they want to see another team improve, they are first going to have to be beyond reproach within the confines of what they can control. For example, one development team that worked for me was convinced that the problem was the poor quality requirements we were getting from the business analysts. That may have been true. But, I argued, if you wanted to change the business analysts, you’d first have to remove all doubt that our development was at fault. That would mean improving ourselves to a point where all that was basically left were problems because of vague or incomplete requirements.
It may still be the right thing to do in the absence of our ability to change anything else, but I now believe that it may create more problems than it solves in the long term. What if we were to improve our test organization’s capabilities until they were able to catch, say 99% of all bugs that made it to them. They’d have an impressive defect containment rate, that’s for sure. But they’d also have another problem. To the end user, our customer, they don’t care how we achieved such high levels of quality. They only care that the product is of quality. And what’s more, what incentive does development have to be better if they know that testing will catch their bugs. The goal is being met, albeit in a wasteful way.
It’s not that the quality isn’t good enough. It’s not that you might be able to achieve it for a reasonable price and time. It’s that you could be doing it better. It’s better to not create the defect at all. You may be capable of doing great things within the boundaries of the process you control, but an even better solution which nobody will go looking for may exist. It’s a solution nobody will ever find if you continue to cover for the up-stream process failures.
Process Rants 
Posted on May 24, 2010
0