Rant: Process Schmocess

In the art of software development with teams larger than one, a process for repeating results is about people. It's about getting them to cooperate and produce something great. That's really it.

I hear groups talk about processes and "resources" (meaning people) and action items and critical paths and all this stuff, and they're full of crap. Their eyes are not on the ball. Management of the process has become the game.

"A perfection of means, and confusion of aims, seems to be our main problem." -- Albert Einstein.

Groups get together and do things in order to produce software. It has to be useful. It's the result of solving a problem, sometimes a whole bunch of problems. If you have an elaborate "process" and spend all your time in that realm, you are possibly probably losing sight of the goal -- great software.

A small group that cranks out great software (meaning it's actually used, it sells, it's profitable, innovative, loved—whatever the criteria for "great" are) and has no process has a good process. If you're a project manager on a team of, say, five people, there is a chance you already have too much "process" smothering your team.

I used to work with a project manager who was the epitome of ineffective. He would try to explain to us something, but it sounded like, "Yeah, we, um, need to review these milestones so we can firm up our deliverables and line up resources so that we can review this with the client at the weekly status meeting and satisfy the action items from last time, too. Alright, see ya." I'd turn to my coworker and ask if he knew what we were supposed to do. "Nope." Me neither.

How about, "Grab Chris, and the two of you get that piece working well enough for us to review it WEDNESDAY A.M. If you have any problems, let me know TUESDAY a.m. and we'll figure out what to do. The client wants an update on THURSDAY. Capiche?"