I recently read a blog post by Chadran Nair emphasizing the occasional need to override the existing process when circumstances dictate it. In fact, the author went on to say that companies which understand and implement this policy get his business. I wonder whether this is applicable in the software development realm. I do not think processes are to be taken lightly. And the breaking of normal process should also be a serious and seldom used resort.
We had a process to compute statistics for how well our software did each year. A couple years ago our customer requested the process be followed to produce input for an important report. This task came to me. So I followed the process and got some unusual stats. They were way too big. I could not imagine how we were coming up with the numbers I was getting. The process dictated that I follow the rules and produce the results.
I inquired to my manager whether I should blindly follow the process and publish the wild results. Like most managers at the time, my manager decided to protect himself and told me to work it out with our customer. Now I had a good relationship with most members in the customer community. So I went to the top technical man in our customer organization. I shared my concerns with him. He definitely told me to research the numbers and find out why the results were off the charts. I was able to skirt by the normal process and found a data point that was messing up all the statistics. In the end, I was told to report a set of numbers that blindly followed the process, as well as another set which discounted the wild data point.
Perhaps this example illustrates the right way to decide when to bypass the normal processes. It should not be done in isolation. And it should be done sparingly. You should get management (or customer) buy in first. But there comes a time when reason needs to prevail. Once in a while you cannot be a drone and follow the documented process when it is going to lead you astray. Yes you can defend yourself by stating you followed the process. However as the old saying goes, rules are meant to be broken.
Check Your Subroutines - We are delivering our latest release to internal test today. Had a code review yesterday. Many issues were found. We are fixing the highest priority probl...