I think a good elaboration would be that for a project to build an Address Book is still a project to deliver an Address Book regardless of Agile or Waterfall or Scrumfall. You still have the same exact steps to execute, Agile just organizes the work differently than a Waterfall project, biting off a small piece of requirements, building the "vertical" of say what a contact form looks like. Waterfall would define the entire app first, hand off to development, etc. Both can fail for the same reasons though, poorly defined requirements, lack of funding, personnel issues, etc.
Not sure this is a good elaboration - if you know exactly what you want to build, then you're not agile. The point of being agile is that you start off building towards an address book, but along the way you discover that actually what your customers want is something slightly different - so you change the direction you're going in.
Agility allows you to follow your customers. If you have a fixed requirements - "we're building a product that does A,B,C and it looks like this" - then you're not agile, and as I point out in the post, agile is NOT a project management methodology. You can use SCRUM, XP, whatever - doesn't make you agile. (And it won't make delivery any faster, just more annoying, as everyone around you will assume it should be faster, and will constantly bang on about why nothing's happening yet.)
Hard to agree here. In my experience waterfall and agile projects fail for completely different reasons.
Waterfall projects fail when they are too rigid and try to define everything beforehand without leaving any space for iteration. The reality checks come too late when it's not easy/possible to change direction any more.
Agile projects fail when they are too loose and no one is actively taking responsibility for the bigger picture.
you need to produce requirements, make a design, create plans, implement code, test, deploy and all that -- it's the same if you're doing waterfall or agile, you're just sequencing these activities in time differently.
if you look at the project management body of knowledge (PMBOK) you find a comprehensive list of things that have to be done to make a project happen and this list isn't any different for agile or waterfall... it's just the answers for how certain things are done (communications in the team) for instance are different.
One advantage of agile is that all phases of project management are going on in each cycle, so you don't run into the problem that now you're testing after five years of doing everything else and now you don't have any idea how to do it.
On the other hand, you can screw everything up in an agile project the same way you can in a waterfall, although the symptoms show up differently. Since you're testing every phase of the process, problems will show up earlier. However, it's easy for people to miss them.
In an agile process, for instance, you can plan a sprint and accomplish the goals you set for the sprint and feel like you're doing a great job. However, the sprints might never end and the product never gets delivered. All your PM tools tell you're winning all the battles but you're still losing the war.
The key difference, IMO, is that true agile doesn't require overt project management or more importantly, project managers. the usual response to the "wining battles, losing war" is to introduce someone who's keeping track. unless that someone is "everyone on the team", you tend to move away from agile because:
a)its not everyone's problem, so its not going to be fixed, or
b)the pm guy becomes the fountain head of knowledge from the pmbok that guide the "one true way"
if a project goes beyond a certain size, somebody has to be in charge. you could build, say, the Dallas Cowboys stadium, without a project manager who heads a project management office.
if your project is small enough that "everybody is in charge" and you've got the consensus to work that way you're not talking agile, you're talking magic... and you're going to be 3-10x as productive as a conventional "team"
Project management is project management; ultimately you need to do all the same things to succeed, it's just a matter of how you organize them.
In the big picture, Agile projects fail for the same reasons other project fail, and they succeed for the same reason other projects fail.