Agile QA: 1 Team or 2?

We've been having an interesting discussion internally about whether our development and QA groups should be part of the same agile team or seperate with a half iteration offset. So far we've developed a list of pros and cons to help us decide where to go.

1 Team Advantages

• Development and QA are always in sync (i.e. working on the same stuff at the same time).
• QA can play the customer proxy/advocate role to help define stories and acceptance tests ahead of development. Essentially increasing the ability of the customer to get more done (especially helpful when the customer is busy doing "real" work).
• Developers can assist QA execute tests, effectively dynamically increasing the QA staff on demand.
• When the iteration is over, all the code works and the acceptance tests run.
• Singular focus for the entire team.

1 Team Disadvantages

• QA typically gets releases late in the iteration making it difficult to run all acceptance test before the end of the iteration.
• Some QA engineers are not interested in being the customer advocate and doing requirements gathering, etc.
• Some traditional QA activities such as exploratory testing are not well supported.
• Some types of testing (volume, capacity, and other stress tests) do not fit within the iteration.
• Estimating QA activities is difficult at best, since time spent exposing issues depends directly on the specific developer writing the code as well as replicating issues that are data dependant are often time intensive.

2 Team Advantages

• Development has produced most of the code when the QA iteration starts.
• QA can focus on more traditional tasks.
• QA tasks for the iteration are better understood.

2 Team Disadvantages

• QA cannot represent the customer since they don't see the stories until after the developers have started them. Thus the customer needs to have good acceptance test writing skills.
• QA and development are working on different tasks causing lots of context switching for developers when bugs are found.
• 2 teams have slightly different focus causing friction when "old" code has issues.
• Development needs to branch the code base at the end of each iteration and apply bug fixes against the branch and then merge the results at the end of the QA iteration.

I am generally in favor of the 1 team approach, but the issues such as late build delivery make me feel for the QA folks trying to get their job done. Perhaps as we get better at continious integration and no-touch deployment this will get better. Others have suggested using both models to get the best of both worlds by having the seperate QA team focus on testing other than acceptance tests and we will probably try something like this.