Notes:
Agile methods provide a mixture of techniques and meta-techniques for developing software. Like design patterns they need to be understood both in terms of the configuation of forces that make them appropriate and in terms of the desirability of the resulting context.
The general theme is the removal of work products and/or procedures that would be damaging to a project. I've already indicated what this implies for the initial context – but for the resulting context it also has implications.
For example, XP – when implemented as described in “Extreme Programming Explained” this produces no long term documention beyond the code. This is a problem for projects that move into a maintenance phase (and led to the failure of the C3 project after the initial team moved on).
Whenever you lose a work product you have the potential to lose two things: visiblity of what is happening on the project, and something that is serving a purpose outside the project team.
Any software development process required dicipline of the team. Some of the simpliciations to procedures that are recommeded simply shift the burden of dicipline to the developers. If the developers you work with don't buy-in to the need for self dicipline you'd better have some processes or roles in place to compensate.
When developers are used to a highly regemented regime it can be hard for them to adapt to the responsibilites of a less structured process. They cannot just assume that an issue they become aware of is someone else's job – they have either to deal with it or raise it with someone that can.