Sigh... I've been in IT long enough to see so many methodologies come and go that I've long since given up caring about any of them.
The methodology is the end product of a work culture which is an end product of the business itself. You can no sooner transplant a development methodology from one business to another anymore than you can transplant a monastery's methodology for making cheese for an life insurance company's methodology for selling policies.
I can recount one project in a business I once worked for. According to an IBM study of successful startups a 'Rapid Project Development' methodology was created. Some of it's key elements were tight working conditions (elbow to elbow desks), drop dead deadlines (deadlines are never pushed back, ever, for any reason) and work 'till it's done schedules (overtime, overtime, overtime). Now when you're fighting with your savings on the line to bring a business you're passionate about to life with your like minded buddies, you'd do all of these things and then some without giving it a second thought. Not the least of which the rewards would be wilder than your dreams could imagine. Now this same 'highly successful' methodology was transplanted into a more than 80 year old, heavily unionized IT work environment. People who could barely stand to spend a day with each other in separate cubicles were now stuffed in each other's personal space day in and day out, with threats of impossible deadlines and forced overtime. Perhaps there were a few of employees who were actually IT trained and even fewer of those with a natural ability in the field. Largely the employees were re-trainees over the years who ended up where they were based on seniority alone. And the reward for using this methodology? Cars? Expensive Homes? Vacations in the tropics? No, the reward was more of the same year after year until retirement. Needless to say, the methodology bombed horrifically at this business.
Never trust anyone quoting best practices...