Appropriate Processes

Here's a simple case. The rule states: ``At the beginning of the review meeting, the participants all introduce themselves''. But, a development team of six which routinely ate lunch together called this into question. They all knew each other and reviewed each other's work regularly, and thus they thought it was superfluous. For them, I had to agree.

Here's a more contentious case. The rule states: ``At the end of the review meeting, the team classifies the problems identified and analyzes them with respect to root cause''. Root cause analysis is an established tenet of process improvement and I am not arguing its inherent value. However, it is a totally different process that is being bundled together with the FTR process into one package by this rule. Many organizations may not be ready to tackle root cause analysis yet, conceptually: you can't talk to them about defect prevention when they've only just begun to think about improving defect detection. The analogy here is from Piaget's theories of human development, where an idea, introduced before its time, cannot be grasped. If the idea of root cause is totally foreign to the development team working on implementing FTRs, this rule may have one of two detrimental effects:

• They may reject FTRs in total, since all they see is: ``These FTRs are just another bureaucratic waste of time. Nobody ever uses that data, so why waste our effort getting it, anyway''.
• They accept that FTRs, in principle, are reasonable, but ``we'll pass on the root-cause stuff for now''. Now that part of the process has become `optional', the process credibility has begun to erode, and it will continue as more things, even the FTRs themselves, drift under the `optional' heading.

Even when a process looks to be a perfect fit with an organization, if the process was Not-Invented-Here it could be in trouble. In line with current trends toward governance by consensus and participatory management, a group may need to develop some sense of ownership in a process before they fully embrace it. In these cases, a process dictated is a process lost. Here is the quandary: given the existence of an optimal process, should we prefer to impose it on a team, leaving bad feelings all the way around, or should we settle for a less-than-optimal process, owned and embraced by the team? That question will be answered differently depending on the organization and managers involved, but a working, near-optimal policy is generally preferable to a non-working one.

So, what makes an appropriate process? The answer is a cultural one: What works for you. It's always useful to know what has worked for other people, but it is crucial to know the substrate on which other processes have thrived. Unfortunately, in software engineering, we are hampered by not having the ability to run controlled experiments, developing the same multi-million dollar software system under each of several scenarios and finding out which comes out best. What we can do, though, is characterize what we know from the experience of others, and parameterize it based on the culture and environments of their failures and successes. The key to defining an appropriate process for an organization (e.g. project, department, corporation, ...) is to understand the pros and cons of various process commandments, and then to weigh them in light of the individual organization's operating culture and environment.