To give you some food for thought about software processes I want to state a few things which I experienced in the past 20 or more years. These experiences may sound like the confession of a heretic, but I stand to it...

Software developers usually do not like processes. They feel it restricts their way of working too much and cuts down their creative work to formal activities. This is like turning a professional poker player into an office worker or something to that extent. Therefore you have to take care of this! Eventually it means that you can define a perfect process but nobody is going to use it. Sometimes I had the impression that it would have been better to employ a psychologist or marketing expert instead of yet another process engineer, to promote the processes in a company.

A process does not stand or fall with the process model which is the background of it. I was in meetings with process engineers. Most of them never did any serious software development by themselves. In the meeting they kept discussing the advantages of the V-model vs. the waterfall model for hours, days and weeks. Those guys then defined a process, which took them months with the outcome that nobody used it, because it was completely away from reality.

High CMMI or SPICE levels of a company do not imply that their products are any good. It just tells that they have passed the assessment and the assessor was satisfied with the defined process and the answers he heared and the documents he saw. Still the products may be of bad performance because an assessment level does not tell anything about the qualitiy of the products. It tells only something about the quality of the process.

Processes are often taken as synonym for tools. Too many companies define their processes around tools. The better way would be to define a process which is good and simple and which is accepted and used, and then look for tools to support it at the places where they can improve handling and save time. Sometimes a tool is used to support a part of the process and another tool to support another part. However the tools can not be linked and the complete process suffers from it. The result is worse than if no tool would have been used at all. Also you have to consider that tools need administration and have bugs. You also should consider that your tools have to have good interfaces to each other to be really helpful in a process.

I came across many cases where little things made a big improvement in processes. Not the big things like introducing big quality groups, formalized review meeetings or the introduction of a requirements database caused an improvement. It was a simple release checklist, a code handover sheet for testing or integration, a mailing list to distribute information, etc. which did the trick, made work easier and more organized. These things reduced the development, testing and integration times and improved the quality of the output.

There is no clear rule which guides you regarding which process standard you have to compy to. Sometimes your main customers enforces the compliance to certain standards on you. Currently there are two main standards. The first one is the CMMI (which is not an official standard) the second one is the ISO 15504 (SPICE). To some extend they both say the same, but the ISO 15504 has finer grades of assessment. Both of these standards are very young compared to the history of technology. I can remember that we had processes and so called mini-processes when I worked for IBM 30 years ago. And we were doing great products at that time. Also mankind managed to fly to the moon without one of these standards guiding them. Some years ago I came to a department which is one of the leading organizations for airbag systems. They had a process and it was even written down in some procedures. However it was not complying to any of these "new" standards, simply because they did airbags long before these standards were written down. They did what made sense, what they learned the hard way and they had written down as much as was necessary. And it worked, they made good airbags! What this taught me was that the standards enforce something which may be too far away from what is really needed. Processes have to be a helpful tool for your employees. Something they are grateful for, because it helps their work and makes life clear and easy. This is an art where you need good support for. Eventually your company will improve and succeed if your products and results get better. The danger with many processes is that they suffocate activities in formalism.

Imprint