Tuesday, December 23, 2008

Quality improvement (Toyota example)

To understand current situation I have been re-reading a book on Toyota's quality process. I found many thoughts that can apply to programming directly.

"Something is wrong if we do not look around each day, find things that are wrong, unclear, tedious or repetitive, and then rewrite the procedures." - paraphresing Taiichi Ohno (Toyota)


One of the recent changes on our way of software development is to de-emphesize the rush for new features in order to ensure the quality of the delivered product.

When we propose a new product (QA build) we STOP new development until all problems are resolved and the application is trully polished, unit tested and documented. We involve our clients in QA process.

Only when problems are resolved we can provide product for UAT (user acceptance testing) and production deployment.

Only when everyone is absolutely happy with the features they delivered we start PLANNING the new development.

While in planning phase, we listen to the user feedback and fix any problems we missed, code at this point is still the same as UAT.

This is: fix problems first policy.

Once a stable product backed up by a suite of regression tests (Selenium) and delivered to the users, we go into a phase of intense development of new features.

The philosophy here is to continously deliver new, solid features that fully satisfy the client. Quality vs. poor quantity.  Having less features hardly ever breaks the deal, having production problems always does.