Are you hiding behind the process?

Some people depend on the process for making results.
I was involved in a situation recently where a software defect was found after the production release. A team member was quick to analyze the situation and indicated that the team had not followed all the steps in the process. They stated that this resulted in increased risk and was the root cause of the defect.

Don’t be afraid to fail.
It appeared to me that their behavior was driven from a fear of failure which often results in blame. If we work in environments that place blame for failures then how do we expect people to learn and correct mistakes? How do we expect them to operate at peak efficiency if they are focused more on the consequences of failure than they are on the results of succeeding?

I talked to the team member and their manager and explained that risk of defects and failures was part of the business of software development.  The particular change that our team implemented was low risk to begin with and the defect discovered was not disruptive to the financial aspects of the site. The decision to by-pass the full process was made based on reduced risk for the change and the potential financial return.

I had a similar conversation with my son about hitting a baseball.
If a baseball hitter has a batting average of .333 (one hit in every three at bats) it’s considered great. Think about that, that means the hitter fails two times every three at bats. Now, I understand trying to compare software development to baseball is like comparing apples to oranges. But it’s not the failure rate that I’m comparing; rather it’s the mindset of failure. A baseball hitter must approach batting with mindset of hitting the ball, not a mindset of swinging to prevent missing the ball. The same holds true for the software developers and testers. They should approach their profession with a mindset solving problems, not a mindset of being afraid of creating problems (defects).

It’s really all about focus.
Focus on the goal, the prize, and solving a problem. Don’t focus on not failing. The processes that organizations define exist to establish a consistent discipline to create a product or service. Problems arise when team members place more weight on following the process than on solving the problem. Don’t let the process becomes the focus and checking-off the steps the objective. That’s hiding behind the process.

A better way is to use the process as a guide for discipline. It helps to promote communication, consistency of purpose, and above all solving the real problem.