This post originated from an RSS feed registered with Agile Buzz by Laurent Bossavit. Original Post: The "Any" process Feed Title: Incipient(thoughts) Feed URL: http://bossavit.com/thoughts/index.rdf Feed Description: You're in a maze of twisty little decisions, all alike. You're in a maze of twisty little decisions, all different. Latest Agile Buzz Posts Latest Agile Buzz Posts by Laurent Bossavit Latest Posts From Incipient(thoughts)

"People trump process" is a wholesome truth of software development. Grady Booch offered the following formulation: "Good people with a good process will outperform good people with no process, every time."

Another frequently offered cliché: "If you hire only good people, then of course you will succeed with any process." I've heard this from more than one Agile critic - and, tellingly, from more than one Agile advocate. (If people agree on something, even though they're supposed to belong to opposite "camps", something odd is going on.)

So here's my take: there is no such thing as "no process". There's no such thing as "any" process - it's like the "any" key on the keyboard that so many computer users waste untold hours looking for.

Suppose that you've seen a group of people put together for a project, gave them an idea - rough or detailed - of the requirements - and the project was eventually declared "complete". Something happened in between. That's what a "process" is: it is a description that involves inputs, outputs, and some transformation of one into the other. If you can look at a project and describe it, at some level of detail, in these terms - you have a process.

What you don't necessarily have is procedures. That's a different beast, too often mistaken for "process". Procedures are rules ("do this"), with expectations of compliance ("every time") and penalties ("or else").

In some areas, "good people" can function without procedures. You need procedures for, say, conducting a nation's census. You don't need them for a picnic. You may not need them for every conceivable software project.

What you will have in every one of these cases is a process, that is, the possibility of describing what people actually do, at some level of detail, in terms of transformations. That's a process, which in some cases may be usefully described in detail as a set of more detailed processes.

If you observe "good people" on a software project, chances are that they are "good" because of what they know. In particular, they know which inputs, outputs and transformations it pays to pay attention to. They know how to put together smaller transformations to ensure that the larger one, from "idea" to "completed project", goes as expected.

When we say "people have a process", that's shorthand. We mean that there's a good way to describe what the people in question are doing in terms of inputs, outputs, and transformations. The description is "good" because it can be shared with other people, and because for those other people, knowing that description makes a positive difference in their performance.

So, the million dollar question is, if in general good people are "good" because their processes are effective, what do they have in common - if anything ? Are there any regularities to what teams of good people actually do, in the ways they transform inputs into outputs ?

That's the kind of "any" process which will reliably enhance the performance of competent people and make them "good people".