Maybe this is a rule of good process design that I’d never heard of, because it seemed suddenly obvious to me when I thought about it today, but I’m going to write about it anyway.
I’m going to propose that a key feature of a good process is one that has no decision points in the process flow. That’s right, no decision points. A decision equals an opportunity to make the wrong decision and therefore the opportunity to waste time or jeopardize quality.
If a process is to be consistently good, then the last thing you want to do is give an individual (especially software developers) the opportunity to make the wrong decision.
I’ll give you an example – the creation of an analysis document. Let’s say you have a process which allows the developer to choose either the long (and therefore rigorous) format or the short format for the document. The decision you want the developer to make is “select the format appropriate for the scale of the change.” Which one would you choose as a developer? If you were well intentioned, you might really consider the question. Still, it’s the kind of question you could screw up. The decision is based on judgement and maybe your developer judges it incorrectly. The developer chooses the long form when the short form would have been acceptable and wastes all kinds of time filling out an unecessarily complex document. Or, the developer chooses the short form and thus misses the necessary rigor and inserts a major design defect into production. Either way, the decision allows for the wrong choice to be made some of the time.
What about a not so well intentioned developer? A lazy developer, perhaps. Not that those kind of people exist at your company. Oh no, all your employees are well intentioned all the time…
A lazy developer would always opt for the short form. Maybe s/he doesn’t value analysis or maybe s/he does but thinks writing things down is silly. Who knows, who cares. The short form isn’t always appropriate.
Here’s what I’m proposing. No short form, no long form, and certainly no choice about whether or not to fill out the form at all. NO DECISION! Just have one form that scales to meet the need automatically. I know what you’re thinking. How can that work, we have 246 sections to our standard design document and a developer needs to make a decision about whether each section is appropriate or not. WRONG! Why do you need 246 sections to your document? Do you think each of those sections is critical to success? Have you bothered to figure out which sections, if done well or not well actually affect performance? Probably not. You probably like lengthy forms with nice headers and sections and instructions in each section about how each section should be filled out. You’ve ignored the idea of the critical few – and there are a critical few – that really affect process performance. Everything else is noise.
It is possible, I have done it, to have a single document format, nay a single process, which you follow unwaveringly through new development, enhancements and even simple bug fixes. The fewer decisions in the process, the better.
With that in mind, I propose this measurement of the goodness of your process. To figure this out, you have to get down to the micro level. If associates are making decisions about which sections of a document to fill in, that’s a decision you should count.
Decision density = 1 – (# of decisions in a process / # of steps in a process).
- analysis review
- decision: analysis OK?
- design review
- decision: design OK?
- code review
- decision: code OK?
- decision: test OK?
That would have a decision density of 4 decisions / 7 steps = 42.85%. I’d say that decision density of less than 50% is a good start. The lower the better. There’s probably a better way to look at it, since you might want to weight micro decisions (those decisions made without consultation with a peer or group) as being worse than bigger decisions in the process (like the decisions made after an inspection step).
The short story is: avoid decisions in the process. More decisions means more of a hand-wavy methodology than process.