In my company, we successfully working with agile practices – but without using iterations. The main reason is that we can't find a clean way to fit in QA in an iteration cycle.
We understand QA as an extra bit of verification to a certain build (release candidate) before this build gets deployed to the customer. The point is to avoid that a single malicious commit damages the whole release. Since you never know which one it is, QA has to wait until all features/commits for the release are in the build. (No famous last words "It was just a tiny change" allowed.)
If QA finds bugs in a release candidate, developers fix these bugs in the respective release branch (and merge it into trunk). When all bugs are fixed, a new build is deployed for QA to re-test. Only when no bugs are found in a certain release candidate, it's offered to the customer for verification.
This usually takes around two to three candidates, about one week, per release. The time to write the fixes is typically much lower than the testing efforts. So in order to keep the developers busy, they work on release N+1 while QA works on N.
Without using iterations, this is no problem because we can overlap the work for releases N and N+1. However, from what I understand, this is not compatible with iteration-based approaches like Scrum or XP. They demand an iteration to be releasable at its end with all testing effort to be incorporated in the iteration.
I find that this necessarily leads to one of the following unwanted results:
(A) Developers are idle at an iteration's end because QA needs time to verify a release candidate and bug fixing work is not fully keeping devs busy.
(B) QA starts working already before first release candidate is ready. This is what is mostly recommended on Stack Exchange. But it's not what my company understands as QA because there is no specific release candidate tested. And the "tiny change" that breaks everything can still be introduced unnoticed.
(C) Bugs are carried over to the next iteration. This is also recommended on Stack Exchange. I don't think it's a solution at all. It basically means that we are never getting a verified build because whenever bug fixes are made, new, unverified commits are added to the same branch as well.
Is there any way out of this dilemma?
Best Answer
There is nothing inherently incompatible between this form of QA and iteration-based methodologies like Scrum.
Within Scrum, the team delivers a deliverable on an X-weekly cycle it its customer. The important part here is that, if the development team is doing Scrum, then their customer is the QA team, not the end-user of your product.
As a developer, I would consider a product shippable to QA if it has a fighting chance of passing all their tests. This probably means that some of the QA-tests have already been executed on the daily builds, but how that affects the official release tests by the QA team is up to your organisation.