A basic tenet of a good software process is that it needs to be documented. This may seem obvious. But you would be surprised how many time the new guy comes in, and must spend a lot of time asking people how things are done. This does not mean a lot of detail needs to be written. And it does not have to be very formal. It just has to been accessible and practical.
I have seen another problem with software process documentation. Often times there are huge documents that are supposed to document the software process. However when read, these documents are actually full of fluff that do not correspond to the actual process being used. This is worse than no documentation. It is lip service to the software process.
In the past I have lead software teams. Some times I had implemented a hands-on approach where I oversaw all aspects of my team's work. In other cases I just wrote out a handful of well-documented process pages, and let the team follow them as I spent more time coding. Guess which option was more fun for me?
