It's easy to see how some people could get the wrong impression from a superficial reading about agile methods, and come away believing there's absolutely no documentation at all, or that there's no design at all, etc. To be successful with any approach you have to understand what it's all about, and not just believe in some myths about it. After that, you have to apply the approach to the right sorts of problems. The best slotted screwdriver in the world can't turn a Philips-head screw. Finally, you have to apply the approach rigorously and knowledgeably. Fail on any of those three counts, and it's Game Over. Far from being like cowboy programming, agile methods actually demand quite a high level of self-discipline on the part of practitioners. Typically, your day to day activities are not tightly governed by a formal process, you're not closely supervised, and there are no third-party code reviews. If you're sloppy about the work, things fall apart pretty quickly. Agile methods demand self-managing teams. It's no mystery what will happen if the team fails to step up to the plate and manage itself. Culturally, this is one of the biggest obstacles to overcome in introducing agile methods to an organization. People are used to being told what to work on, and then being judged by some external authority. They're not used to being enabled to act on their own professional judgment, and then held accountable for results. Scary? Sometimes. Exhilirating and empowering? Always. In that general sense, I guess agile methods are no different from any other approach. If you don't understand your tools, or you use the wrong tool for the job, or you use the tool improperly, then naturally your results won't be so good. The question is, what will you do next? Blame the tools?