The Ugly P-Word

Process! (Suddenly I feel like I need a shower)

People have stated that I am a ‘process guy’.  It is true.  I freely admit it.  Nevertheless, why is ‘process’ considered an ugly word?  We all use processes to obtain our goals.

As an engineer, I have my peers review my code before it is checked-in to the source repository.  The Quality Assurance team has a collection of scripts they follow to test areas of our product that automation does not cover.  Management regularly reports the team’s progress through standardized reports.

We follow these processes to accomplish our goals.  The goal of code reviews is to remove defects earlier in the development cycle.  QA follows scripts to ensure consistent test coverage.  Management utilizes standardized reports to communicate with clarity.  These processes ensure consistency and improve quality.

For people who dislike process, the issue in my opinion is not ‘process’, but equating ‘process’ with ‘bureaucracy’, which is the blind pursuit of process.

Developing software is like no other profession.  We know that things change.  We discover requirements all the time when we develop software.  It is simply impossible to know everything upfront.  Change is like death & taxes – it is inevitable.

Change occurs not only in requirements, but also in defining what we need to build and how we build it.  We may adjust our object model when we discover new insights.  This leads to leveraging new libraries in the model, which requires additional expertise.  The team may need to build or acquire that expertise, which leads to changes in the teams dynamics.  If process were another word for bureaucracy, these changes would be near impossible because the rules are rigid.  “We must only use our proprietary libraries”, or “You cannot change the model because it will cause too much re-work”; these are examples of bureaucratic rigidity.

Process is not rigid.  Process is about guidance and insight.  Process explains what must be done and why.  Processes allow someone to challenge and expand them to meet the needs of the team.  An example of this is a wiki I put together outlining the roles and responsibilities of a distributed team merging multiple branches of source code.  While the team generally followed our defined processes, there were times when then team found ways to accomplish work that was against the process.  For example, the process stated that between shifts, remote engineers should call the engineer starting the next shift and inform that engineer where they are at in the process.  The goal was to get the engineers to communicate smoothly and effortlessly.  The engineers decided to switch to emails rather than phone calls because it was easier to organize their thoughts as they typed them.  Additionally, engineers sometimes could not work a full shift.  If they were performing phone calls, they would have to wait for the other engineer to start his/her shift.  With email, they sent their message and went home.

This was a good example of process.  The goal was to communicate between engineers to facilitate a smooth transition between shifts.  The process recommended one way, but the engineers found another that worked better for them.  The process worked, even though they did not follow it to the letter.

Processes are also necessary for new team members.  They help those who are unfamiliar with the working environment, allowing them to integrate with the team and work effectively.  In time, as their expertise grows, they can move away from following the process literally, to following the spirit & goals of the process.

Everyone has their personal processes to achieve their goals.  Every team has their processes too.  Process is not bureaucracy.  It is about guiding and informing people about what they need to do with steps to accomplish them.  If people or teams want to change the process, and it accomplishes the same goal, let the team do want they want and be productive in their own way.

I am a ‘process guy’, and I hope you are too.