I think its true, in some environments Agile is used as an excuse for no discipline. The real problem is we've lost sight of why we have any methodology. Personally, I feel the methodology is an architectural issue in the sense that the architecture of the system is supposed to address the non-functional, quality attributes, the methodology should be addressing some of those same attributes (maintainability, development productivity, knowledge transfer, et al.)
Viewing the methodology as a control for the process attributes implies a couple of things: 1) without metrics we cannot compare the effectiveness of one methodology over another, 2) an active decision needs to be made about what attributes are important (delivery time vs code quality vs knowledge transfer).
Without having both metrics and a tangible goal, we simply choose a methodology as our "magic feather" that if we hold on to tight, we'll be able to deliver software.
Now the nay-sayers of Agile, XP, Scrum, etc talk about the fragility of that particular category of methodologies. The argument being: why use a methodology that can be sabotaged by one individual lacking the discipline to follow all the rules? The question is a valid one; however, that is the symptom, not the cause. If an accurate and meaningful (that's the hard part) set of process metrics are defined, tested, and timely feedback given I think we'll discover the particular methodology has little to do with success. (Anecdotally speaking I've seen successful projects using a myriad of methodologies and twice as many fail using the same methodologies)
So what are the metrics? They vary from project to project, team to team, and time to time. Useful for when the delivery schedule is important, one that I've personally used is estimation skill and quality. Most developers can accurately estimate tasks that are a week long or less. So one approach is to divide up the project into tasks one developer-week long and track who made the estimation. As the project goes along, they may change their estimates. After a task is complete, if its off by more than 10% (1/2 a day) we treat this the same as a bug - we identify why the estimate was off (i.e. a database table wasn't considered), identify the corrective action (i.e. involve the DBA in the estimation), and then move on. Using this information we can create metrics such as # of estimation bugs per week, # of bugs per developer, # of bugs per KLOC, # of bugs per developer-KLOC, etc. Posting these numbers on the team wiki provides serious social pressure and from the managerial perspective, after a couple of weeks, you can generate a predictive model of subsequent development weeks.
So what? That's when the methodologies come in - if you have a predictive model that fails to meet the process qualities, you can choose to add or remove some aspect of the methodology and see how it affects your model. Granted, no one wants to play with a development process for fear of failure, but we're already failing at a consistently high and predictable rate. By making individual changes and measuring the result you may find that Agile is the perfect methodology for your team, but you could just as easily find RUP, waterfall, or just a hodge-podge of best practices to be ideal.
So my suggestion is lets stop worrying about what we call the process, put in place checks that are relevant to our development process goals, and experiment with different techniques to improve that process.