The pros and cons are typically thought of as intrinsic properties of Agile in general. But they are not. Agile has a number of assumptions regarding organizat

The pros and cons are typically thought of as intrinsic properties of Agile in general. But they are not. Agile has a number of assumptions regarding organizational culture and the people involved on the project. Those assumptions are usually not discussed very often, which is bad, since I believe they are typically related to those many cases of failed Agile implementations that end up getting different explanations depending on how one likes/dislikes Agile. To summarize what I'd like to answer about your question: Pros: - They are great tools to break larger projects into smaller chunks and to keep track of their progresses. Experience shows that it's easier to reach success on smaller projects, and sprints and daily meetings are ways of emulate such sort of project even when working on larger ones. - There's an opportunity of catching and fixing schedule slippages, requirements misunderstandings and other sorts of deviations before they get too expensive to fix. Cons: - You need a bigger deal of maturity and commitment of people involved. As IT professionals, we usually complain about users being unprepared for working on Agile projects, but we have to admit that many professionals show a significant decrease in performance when they are not under a certain level of healthy pressure. - When you favor people over processes and communication over documentation, a higher level of mutual trust is required. You can't find that everywhere, for a number of reasons. Some say that such organizations are not prepared to work under Agile rules. Some are more pragmatic and adapt. I stick with the latter. Agile talks a great deal about embracing change on requirements, and I don't see what is the point of being a purist and refusing to adapt the method to deal with risks.