Agile, in whatever form, has a set of core practices - iterative development, unit testing, continuous integration, etc. You can, by all means, choose not to include one or more of these core practices; but you better make damn sure you fill the gap with something else or you're headed for big trouble.
For instance, one core practice is the creation of acceptance tests for each story (use case) at the same time, or before, the story is being worked on. These acceptance tests are often created by test professionals who form part of the team. If you don't do this but instead see testing as seperate to development, then you need to do something to plug the knowledge gap. The testers are not going to know what to test. How can they? They're not involved in planning or daily stand ups. The usual response then is that "Agile doesn't work for testing because it is document-lite." Wrong, agile is document-lite because everyone is involved in the development process. Take that away and you have a gap. A gap you must fill. In this case by writing up your stories in detail for the testers to test against.
You see, the agile core practices work together, so that the whole is greater than the sum of the parts. Take one of the parts away and you may very well find the whole is broken. At this point you may decide agile doesn't work. Not true, you broke it!
Building a query parser over a weekend: Part II
5 hours ago