What happened to your formal test teams when you adopted scrum?

As my organization has adopted Scrum, I've observed we've formed scrum teams with perhaps 5 developers and 1 formal tester.  There's always tasks on each PBI that require that 1 formal tester to test the software.  From my perspective this approach is a step in the right direction but still feels anti-scrum.  1.) It emphasizes to the team that this one person is responsible for ensuring the quality of the code as opposed to the whole team.  2.) It creates bottlenecks since the developers are not allowed to take the final testing tasks.

the whole dev team is taking responsibility for the tasks that are done by them. Remember that there is no "formal tester" in SCRUM. People from dev team can have specialization but everybody should take as much effort as possible to make each task "DONE" according to the "done" definition. First step you should make is to forget about "formal tester", implement testing as part of the "done" definition and let the team to make proper adjustment to their work. They should be self-organized, don't tell them how they should work, they know

There is a testing department in our organization. In scrum projects, testers are part of the development team (in waterfall projects they are working individually). Testers in scrum teams are supposed to be involved in software development process. Some testers are lucky because they have software development background. It's not easy for others to learn another profession but they started learning (at least they are writing some scripts). In the long run, it's expected from all development team members to be capable of analyzing, designing, developing and testing the product.

Dawid, from your response, I take it you no longer have a formal test team.  So my question was...  What happened to your formal test teams when you adopted scrum?  Did your organization re-train all of your testers with basic coding skills so that they could be incorporated into the Scrum teams?

As others have pointed out, on a Scrum development team, there are no roles other than development team member. Everyone on the team is responsible for the quality of the team's output. We also usually say that the development team is cross-functional.

What does that mean?

A common answer is that you cannot have people on this team that do only testing, because in that case they could not be held responsible for the rest of the work.

Allow me to propose an alternative interpretation: It's not because you have the responsibility for something that you, as an individual, will be the one doing it. Take, for example, a general contractor (in construction work). They are usually held accountable for the entire construction project, even though they probably don't have the skills to do the plumbing or electrical work themselves. The contractor (in a very hierarchical manner in this case) will ensure that he has reliable people on his team to do this work.

On a development team, the team members may decide that a certain individual, because of their particular expertise in quality assurance and lack of experience in other areas, will focus on the quality assurance work. When that decision comes from the team, you have self-organization.

Responsibility doesn't mean that the QA-experts will have to learn coding so they can pitch in to that as well (although that's not necessarily a bad thing); it means that the QA-experts are just as responsible as anyone else for making sure the team can get the coding work done. If the team is unable to do so, then a solution must be found collectively. That solution, whether it is to have the QA-experts start coding, to ask the organization to bring in another developer, or anything else, must come from the team, and it is the responsibility of every team member.

Now take the hypothetical situation where the team realizes they have too many dedicated testers who are not qualified to do anything else. Traditionally, a manager would see this, realize the team is weakened as a result, and force a solution upon the team (move some of the testers to another team, or send them to training, for example). On a self-organized team, this decision must come from the team. Personally, I've seen people who realized their particular skills were not relevant to a project ask to be transferred to another team where they would be of more use. This kind of decision, of course, like all self-organization, requires emotional maturity.

As my organization has adopted Scrum, I've observed we've formed scrum teams with perhaps 5 developers and 1 formal tester.  There's always tasks on each PBI that require that 1 formal tester to test the software.  From my perspective this approach is a step in the right direction but still feels anti-scrum.  1.) It emphasizes to the team that this one person is responsible for ensuring the quality of the code as opposed to the whole team.  2.) It creates bottlenecks since the developers are not allowed to take the final testing tasks.

 

Correct. A team is notionally created but teamwork is compromised. This is a problem which will not be solved overnight, and there has to be an organizational shift towards valuing people with T-shaped skills. A significant and neglected part of this journey is to hire people with these broad skills instead of recruiting to an old job spec.

As an interim measure, an accommodation may be reached. For example test specialists may help to author test cases and test scripts (e.g. BDD scripts) while developers might help to execute test cases. Over time there may be a greater degree of cross-skilling. Specialists, like old soldiers, don't die they simply fade away.

I'm gathering from the responses that the days of formal QA test teams is fading away as organizations form cross-functional development Scrum teams that can manage the quality of a product being developed and as tests become more automated.