30 June 07 - 14:57Please influence the Agile community
How ?
By
nominating someone for the Gordon Pask award. You can get the official description of the award from Brian's blog; I'll tell you what it means to me.
I was awarded the Gordon Pask last year, at the Agile 2006 conference. It was a weird moment. I was stressed out and tired from presenting too many things. I made a little speech. I started by thanking the people who had welcomed me, so to speak, into the Agile community back in 2002 at the XP conference in Sardinia. Many were in the room. Then I said more or less the following: "It's always hard explaining to my neighbours, to folks I met at parties, and so on, what this Agile thing is that takes up most of my time and has become a full-time job. Lately I ask people if they've used a computer; I ask them if they've been frustrated and angry with it. Usually they say yes. Then I say that we're working to improve the software profession, so that these things eventually become history. That seems to be a pretty good explanation, judging by the encouraging words I get now. For me this is what Agile is primarily about: working to become a profession that people respect, like doctors, firemen or astronauts." Well, that was my speech. In retrospect I might want to add that it takes more than software developers to build software, so there are many roles in our profession for which I would also like more recognition as professionals. Testers, "customers" (product owners, if you prefer), and so on.
The Gordon Pask award is one way for the Agile community to say, "Listen to what these people say Agile is about, and look at what they do about it." It is intended for people who don't already have "star" status, like Kent Beck; for people who are doing things within Agile that seem to matter and who we'd like to have more recognition, so that they will matter a bit more.
You can help define what Agile stands for: look around you at who is doing stuff that you think moves Agile in the right direction, and nominate them for the Gordon Pask award. Just send an email to pask-nominations(at)agilealliance.org .
- default -
-
§ ¶
29 June 07 - 14:56One of the best ways to invent the future...
...is to attend a conference.
Here is one that just appeared on my radar - and for reasons that will become clear shortly, I'm mightily tempted not just to attend, but to present something.
The best conferences are just that: invitations to shape the future. Back in 2002 when I attended the XP conference in Sardinia, it felt so invigorating, exciting, mind-expanding it felt to be surrounded by people who had a vision of how the world - or some little part of it - could be made a righter place to live. (Another of my favorite quotes: "The greatest obstacle to transforming the world is that we lack the clarity and imagination to conceive that it could be different. -- Roberto Mangabeira Unger")
How could I not be interested in a conference presented as follows: "Computers, networks, and other forms of technology are now pervasive in our information-based society. However, most users still function as passive consumers of technology. To evolve into a true knowledge society, it is critical that we transform computer-based human activities to engage users in the active process of creating, connecting, and collaborating together."
The
C5 conference will organized in january 2008 in Poitiers, France by Smalltalker extraordinaire and fellow
Dojo enthusiast
Serge Stinckwich. When I Googled previous editions of the conference, a number of things became clear.
First and foremost, it appears that it might be an occasion to meet
Alan Kay in person. It's not certain yet, but that alone would make the trip worthwhile - for an OO enthusiast, meeting the person who invented OO is too good to pass up.
Next, the conference, which originally had a major focus on Squeak and Croquet, is opening up to the full scope implied by its name (C5 is an acronym for "Conference on Creating, Connecting and Collaborating through Computing"). Serge has confirmed that XP/Agile, with its emphasis on shared responsibility for the design of software systems and customer collaboration, could be a fit topic for the conference. And it seems only logical to want to be more than a "passive consumer" at such a conference...
- default -
-
§ ¶
05 June 07 - 15:34"Just a mistake" ?
Two follow-up observations on my previous post about "four types of process errors".
One is to stress again the difference between (what I think are) the relevant attitudes toward process, as per my previous post, and how much formality accompanies process. The two dimensions are quite orthogonal. If you are very formal, you will define in painstaking detail the Inputs, Transformations, Outputs, Resources and so on, that constitute your process. If you are informal, you'll just say things like "our process involves shipping every two iterations, three if it's a big chunk of functionality". Just how much is to be gained by being more or less formal is still a mystery. To be Agile means, usually, to take a clear position that formalism doesn't gain a whole lot. Still it's interesting to note that people who label themselves Agile tend to vary quite a lot as to how much formalism they like.
One thing you gain by having some formalism is traceability, as in: the ability to resolve disputes by looking at something objective (a written statement or a diagram) when people disagree about what the process is
supposed to be. (That distinction is still important.
If it's written down, but people do not generally do it, it's not their process.) And as in: looking at the changes that were made to the process over time. And so on.
What is clear is that if you have too much formalism, it can be as much a hindrance to traceability as having too little. If it's written down, but people do not generally read it, look at it, refer to it, it's not their process.
Another thing that came to mind was an objection: "Maybe sometimes a mistake is just a mistake". Say we make a mistake and don't change the process - are we necessarily making a Type III error ? Suppose you've forgotten to pack your razor before going on a trip; it happened just this once, never before. And if you never had it before, you're not necessarily going to decide that from now on, you'll use a "check list" of things to pack, which includes your razor. Perhaps for many people that would be a Type II error: going overboard. On the other hand, before your next trip you're probably going to think twice about your razor before you're done packing. "I remember I forgot it last time". Well,
remembering is maybe the simplest type of process there is. You did change your process. So, forgetting the razor would be a Type IV error.
- default -
-
§ ¶
04 June 07 - 14:47Four types of process errors
Part of the
Agile Manifesto reads: "...we have come to value
Individuals and interactions over processes and tools". This has often been paraphrased as "
people over process", a phrase which has generated a lot of debate, not all of it very productive.
One reason for that is that everyone knows the meaning of the word "people", but not everyone - far from it - understands the meaning of the word "
process". I'm still not sure
I do (especially after looking at the various pages of that name on Wikipedia).
In the context of software development, it is used with varying degrees of formality to mean "the generally understood distribution of responsibilites among the various roles involved in getting software out the door". One source of much confusion is in the "generally understood" part: what I usually need to clarify at the start of any discussion of "process" is that people use "process" both to mean any of the following, depending on context:
- "what we're supposed to do, and actually do"
- "what we're supposed to do, but don't actually do"
- "what we actually do, regardless of what we're supposed to"
Of course, what actually matters - what is worth discussing - is what people
actually do. A 10-page process document or a flowchart are nice, but generally irrelevant unless they match very closely with what people actually do in the pursuit of shipping software.
Now to the main point of this post - which is still somewhat fuzzy in my mind, but which concerns the way in which mistakes resulting from a process are corrected. Along the same lines as the "three types of errors" known in statistics, I think processes (or maybe process cultures) can be classified in different categories according to how people are seen to handle defects (problems, incidents, mistakes, crises, etc.)
- A Type I error (rigidity) is when you follow the process, produce a bad outcome, but you're not allowed to change the process
- A Type II error (bureaucracy) is when you follow the process, produce a bad outcome, and the process is changed by the addition of an exception that only addresses repetitions of that exact same mistake
- A Type III error (hacking) is when you follow the process, produce a bad outcome, and do nothing about the process
- A Type IV error (benign) is when you follow the process, produce a bad outcome, and correct the process so it produces better outcomes overall
You see errors of Type II all the time in attempts to regulate health hazards. For instance, one person dies after doing stupid on an amusement park ride, and that results in new legislation mandating foolproof belt buckles which can only be undone when the ride is stopped. (Until there is a fire trapping dozens of people on a park ride, at which time...)
I'm often concerned that an overly enthusiastic interpretation of "people over process" could lead to Type II errors. "Well, our iterations are supposed to be two weeks long, but Bob is on vacation for a week so it seems to make sense to use three weeks this once." Sensible, but if you keep making exceptions to your process, pretty soon you're going to be in Type III territory: getting bad outcomes but not bothering to fix the "process" any longer, because no one remembers any longer what the "process" is. On the other hand if you treat the process as "sacred" you'll end up in Type I territory.
Errors of types I through III are not just errors, they are
meta-errors. They are defects arising from the process that is in place for modifying your (software) process. If you're lucky, your meta process has only Type IV errors: people recognize that they are too rigid, too procedural, or too indifferent, and adapt accordingly.
More useful than calling for "people over process" is, I think, characterizing one's process according to which of the above four types of error it suffers from, and recognizing the possibility of going meta.
- default -
-
§ ¶
