Traditional software development methods typically create software in stages - Planning, Analysis, Design, Code, Test, Ship. This staged "waterfall" approach is known for being rigid and slow and as a result it is difficult to get things right. It prides itself on documentation created at each stage and is a very structured way of building software. The problem is that it doesn't work.
Agile development on the other hand is all about prototyping, black boxing, and figuring it out as you go. It is known for rapid application development and usually involves a team full of superstars that can each do it all. The problem is that is doesn't always work.
In todays world of offshore development, cultural and language differences and skill shortages, there must be some happy medium. It's hard to have a daily stand-up meeting (Agile/Scrum) with team members distributed across the globe in four different timezones. It's tough to figure it out as you go when your team is asleep on the other side of the planet. There must be some requirements that are documented and analyzed and designed in advance. There are others that can be done in quick "sprints" so that results can be demonstrated as you go. But you don't want it to take forever because requirements change and the likelihood of that increases the longer you take to get the job done.
To the waterfall purists, I say "get real". To the agile purists, I say "wake up". Because at the end of the day, it's not about waterfall or scrum or any particular methodology. Instead, it's about deciding what works for you and your team and constantly adjusting and improving so you can delivery high quality software in record time. There are good things about all methodologies - it's up to you to figure out what's best for your particular project. And for me it's a combination of Agile Scrum and the Waterfall approach - I call in Scrumwater. It involves designing and hashing out some things in advance. It involves some documentation to help all team members, wherever they are. It involves building the software in sprints. It is 80% agile, 10% traditional and 10% "I don't know what".
And on the next project, it'll probably be a little different.