Quality is #1

We just shipped v2 of our project - but few are cheering. To meet our dates we dropped quality on the floor (reliability, usability... you name it) and everyone knows it. There's already talk about what commitments we have for v3, but no one has articulated what we're going to do about raising the quality bar.

How do you (successfully) argue for time for higher quality? Has anyone worked on a project where quality was really job #1? How did it happen? Who defined (and defended) quality?

- Quality is job #1

Response by Neil Enns, Product Manager, Microsoft Visual Studio
---------------------------------------------------------------

In my product (Visual Studio) we took four months off feature work after shipping our last release, solely to focus on quality (called “Milestone Quality” or “MQ” for short). It wasn’t just product quality, but also engineering process quality. We automated thousands of test cases. We scrubbed our postponed bug database. We educated the development team on the latest in testing processes (such as TDD), and built tools to help developers implement those processes.

What was so cool about the four months is that it wasn’t just about fixing bugs in the product. It was much more about seriously looking at our engineering processes and being smart about what needed to change, and investing in the tools to support those changes.

This only works if everyone up the chain buys in, and it has to be driven from as senior a level as possible. In our case, Soma was adamant that we do this, and every single person in the division participated.

You can read a little more about this effort at Soma’s blog (http://blogs.msdn.com/somasegar/archive/2005/11/08/490694.aspx) and Eric’s blog (http://blogs.msdn.com/eric/archive/2005/11/04/489108.aspx).

Neil