This post originated from an RSS feed registered with Agile Buzz
by Laurent Bossavit.
Original Post: Four types of process errors
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.
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.
Previous Topic
