There's a lot of talk about Agile development in the software world. Basically, this means that instead of planning big projects by figuring out what's needed, and then methodically building it, you take baby steps. You set small goals, and have teams work their butts off to achieve them in a few days or weeks, with frequent brief meetings to keep everyone on track. There's more to it that than, but that's the high-level, non-technical, other-hyphenated-adjective view.
So what's the point? The point is that things change too fast for classical long (e.g., 12-18 month) software development projects. In the Web market particularly, companies have to react almost daily to changing technology, changing demands, viral cults and fads, etc. Plus, the ability of the Web to deliver upgrades continuously or nearly creates the expectation of constant newness. In theory, atomizing development into projects of a few days' or weeks' scope helps companies be more reactive ... agile! Get it?
The only problem is that for all its flood of buzzwords (agile, sprint, scrum, stand-ups), Agile methodology (actually, methodologies, as there are already multiple factions with the Agile development world), really just boils down to: do small steps quickly. There's no new idea here. The difference between Agile and more traditional methodologies is one of quantity, not quality.
Also, many of these methodologies are observed only by lip service. This approach is so trendy that everyone wants to be a part of it, even if only by renaming their status meetings stand-ups, and their now much abbreviated project cycles scrums. I know one place that holds stand-ups in a comfortable lounge area. Everyone sits.
I can certainly appreciate the goal of formalizing development methodologies. I've seen plenty of utterly chaotic organizations. But in those places where the methodologies are formally applied, they often become more of a hindrance than a help. There's only one methodology I've seen as universally successful: Hire good people!