Process is not a four-letter word

As a software engineer, I’ve worked with a lot of different development processes over the years, and I’m a pretty big fan of a number of them. Also, as a Getting Things Done (GTD) fan and advocate, I have a pretty rigorous process I’ve imposed on myself for doing my daily work. However, I constantly hear my colleagues decry “process” as an unnecessary burden, and look to eliminate it whenever possible. I think this attitude is somewhat mistaken at best, and actively harmful at worst.

Let me start, though, by being clear what I mean by “process”. A process is the means by which something gets done. Using that definition, if you get anything done at all, there was some process by which it happened. It could be a good process, a bad process, or even just plain trial and error. It’s still the way it got done.

So, process clearly isn’t actually the enemy here, since we all like to get things done. Really, the problem my colleagues are reacting to is having a bad process with too many unnecessary, laborious, or complicated steps. This is definitely a problem, but not the worst one you could have.

The worst is having no process at all. Of course, that’s not actually possible, so really what this means is that your process is made up as you go along, on the spur of the moment, each time you try to accomplish something. It may feel good not be restricted from tackling the job in whatever way occurs to you, but you’re very unlikely to take the optimal path from concept to completion. Instead, it’s very likely that pieces will be missed along the way, thrown back in haphazardly, not completed in time, or in the wrong order, and stakeholders will be unaware of what’s going on, or when to expect results.

The worst part of this ad-hoc process is that you’re doomed to repeat the same chaos every time you do it again. Since everything was made up on the spur of the moment, you’ll most likely wind up doing it a completely different way next time. Any lessons learned about what worked and what didn’t (even if you’re able to recall enough of what you did to try to analyze it), won’t be applicable the next time.

The essence of process improvement is repeatability. If you can reliably repeat the same sequence of steps each time, you now have a chance to: 1) clearly understand what you did, and 2) deliberately make changes the next time.

So, one step better than total chaos is what most people think of when you say “process”: a clunky, cumbersome, set of steps which create a lot of unnecessary busywork for those trying to accomplish the goal. I say this is still better than no process at all because it is repeatable. That means, you can tweak the process each time you repeat it to make it better.

The very best processes, of course, are those which only include exactly as many steps as are necessary to ensure the right work is done, done well, and all the right people know what’s going on at each step along the way. The problem is that it’s not always possible to predict what steps those are, and whether those will continue to be the right steps in the future (e.g., as the team grows, or the problem gets more complex).

That leads you to the real goal: to create a process which includes a means of improving the process itself. There are many examples of such processes (SCRUM, Kanban, etc.) when they are practiced well. In those cases, the built-in self-correcting nature of the process allows the details to change to adapt to new circumstances.

Of course, this ideal implies a few failure modes. One is to adopt a “we’ve always done it this way” sort of attitude which fails to allow for refinement, growth, or adaptation. Then, no matter how good or bad the process is at any given moment, you’ll never get better. And, as times change, the process will suit the current situation worse and worse.

A second failure mode is to change lots of thing with each repetition. It is very hard to successfully and consistently change a habit: even when you’re only trying to make one small change. This becomes nearly impossible when you pile on too many things at once. And, even if you managed to do it, it’s very difficult to judge which changes had what outcomes. Better to keep things simple and tackle one change at a time.

✧✧✧

As I said to start, a “process” is the means by which something gets done, and any time something gets done, there was a process by which that happened. Instead of treating “process” as a four-letter-word, I think we should embrace it. Whatever process you’re following for whatever goal you have, start by striving for repeatability, and then—bit by bit—keep making it better.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s