7

Developers and QA testers are treated as separate teams at our company, something we are trying to change by adopting scrum. The QA team is distributed globally and each local team has different hardware in order to test platform-specific tweaks we make to our applications. So if we implement a fix required for the application to run on platform X, and QA Team 1 has an X onsite, then they are assigned to validate that particular defect or user story. If we implement a fix for platform Y, that gets validated by QA Team 2. And so on.

The problem is that we do not know ahead of time which platforms we will be developing for, and therefore cannot say ahead of time which QA teams we will need to partner with during a particular sprint. Incorporating all of QA into our scrum team every sprint would make the team huge, with the associated coordination challenges and overhead that brings. We are experimenting with a scrum of scrums that includes representatives from both the dev and QA teams, but that still maintains the current organizational boundaries rather than making us a truly cross-functional team.

How can this process be adapted to scrum?

I understand that kanban might be a better fit for this operational model, but that is unlikely to happen.

Improve this question
2
  • Some initial thoughts... Would getting each QA team one of each platform/training be more cost-effective than the current overhead or costs in delays? Is getting QA local to the team possible? Do the devs have platform access for their own testing?
    – Jeff Lindsey
    Mar 3, 2016 at 21:25
  • @JeffLindsey I don't believe there has been or soon will be any study on the costs of equipment vs. delays, so I would say no, it is not more cost-effective to get everyone the same hardware. We have local QA, but they are limited in the testing they can do for the same reason (hardware) as the rest of the distributed QA teams. Devs do have remote access, but the testing often requires physical access to the system.
    – Pedro
    Mar 5, 2016 at 4:35

1 Answer 1

Reset to default
5

Scrum recommends that teams consist of people with every skillset necessary to create a working product increment or potentially releasable software at the end of every sprint. This means that every scrum team should consist of backend developers, frontend developers, as well as testing engineers specializing in the different platforms.

The way you're operating today is by separating people based on their function rather than by the product they support. This creates walls between teams and leads to delays and impediments.

What I feel works best, in my experience, is to put a testing engineer from team 1 and team 2 on your scrum team and have them work as a part of that team. The QA manager then should become more of an agile manager whose responsibility is to help the testing engineers grow and improve in their careers but without getting caught up in the day to day details of what the team is working on in the product.

Such people should still collaborate with other testing engineers and work with senior people, but they should also act as members of the scrum team, working on a single product just like the rest of the scrum team.

To make such changes will not be easy. You'll need to convince senior management, the manager of the testing teams, and your own team to agree to try this as an experiment to see if productivity improves. If it doesn't, you can always go back to the old way of doing things.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.