On Too Much Process or Too Much, Meh, Whatever

Process - noun - 
   1. a series of actions or steps taken in order to achieve
       a particular end
    (Oxford English Dictionary)

So, a fair number of people have heard me discuss excitedly (find the euphemism for rant) on how too much process stuff gets in the way of actually getting things done.  A fair number of times I pretty well am set in the idea that process should not be a controlling thing or a limiting thing, but a guiding thing.

There is a significant difference between the two of them.  Some people don't want to accept that.

Kind of like some people define "Agile Software Development" as 1) no documentation and 2) no testers.

When people allow the aspects of process to overtake the entire point of what is intended - typically the facilitation of what the process is supposed to, well, facilitate, where the process becomes more important than anything else, you don't have one problem, you have a collection of them.

The opposite end, well, makes bedlam look reasonable.

Having no controls and no processes in place can, and I suspect will, lead to its own problems.  Point of codifying processes, the "How we do stuff" is centered around making sure nothing gets missed: no steps get left out, nothing critical that will impact customer experience (like .JAR files not being where they are supposed to be) and other small things like that.

A process can also help us be certain that everyone who needs to know about something actually knows before that thing happens.  People, myself included, often talk about process as something that is ungood.  I've tempered this over time to be more like, process can help us, it can also hinder us - and the specifics of the situation will no doubt have a direct impact on which one it is.

What often gets lost in the shuffle when talking about process, or some development methodology or approach, is that the point of most software processes is to get things done that need to be done, and make sure people know - I kind of said that a bit before - I know.  But if you look carefully at the second portion of that, the bit that process helps "make sure people know" then that sounds alot, to me at least, like communication.

People forget that communication is less about what is said and is more about what is understood - what is heard on the receiving end.

If you have good communication and people succeed in hearing A when A is said, or written in a report or email or... yeah, you get the idea, then process forms a framework to operate within.  When people don't communicate, process may help - but I suspect it just adds to the noise.  More emails and reports to ignore, more meetings to sit in and do something else whilst they are going on, more of the same Dilbert-esque pointy-haired-boss stuff.

Even companies that quite publicly talk about their lack of formal process have processes - they have rules that people work within - frameworks that guide them  and their activities.

I suspect where I draw the line for processes that are useful and those that get in the way is the willingness of the staff - the people who are directly impacted - to follow and adhere to the given processes.

I prefer processes that are organic - that grow and develop based on the experience and relationships among the people doing the work.

I object to processes which are imposed by someone, or a group of someones, who have never actually done the work (except maybe as an exercise in school or a single project in the "real world") but have read, or attended a workshop or talked with someone at "the club"on some best practice that involved some stuff.  Whatever that is.

If people want to have a thoughtful discussion around what can work for their organization, team, company, whatever, I'd be extremely happy to participate.  If you tell me things must be done this way because of some study or best practice or whatever, don't be surprised if I ask what was studied and what practices were compared to determine which one was best.