We're trying to get started with Scrum and I'm not sure how to handle QA in our situation. Like many organizations, QA and product development are separate entities. However, we have QA teams that are dedicated to individual products, so I don't think incorporating them into a Scrum team is going to be a radical change. The odd part is that our QA team is bigger than the development team on the project that's moving to Scrum. We've got five developers, one QA lead, and six QA testers. The QA lead is very technical - a programmer who lost his way. There are two other fairly technical QA folks who are getting into automated testing. The remaining four are not very tech savvy and basically just walk through predefined test procedures.
Currently, QA gets a release every two or three weeks and just tests that until the next drop. We're dealing with an old, horribly buggy codebase at the moment so they have lots to do on each release. We're going to wipe the slate clean pretty soon, at which point we're going to get serious about unit testing. I'd also like to start doing continuous integration and have QA test each bug and user story when it's finished being developed. Hopefully the end result will be a lot less bugs and a much quicker feedback loop.
So with all that said, the question is who to include in the development team. Clearly the QA lead will be part of it. The two people working on automated testing might be a good fit as well since they'll probably be able to make sense of programmer talk and hopefully even contribute to planning and estimation. I really don't know how to handle the other four. It seems like they should know what's going on at all times, but I don't know how much they'd take away from the meetings and including them will make the team bigger than I'd like. But then I also don't want to have hurt feelings by excluding them. What should we do? Try a team of 12 people? Draw the line at eight? Perhaps only include the lead and let him delegate to the others the way he currently does?