For what task? In what language? For what purpose? With how many other developers? With what organizational constraints? With what time constraints? With realistic expectation of code re-use? With what other constraints?

The methodology used should match the task at hand.

Scripting a one line throw-away in Perl for your own personal interests is very different from working on a multi-person team doing OS development which is different from research done with taxpayer's money which is different from safety-critical software engineering which is different from military applications developed as a state secret.

Each environment will have it's own requirements, it's own paperwork, it's own QA requirements, etc. Some of them will have other special requirements as well (military clearances, document handling rules, formal audit trails, signoffs, confidentiality requirements, etc, etc.)

The level of paperwork and the level of quality assurance required will determine the appropriate methodology; a slapdash (but very "agile"), "fix it if it breaks" attitude works great for personal web sites, but would be a disaster for work on, say, a nuclear weapons control system.

Even if you're just writing scripts in Perl, what you need to do often determines how you do it; if every release to production requires formal sign off from management in triplicate, your team will probably make fewer small changes, and spend more time testing each change than if the environment is set up for fast turnaround of development and promotion.

The way I work is mostly determined by how I'm allowed to work; if the boss needs/wants something done a given way, well, it's his money...