Software development process is unpredictable: for trivial application, the unpredictability is low, the lower the triviality, the higher is unpredictability. Even with more or less trivial applications, there is a chance the project would not be completed on time and under budget or fail completely. There is only one way to reduce the risk of failure - intensive design and code reviews, coupled with bottom-up testing and readiness for discarding the erroneous code. Unfortunately, it implies the understanding of the software on the part of low- and middle- level management and make time estimation almost impossible, but in the software development industry people are not promoted by their development competence and missed understanding of software is frequently replaced with out of limb time estimations
This unfortunate result is situation where the software development process reminds driving by the blinds. Under these circumstances, the managers are in dire need for excuses for failures that appear to them as completely random and unpredictable: the demand for excuses fuel the industry of "software development methodologies". From the point of upper management, as long as middle management employs fashionable "software development methodology", the budget overruns and utter failures have nothing to do with management incompetence, but appear to be an acts of god or any other force majeure.
There is also a related stupid dream, shared by management: turning the software development into industrial process. Almost any willing person can be trained into machine-building floor worker; substantial majority of people can be trained for clerical jobs, so it looks reasonable for ignorant people to imagine the software developers being separated into "software architects" and "coders" - where "software architects" imitate engineers in traditional industries and "coders" expected to behave like workers. The "software development methodologies" then are expected to be applicable to the "coders" in a way similar to a project management in traditional industries, with exact time estimation.
The problem with this stupid dream is that separation software developers into "architects" and "coders" ignores fundamental nature of software - first, if we look at software as an hierarchy of abstractions, there is no level where design become irrelevant and implementation is trivially deduced from higher-level designs. Second, it is almost impossible to come up with correct high-level design before implementation become available and unforeseen issues arise.
For the medium and big corporations responsibility evasion maneuver is executed best when outsourced to the external consultant: the auxiliary consultancy industry creates the environment where new "software development methodologies" spread like plague in medieval cities - as only "methodologies" in current fashion deliver proper and reliable shield from responsibility.
Unfortunately, as "software development methodologies" are manufactured for the dual purposes of evading the responsibility and imaginary control, the methodologies don't materially reduce risk of failures. Therefore, the "software development methodology" fads usually wear out within several years, only to be replaced by even more outrageous and stressful system.
Buzzword treadmill describes the process of replacing worn-out harmful "software development methodology" with new one.