Scrum != Agile
Full-bore agile is the only software-development process I know that actually works (and believe me, I've tried many). Nonetheless, I'm afraid that Agile might go the way of the dodo. Think about OO, which was pronounced dead several years ago. Those who put OO in a premature grave, however, usually aren't doing OO. Their ad-hoc if-I'm-using-an-OO-language-and-following-the-vendor's-rules-it-must-be-OO methodology is now eating brains in the cemetery at midnight. Don't confuse what they were doing with OO, though. Real OO is valuable.
Which brings me to agile. More and more lately, I've been seeing the press (including some parts of the press that ought to know better) saying things like "Scrum—the most popular of the agile methodologies..." This equating of Scrum and agile is worrisome. Scrum and agile are by no means the same thing.
First of all, agile in the true sense of the word (flexible, innovative, customer focused) is a culture—it's something that infuses the whole organization. It's not a process, and it's not limited to the engineering department. That's one of the reasons that I don't like to use capital-A "Agile." Agile should mean "agile," as in English, as in "able to move quickly and easily." It's not Agile(tm). When the company can move quickly and easily, it's agile.
So, let's look at how a culture mismatch can subvert agility. If an agile team needs some sort of resource (software, training, whatever) to complete the current development iteration, they need it right now. If, however, your organization puts massive delays in the process of acquiring that resource—sign-offs up the management hierarchy and six weeks to cut a check, for example—the team simply won't get the resource soon enough for it to be useful. So, engineering can't function in an agile way if the finance department isn't equally agile.
Another example: An agile philosophy implies short release (not development, but release) cycles to get feedback from real users as soon as possible, and that feedback should immediately feed into the next iteration. If an organization releases semi-annually, or even if there's a three-week delay while the finished code wends its way though production, you won't get that feedback soon enough.
Without a company-wide culture, no agile process will work. Which brings us back to Scrum. Scrum is not a culture. It's a process. So, Scrum won't work outside the context of a supporting culture.
Moreover, Scrum isn't even a complete process. Take XP, which is a full-blown process to my mind. XP is made up of 12 interlocking practices. One of those is planning. Scrum is little more than a formalization of the XP "planning game," which is to say that it represents 1/12 of the full process. Kent Beck pointed out in his "Extreme Programming Explained" that the practices that make up XP are tightly interlocked. For example, if you're not doing pervasive and early unit testing, it's difficult to refactor safely. In fact, Beck said, if you're not doing at least 80% of XP, you'll see only 20% of its benefit. You can't cherry pick the practices you like, because the practices influence each other. And I'm not even talking about how engineering-department processes interact with other processes in other departments. If what you're doing is Scrum in isolation, you're down in 20%-effective land (or lower).
This doesn't mean that Scrum isn't valuable, but it does mean that Scrum can't stand alone. Without the culture, Scrum will fail. My fear is that people will look at the many failed or dysfunctional Scrum shops and start saying "agile doesn't work." That's the danger of imagining that Scrum and agile are equivalent, and we need to push back hard whenever we hear somebody say that.