When people talk about quality improvement, they tend to talk about process, and to a lesser extent, methods and tools. Let’s put some order in these terms, and see what’s missing in many conversations about quality.
In the software development domain:
Process — How people do things together. Who does what, and in what order. Inputs, outputs, expectations.
Method — Specific way of doing something. E.g., Using UML to express a software design. Or refactoring to improve it.
Tool — Usually software. E.g. , an IDE add-on, or a source control system.
Quality management people try to capture and improve the process. ISO 9001:2000 can be good for that: ISO got with it, dumped a lot of paperwork, and basically preaches “Say what you do, do what you say, look at your results, and make changes accordingly.”
Today’s software development community is also abuzz with methods. Sure there’s Agile, but that’s mostly at the team level. At the individual developer level, refactoring and unit testing are some good examples.
And where would we be without tools, which, for developers, usually means the best IDE and its add-ons. Rightly so — in the end, a developer produces code, and needs the best environment on his or her computer to do it.
So what’s missing?
All of software quality improvement is about getting software released as fast as possible, working correctly. Once people know what they’re supposed to be doing, and have the basic methods and tools, wouldn’t you want people who are really good at it?
To be specific:
In an otherwise well-organized company, the biggest improvement will come from having developers get better at design and coding, every day.
How to do it? Not just courses on technologies, or even on methods. Rather, the way people learn for good: by finding someone better at it and getting guidance on their daily work.
So if you’ve got some really good developers at your company, don’t hide them away: let them work with the rest, to improve everyone’s skills.