Many organizations implement "Agile" without understanding it. Agile is not a methodology. It is a philosophy, expressed by http://agilemanifesto.org/ . The intent of Agile is to rewind back to what worked during the 70s and 80s. The authors of the Agile Manifesto are all people who were around then. It is well documented that large software projects with detailed up front requirements have a very high probability of failure. Agile merely advocates a return to common sense, including:
- 1. Dividing the work up into smaller loosely coupled projects, and small features that can be implemented individually.
- 2. Allowing requirements to change, in recognition of the fact that users often don't know what they need until they see something working.
- 3. Testing as you go, instead of all at the end, based on acceptance criteria.
In the case that you describe, it sounds like acceptance criteria were not defined well.
Well run Agile projects do not abandon quality or non-functional requirements, detailed requirements, or design. What is different is that these things are allowed to evolve over time, through a process of refinement; but if no one is orchestrating that process, then indeed junk will be produced.
Many organizations are confused about how QA relates to Agile. Agile does not dispense with QA. If you search online, you will find a-lot of discussion of that. It is true that some in the Agile community do not understand the need for QA, but the more experienced and rational ones do. I can offer the following four-part article on Agile testing the way that it is done in many real organizations that do it right: http://www.transition2agile.co...
Isn't it ironic that a great percentage of the programming that occurs today is for using the Internet to enable online commerce, collaboration, and business? And yet the Agile community (of which I am a member, and believe in Agile - although not ever single idea or practice) shuns distributed teams - the very technology that we build.