This post originated from an RSS feed registered with Agile Buzz
by Laurent Bossavit.
Original Post: Of processes, babies and batwhater
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.
There is a temptation, which is to think of "process" as meaning "a set of instructions which, if people would only follow them to the letter, would result in reliably complete some kind of work in the minimum time and with highest quality". That was Frederick Taylor's insight, and you can't entirely blame some people for wanting to apply it to software. After all, it worked (or seemed to work) for reliably completing high quality cars on time.
Well, it turns out that Taylor's ideas do not, in fact, transpose well to software. Or at least, not given the current state of our technical knowledge on software; I'm pretty sure that not everyone has given up on the idea of making the programmer a kind of factory worker. And I can understand Naresh's association between Taylorism and the word 'process', and coming to hate the word as a result.
Where I balk is when Naresh suggests banning the word itself, and suggests that one would want "zero process". That strikes me as a case of throwing the baby out with the bathwater.
The notion of "process" is quite useful. "What is your software process" is a valuable question to ask, for instance you'll see it asked here on Stackoverflow to good effect. Why would you want to deprive yourself of a word that is such a compact shorthand for the set of questions it implies ?
A question about process is basically a question about regularities. "Suppose one of your users runs into trouble with your software. What do they typically do ?"
This could have different answers. "Well, half of the time they call up one of the developers on the phone, and the developers fix it right away. And half of the time they'll send email instead, to the lead developer, who forwards them to one of the devs for a fix." Or you could hear "They file a trouble report using our ticketing system, it goes to a support person for investigation and qualification, possibly as a defect, and if it is a defect QA will write a test exposing the bug if they can repro, then after a fix is found by development we'll either issue a patch or it gets into the next release."
These answers have something in common. They describe a process. You can ask some follow-up questions: how is that working out for the users ? Are they happy with how their reports are handled ? How is it working out for the developers ? What (if anything) would you like to improve ? Do you think you might shorten fix times if you agreed to do X instead of Y ? These questions could even be asked by team members themselves, in a retrospective, taking a process perspective on improving their results.
Of course you could hear other kinds of answer: "I don't know. I haven't even thought about users having trouble with our software." Or something like "I trust them to do whatever is appropriate." Or you could hear (at length) about Bob, the user in Accounts Receivable who calls at inappropriate times, yells at the developers and is generally a jerk. All these answers are interesting, and they are not about process.
Even Naresh, while calling for "zero process", is concerned with describing regularities:
Personally Iâve been executing projects quite differently. When I think about the various things we are doing, they donât quite fit what the books or the standard training courses are talking about. In fact in some cases it contradicts them. Interestingly, I see a few folks executing projects similar to my style. There is certainly some common patterns out there. [...] How do we package these evolved concepts and patterns? Just so that I can differentiate it from the rest, I prefer calling it âNaked Agileâ.
...and starts making the exact same mistake that he's so worried about. That is, thinking that a process description obtained in one team, one project, can always be turned into a prescription for other people to follow:
Then the question comes, do new comers really have to go through the same evolution process to understand and appreciate Agile? Or can they skip some of ancient practices & concepts and jump start with what we collectively believe is the most suitable now?
Certainly that's a good question. But, if it is a good question to ask about the "ancient" practices and concepts, why not ask it also about your "current" practices and concepts ? What is it that makes any process description something suitable for anyone to "jump start with" ?
This is an open question, and a difficult one. I'll say more about it later - lately I've been writing about it, and speaking at conferences about it. But the observation for today is that it would be hellishly difficult to examine that question if we deprived ourselves of the useful word "process".
Previous Topic
