After visiting a start-up that is adopting scrum, I received the following email from “B” and I’d like to share the answer here. As you will see, they are trying to be more agile, and wondering how to deal with their remote quality assurance team.
Hi, Chris,
Great agile session today. I learned a lot from you. Here are my two questions:
What is the impact of agile to the remote team? We have an outsourced QA team in China.
For the QA testing, how often should developers deliver a stable build to QA for testing?
Thanks,B.
With part of the team in California and part in China, the biggest source of trouble will be communication. Of course, this is true even if you are not trying to work in an agile way.
The first thing I wonder: Why do you have an outsourced QA team in China? If the answer is that they are the world’s experts in testing your technology, then it’s likely to be worth suffering the communication issues in order to gain the benefit of working with these experts.
But what if we are outsourcing QA to a team China for other reasons? Perhaps it’s because it’s less expensive? Beware of cost-focused thinking! Our goal should not be to have as many QA people as we can, given our budget. Nor should it be to test the product as cheaply as possible. Our goal should be to create the best return on the money, time, and energy invested in development (and I mean the whole process, end-to-end). This usually means getting high-value deliverables to market as quickly as possible. If our less expensive QA team slows us down, and acts as a bottleneck, limiting our ability to bring product to market, then we may be “saving” ourselves out of a lot of potential profit!
You are going to have to work hard on communication. Try having a daily stand-up meeting. China is 15 hours ahead of California, so when it’s 6:00 PM on Monday in California, it’s 9:00 AM Tuesday in China. You might meet Monday – Thursday at 6:00 PM, California time. I’d recommend using video for these meetings, so that the team members can see each other. I’d also recommend having a text chat window open, so that it is possible to get clarification when the audio isn’t clear. There’s much more to making things work well with remote team members, but this might be a good start.
Your second question, “How often should developers deliver a stable build to QA for testing?” is also a communication question. One of the most powerful ways that people working together on a software project communicate is through working software. We could talk for days about what the software should do, or we could fire it up and see what it actually does. Instant clarity, regardless of timezone or accent!
Therefore, I recommend delivering stable builds continuously. Continuous integration has become a well-accepted, and well-supported practice. The reasoning behind it goes like this: Integration gets more difficult the longer you wait. If you try to get a stable build once a month, you will likely spend a painful week at the end of each month, merging changes and trying to get everything working again. If you deliver a working build once a week, then there won’t be nearly so much change to integrate, and so it may only take you a day or so to get the build working. But if you integrate many times a day, each integration will be small, and easy to do.
If the developers always have a good build available for the testers, then the testers can pick up and test a build whenever they are ready. This will allow them to raise issues, ask questions, and get clarification as frequently as possible.
This brings me back to my earlier thoughts about bottlenecks. You may find that the coders can create testable builds much faster than the testers can test them. This will be a clear indication that testing really is your bottleneck.
I realize that I’m just scratching the surface of answering your questions. Perhaps our readers will chime in with additional suggestions.
Cheers,