Many things have already been said about the two methodologies, so consider these lists my own, subjective opinion.
- Early customer involvement: end users can have an enormous impact on the final product; product backlogs, demos, early feedback loops, all make it possible for end users to have a say about the final product.
- More efficient communication. agile is all about communication: sprint plannings, daily standups, retrospectives; all these meetings are meant to share information, update each other and make the whole process even better.
- Faster product development. Being an iterative process, agile tries to deliver increments which are valuable to the business. These minimum marketable features make it possible for end users to start using the product in as little time as one sprint (in an ideal case).
- In real life situations, it is pretty hard to abide by the “no change to the sprint backlog” rule. Business priorities change fast; thus the backlog has to change too, causing smaller or larger scope changes. (Kanban can address this issue, but many people consider it a Lean methodology, rather than Agile)
- Hard to take full advantage of it most of the times. Startups may benefit the most of agile, but in cases when releases have to be carefully planned and executed (banks, insurance companies, telecom companies) only parts of it can be implemented.
- High emphasis on product, principles and people rather than rigid processes.
- Agile encourages empowered teams, which can boost productivity as team members are allowed to take decision and act on them.
- Geographically distributed teams cannot make full use of agile due to communication difficulties, cultural differences or client-vendor relationships.
- The focus is far from being placed on documentation in agile. This can make it hard for new team members to join a mature product (many times agile projects employ ad-hoc documentations only, using wiki pages).
- Possible dissatisfaction resulting from the mixture of traditional and new ways of working, roles and points of view.
- Engineered way of software delivery by engineers, for engineers. Very rigorous planning up front aims at eliminating bugs right before they get introduced. In theory, this can result in major bug free implementations.
- Phases do not mix, so it is always obvious what phase the project is in. This way the project lifecycle is easy to understand, staffing needs are clear.
- Analysis-paralysis: in a traditional waterfall setup coding cannot start until the analysis phase completes. For a large enough project, this can take up extremely long time. Such a way, no fast results can be delivered.
- Due to the hard constraints of the phases, it is somewhat hard to add a new feature or requirement once the analysis phase completes. This way the customers have to think well up front about their needs and there is little room for change.
- Keeps engineers disciplined and focused: rules are much harder to break than in agile.
- Provided it is done right; Waterfall can minimalize waste. Since analysis and design are done much before any code gets written, in theory, it is ensured that no unnecessary software (in terms of features) gets created.
- Too much effort is put into the process itself and values and people are not explicitly addressed.
- Too rigid for many industries: web based development, games development (entertainment, in general), startups are prime candidates where waterfall may be too slow to work with (except for several games, which are released only after 5-10 years).