05 April 09 - 11:45Looking for conscious competence
This is sort of a survey. Assuming there was a ranking system in software similar to that in
Go, from 30kyu to 9dan (or ELO, from 1 to 2800), what would you guess your level is ? Why ?
I know, difficult question. Here is one that may prove even harder. What is it about software that, for you, represents the hardest "learning barrier" ? Some aspect of the craft, some topic, that you find particularly difficult to wrap your head around ?
- default -
-
§ ¶
04 April 09 - 12:37Of processes, babies and batwhater
Do you have issues with
the word "process" ?
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".
- default -
-
§ ¶
02 April 09 - 08:53WeVouchFor
At present
WeVouchFor is a zombie project. It's definitely not dead, lots of people are signing up. It's also definitely not alive, no one is actively working on it.
People are signing up because there's a definite need. Recently one more "rip off" certification was announced to the world, and once more the people in the agile community who are sincere agents of change responded to that by offering alternatives - and specifically by pointing to WeVouchFor. This blip in the project's popularity is both encouraging to me, because it suggests that the idea of "peer certification" may be workable, and a little embarrassing - because I have more or less abandoned the project. I'm wondering how to revive it, or what to do about it generally.
What suggestions do you have ?
- default -
-
§ ¶
