In TemporaryCargoCult, the problem is stated as:

''A project needs to use something nobody understands.''

I claim that many methodologies are in fact cargo cults, and that the heavier
weight the methodology, the more true that is.
However, it's deemed to be necessary to produce a good product, so the methodology is officially adopted.
In practice, the programmers just write the code like they always do.
Whenever QualityAssuranceAccreditation time comes around, there is a flurry of
activity writing up documents that nobody ever needed before.
BUT, because we say we're using a methodology, when the project succeeds, that's because of the methodology.
When the project fails, that's because we didn't follow the methodology. 
(Long ago I argued with RonJeffries about this on ExtremeDiscipline.)
I claim that the facts that a methodology needs to be chosen, and that the documents it requires are not otherwise needed, make it a CargoCult.

However, I do not want to claim that all methodologies are like this.
XP and CrystalClearMethodology appear to be evolving toward the sort of
methodology which really are useful.
My first experience with AlistairCockburn was with a UseCase template, which has fields for 20 different things, and I thought it was stupid.
Now that I have read MethodologySpace and CrystalClearMethodology, I think Alistair must be a very clever person.
My hypothesis is that, being a very clever person, Alistair has been moving away from heavyweight methodologies to lightweight ones, and that is a good sign for the software industry. 

--JohnFarrell

''(Note from Alistair: I have never subscribed to heavyweight methodologies, so there has been no such movement in my case. The template was taken from a real 45-person, 15M$ fixed price bid project, run using an extremely lightweight methodology. Yes, it looks heavy to those not on such a project, and yes not all the fields would be used on a smaller less critical project bid, etc as described in the use case book. There is possibly a lesson here for people to learn who have never been on a significantly pricey project. end note.)''



Though I never met the ''UseCase template with fields for 20 different things'' version of AlistairCockburn, a recent meeting with the current version suggests that he has become very clever through doing something very different from anyone else: visiting many different kinds of software project and writing down honestly which methods are working and which aren't. For some of us this defines what MethodologistsOfTheFuture are going to look like and is as good a sign as we could hope for from the industry. -- RichardDrake

I agree with the title of the page and the other thoughts expressed so far (judging from history, the safer assumption is that the methodology/methodologist is wrong, and the burden of proof is on the methodologist).  ''(p.s. I appreciate the kudos here, thanks, and do hope to set a trend for how "methodology" is done, namely as a technically demanding social science)''

I.e., Yes there's a CargoCult out there, and No it's not all crap, and Yes it's extremely hard to distinguish the crap from the non-, and No most people can't do that, and Yes it's important, and NO it won't go away, and Yes the arguments go around in circles, and No I don't have anything more useful to say in this paragraph.... --AlistairCockburn


----
The primary purpose of "methodology" is to give managers something to talk about as they can not discuss the code. One of the side effects of a good methodology is that it gives developers something to talk about besides code, which is expensive to create and hard to discuss due to its level of detail -- Often this actually helps the developers. When it does it is clearly the part of the method that is " not all crap" So the mission, should we chose to accept it, is to find out what that is useful and what is not. Here lies the rub-- it is the developers and the developers only who can determine what is or is not useful, but it is still the fact that the dominant user of the "methodology" is management. Management has no idea what is or is not likely to be useful, but they and other stakeholders are often the only voice in the debate, and more often than not the sole vote.

Most mature technical professions have a self-regulating standards body, if a profession, or a Union if a trade, to prevent ill- informed or negligent management from proscribing foolish or dangerous work rules and procedures. The software profession has none, or at least none that is effective. When and if the software profession matures, we will know it because the practitioners, licensed or otherwise, will be specifying the methodologies and standards. Until then we are a the mercy of management and can, therefore, expect no significant gains in the productivity of programmers or the reliability of software.  


Do you think I overstate my case? I would not disagree. I am doing so to spark debate. Not about one methodology over another or even the benefits of methodology, but rather of the criteria of making that assessment, and more importantly who should be making that judgment.

Marc Grundfest