Non-technical testers on a Scrum team

Question

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?

Answer 1

Include everyone.

It won't be a very functional team because of the likely pipelining of tasks which is characteristic of this kind of teams.

That said, it will still be a better team than the alternative. Keeping QA out of the team seems to only increment pipelining and disengagement.

In other words, you want to maximize communication and self organization within the team. The best way to do so is putting everyone working together and helping them help themselves.

Answer 2

Following Scrum framework you need to add anyone who is involved in project development & delivery and lets call it the scrum team instead of development team.

Scrum calls for a multi-disciplinary team which works together having open communication channels between each team member. Some Scrum followers would suggest a small team (preferably limited to 8 or 10) but a 12 member team can work too even though it would cause many communication channels but the alternatives you have mentioned will take you to ScrumBut. You don't want someone who is responsible for task delegation in a scrum team as Scrum suggests a self-organizing team.

Regarding the four testers, they need to be part of the planning meetings as it will give them the required 'big picture' of the project as wells as clear idea of sprint objectives so that they can create or execute appropriate test cases. Having them part of the team would help in minimizing the 'pass the blame' game. Moving forward, team could set a goal to raise skill level of each team member so that they can provide more value in the long-term.

In a scrum team everyone is an equal partner there are no lesser roles or less important team members.