I see an important difference between Kent's admonition and prescriptive methodologies. Prescriptive methodologies deliver predetermined ways to avoid certain kinds of problems. The prescriptions (when they solve any problems at all) often solve problems that you don't have, and neglect problems you do have.

Kent's suggestion seems to me to be more about learning how to prevent future occurrences of the kinds of problems that are necessarily relevant to your work. And in particular, it guides us to correct process problems.

If prescriptive methodologies prescribed that we learn how to correct process problems, then we'd quickly learn how to adjust the prescriptions to our own needs.

Dale

<blockquote>Ummm, isn’t that what the prescriptive methodologies try to do by adding more process?</blockquote>

<p>True - but adding top-down high-ceremony lotsa-documentation process isn't the only way of solving the problem. "Individuals and interactions over processes and tools" and all that :-)</p>

Dale - I agree that the spirit of what Kent is saying (actually the manner in which you view anything about software methodologies) is more toward the agile view, but you have to take into account who Kent is when he says this. That's the problem. Later on, this could be misconstrued in a manner similar to the traditional methodologies. I would suggest making sure that whatever we say is always agile regardless of who said it, but in the exact context of the writing. The paragraphs around this don't let you know that you should not implement additional processes to make sure you don't make this same type of mistake again.

Adrian - I agree with you. I disagree with the quote in that it says "make sure you don't EVER make the same mistake again." The only way to absolutely make sure you NEVER make the SAME mistake again, is to add some small task to check for that error. You combine a bunch of these small tasks and you get a really large, process-oriented approach to making sure you don't make mistakes. You end up spending more time avoiding mistakes than the time it would take to correct a single mistake.

I know that's not what Kent really meant, but like I said in response to Dale, if you don't know who Kent is and what he believes etc., then this quote could send you down the wrong path.

Darrel,
I see Kent's statement as entirely consistent with Agile. Sounds to me like he's saying that we should learn from our past mistakes empirically, rather than prescribing defined processes up-front to prevent them from happening in the first place. To me, this is Scrum 101 "Inspect and Adapt".

Victor - but making sure to never make the same mistake again can only be done by adding a task in the process. And adding too many tasks to the process is how traditional processes became so "heavy" to begin with.