Processes vs principles
There are different ways how an organisation can optimise the way of working. Depending on the company culture it may lean more towards processes or principles to guide its teams/people.
A principle is about describing the underlying reason why you should do something. It is contextual and leaves flexibility in choosing the actual implementation details. The emphasis is on educating people and trusting them to make the best choices.
A process is step-by-step procedures and rules you should follow. It is prescriptive — focuses on how something should be done and less on explaining the why.
Often there can be good initial intent behind the process but as the focus is on rules and not explaining the underlying reasons it can result in a situation where the process becomes the objective, not a tool to achieve the actual objective. Such process rules can become like laws of nature inside the organisation. When asking why something is done in a certain way nobody knows the answer besides: “This is how things have always been done”.
The problem with processes is well explained by Tom DeMarco and Tim Lister in their book Peopleware: Productive Projects and Teams:
Methods: The centerpiece of most Methodologies is the concept of standardized methods. If there were a thousand different but equally good ways to go about the work, it might make some sense to choose one and standardize upon it. /…/ When there are genuine alternatives, people have to know about and master them all. To standardize on one is to exclude the others.
Principles cannot be used to delegate responsibility while process rules can be made a convenient scapegoat.
From Productive Projects and Teams:
Responsibility: If something goes wrong on a Methodology effort, the fault is with the Methodology, not the people. (The Methodology, after all, made all of the decisions.) Working in such an environment is virtually responsibility-free. People want to accept responsibility, but they won’t unless given acceptable degrees of freedom to control their own success.
Of course, the simplicity of having a single “way of working” is very alluring. Especially so in low-trust cultures. Unfortunately, this approach helps to turn off a big part of the collective brain and can serve as a good breeding ground for the expert beginner mentality.
One way how to avoid process rules becoming axiomatic is to recognise and nurture a wise fool. This role is described by James O. Coplien, Neil B. Harrison in their book Organizational Patterns of Agile Software Development:
The wise fool asks the questions that may unpopular or that seem politically risky but these questions make the team pause and reexamine decisions.
