I have witnessed countless debates about the merits of process in development teams. Intrigued by this ongoing controversy, I decided to dig deeper and write an article exploring why processes are crucial, despite often being met with resistance. My journey began with a simple online search: 'Why do people dislike process?' To my surprise, the results painted a more extreme picture than I had anticipated. The top hits consistently used the word 'hate' instead of 'dislike,' revealing a level of animosity towards process that far exceeded my initial assumptions.  This discovery not only piqued my curiosity but also underscored the importance of addressing the misconceptions and benefits of well-implemented processes in software development.

Before I start making you fall in love with the joy of process, I have a confession to make. When I started my development career, I had disdain for process. We were required to complete weekly timesheets. The hours had to sum to a full week, so we needed to track meetings and other non-coding activities. The reason I detested this process was that we did not bill our hours to either internal or external customers; nothing was done with this data. In an act of passive-aggressive protest, I would always enter a line item for the time it took to complete this form. I was convinced that 'process' was just a fancy word for 'ways to make simple things complicated.'

I suspect that much of the dislike of process stems from the same reason I bridled at completing the timesheet. Software engineers do not like to be pulled away from writing code, especially when instructed to do something for which they see no purpose.

Good processes, those that people will love, or at least tolerate, share at least three characteristics:

1. The process should help people get things done.

2. The process should not be imposed from on high.

3. The process is not carved in stone as an immutable edict.

A former boss stated the first point as: “Process should serve delivery.” If a process is not making it easier to get things done, it needs tweaking. If a process is actively hindering the work of those who follow it, it should be abandoned.

Managers identify the need to change how something is done. They may think that their idea for a process will improve the workflow. They should not move from knowing there is an issue to unilaterally imposing the process they have designed. The process should be treated as a proposal to discuss with the team. Those who will follow it need to understand why it is necessary and be able to offer suggestions to amend it.

A team agreeing to follow a new process is not the end. Over time, the team or its leaders may realize that the process is not working as envisaged. The real world is different from a brainstorm on a whiteboard. Prussian Field Marshal Helmuth von Moltke the Elder wrote:
“Kein Operationsplan reicht mit einiger Sicherheit über das erste Zusammentreffen mit der feindlichen Hauptmacht hinaus”
Translated into English and made more concise:
”No plan survives contact with the enemy”

Even if the process worked well when it was launched, changing circumstances may impact its effectiveness. A leader should be open to amending the process. Retrospective and postmortem meetings are a natural place to review the effectiveness of processes.

There are times when processes that do not serve delivery are needed. In one role, the finance department needed to know the cost of projects that were eligible for R&D tax credits. Therefore, we asked developers to enter hours against these projects. It may seem that this shows hypocrisy; I was requiring timesheets. However, there are key differences.

1. I could explain to the team the benefits of following the process.

2. We needed the hours to be entered monthly, not weekly.

3. There was no requirement to account for every hour, just those worked on specific projects.

In summary, you should be able to explain the benefits of any process. You should discuss the best way to implement it with the team, and you should review processes frequently. Following those steps may not cause your team to love processes, but it should stop the hate.