Describing what you really do is really difficult.
ISO 9000: (IsoNineThousand)
CMM: (CapabilityMaturityModel)
(from http://www.xprogramming.com/Practices/justrule.htm, written by Ron Jeffries)
XP, to the extent that there is such a thing, doesn't say "Do it My Way or Get Out". Quite the contrary ... the XP-like rules we use on C3 are rules the Team chose to live by, and the Team says "Do it OUR way, or get out". And within the team's rules, there is individual variation. In some areas (you will write unit tests, you will run the unit tests before releasing), there is very little variation. In others, there's more. But there's never much because the team has an internal social contract to do it the way we do it.
This is the way of it: the rules expressed so strongly here aren't my rules or Kent's rules. They are the rules that the team embraces. We do require everyone to follow them, because we believe that they make us more effective. When the situation changes, or we get a better idea, we discuss possible changes and often change the rules. After all, "They're just rules" is one of our rules.
A friend from an organization that is ISO 9000 certified tells me that what they really do is to write down what they think they should do in a notebook, then put the notebook on the shelf and ignore it, until just before the auditors' next visit.
One of the worst places I ever worked and another which was one of the best places I ever worked were both IS0 certified. The difference was that best place practiced what they described as process, while the worst place selectively and arbitrarily ignored and continualy invented new and ineffective ways to do things different from what they described as process. The turnover at the worst place was high, the turnover at the best place was low. There was much overtime at the worst place and 40 hour weeks at the best. This is proof in the putting that it is best to Do what you Say. -- DonaldNoyes 200080106
I once discussed the CMM with a 65-year-old aerospace engineer who had worked on software for the Apollo missions. He told me that in his opinion, the CMM was backwards.
How about...
I can't remember his exact explanation, but I'm guessing it went something like this:
The first thing you need is an ad hoc process. The second thing you need is a way to improve your process. Then you need a way to judge your improvements. Once you have these, your process will get better. When your process is good enough, it will start being used by others. When enough people use it, you can observe what they are all doing and write it down on paper.
If you don't use continuous improvement to get to your process, you have to do big design up front to get to your process. If you do this, chances are the process won't be usable, and will just sit on the shelf in a notebook.
In other words, you have to figure out the process first, by trial and error, before you can write it down. (And 'then' it will sit on the shelf in a notebook, or will be hidden in the source code which will be lost. Personally I prefer things which are visible and organized. Even if that means a ThreeRingBinder.)