The Stupidity Threshold

by Krishna on August 25, 2009

Alan Skorkin has a good post about how people tend to use concepts like YAGNI and TDD to justify whatever they are doing, instead of thinking about what they are doing:

Every practice you use, including TDD and YAGNI has a certain threshold which I call the stupidity threshold. While you’re using the practice as a tool giving due consideration to all other concerns, you’re fine. But, as soon as the use of a particular practice becomes an objective in and of itself, you have crossed the practice stupidity threshold and will find yourself in trouble eventually.

Obviously, this sort of behavior is not unique to Agile practices. Take any methodology (in software development or business management) and you will find “true believers” who seem to think that some principle is infallible, even though it was invented or discovered by some human being(s) who are nowhere near perfection.

An amazing thing that I am seeing in the software industry right now is the whole-hearted acceptance of Agile practices by organizations who were previously married to rigid methodologies. Part of it is that Agile has gone mainstream by presenting its practices in the wine bottles that decision-making executives prefer: certifications, expensive consultants, great-sounding names for Agile practices (like Scrum), project management software (with bar graphs and all!)

This is both good and bad in a way. The good thing is that there is no more need to convince people of the virtues of Agile. The problem is that a lot of people (and I mean, A LOT) are coming to Agile with many ideas and attitudes from their current way of working. Prominent among these attitudes is the slavish adherence to processes.

Quality departments in organizations have what is called a “non-conformance”, a red flag raised when some person or department is not following a process correctly. Such “non-conformance” items do not look good when a group is evaluated, and so people try to minimize them by trying to follow every process to the letter, even if it makes no sense in a particular situation. They want to avoid having to fill in all the paperwork to justify any deviation from the agreed-upon process.

So what happens when you bring that mentality to Agile? All you have done is replace one set of processes with another set, and failed to understand the need to provide good business value to customers by building quality software. This behavior is not the exclusive domain of large organizations. Even a small team can fall into this trap by thinking in terms of processes instead of thinking of the overall goals.

The merit of Agile practices is that very talented people have thought about them and found them better to existing practices. But that never means you should leave your brain in the fridge when you start using them in your organization. Use data from your experiences to decide what is working, what should be tweaked and what should be abandoned. Read more case studies of Agile use in other companies and use what may be applicable to you.

Comments on this entry are closed.

Previous post:

Next post: