Home > Agile, Development, Rants, Software > The Purpose of Process

The Purpose of Process

It shouldn’t be a big surprise that I prefer low ceremony agile processes to their heavyweight waterfall brethren. While I’m certainly not anti-process, I’ve spent way too much time in meetings defining how we were going to write software. Recently I wondered, do other industries spend so much time on mundane details like templates for issue logs? Perhaps they do, but I doubt the architects of the new 35W bridge spent a lot of time discussing the how they would document the plans for the new roadway.

Most companies I’ve worked for spend an awful lot of time and money on process. Much as no serious enterprise would ever consider deploying SAP or PeopleSoft without a hefty does customization, every organization wouldn’t dare to use an off the shelf process. No, it’s better if a group of people spend months coming up with the perfect approach and a set of presentations that would make Tufte weep. Despite a lot of pats on the back, I’ve yet to see this effort lead to any significant business value, yet it is a persistent part of the environments I’ve worked in.

It seems to me that most companies focus on process for one of three interrelated reasons. First off, there are a number of people in technology that, well, aren’t very technical. Some of these folks *used* to be, but many just bluffed their way into higher paying roles and well, they need things to work on. Of course not everyone needs to spend their free time brushing up on the finer points of the closures in Java, but last I checked templates don’t compile their way into working software.

Second, software projects have a nasty tendency to fail and to combat this fact, most organizations want greater control over the work. To accomplish this goal, they invent more and more process, more gates, more checkpoints. Of course it doesn’t really work that way, and the tighter they grip, the worse things get (hmm, sounds like a Star Wars quote to me.)

Project failure brings us to reason number three: plausible deniability. If (or is it when?) a project isn’t everything it can be, we can always point the finger at the process as either a point of blame (if only the process had a few more gates…) or as an example of success (as in: we’ve got a great process now…) Following the corporate standard also gives managers et al an easy out: yeah, the project failed, but we followed the all mighty process.

Don’t get me wrong, heroic software development isn’t good either. I’ve worked in manners best described as fire fighting and frankly that’s just too much stress for me (though some people I know absolutely thrive on that rush.) Like so many things, process lives on a continuum. At one end, we have absolutely nothing – hack and code, cowboy coding, whatever you want to call it. On the other end, we’ve got extremely heavyweight command and control approaches that attempt to plot out when every developer will use the bathroom.

Truth is often found between extremes and we should seek a balance. Do what’s right for your project though I’ll always favor the less is more camp. And before you spend the next few months creating the perfect process see if something off the shelf will work. Better yet, try some stuff and see what works for you – repeatedly ask yourself these two questions: what worked and what didn’t; do more of the first and less of the second and you might just find yourself on a successful project.

Categories: Agile, Development, Rants, Software Tags:

google