offshore development can be called as "Distributed Agile". Collaboration among testers, programmers, and other stakeholders is more highly valued on agile projects than details of process, practices, or tools. Test engineers are part of feature teams. Agile methods ask teams to continually evaluate how to improve group interaction, for the benefit of the project./p>
Once we have decided the members of the feature team building the team is the first priority. We need to plan for internal and external team building activities initially. We can also do lot of informal interactions and get together ... like all feature team members having evening snacks together in the snacks parlor.
Chat, email , wiki , telephone etc.. can be used for constant communications. We need to plan for weekly meetings with members of the feature team who are in the remote location. It is a good idea to have all the feature team members participate in this meeting. Frequent chat conversations between the development engineers and the remotely located test engineers is a good practice. This will help us to build the relationships. We need to agree up on the overlap timings when the chat interaction can happen as most of the time one of the engineers will be at home because of the time zone differences. Monthly Video conferencing is another good practice for improving the interactions. Engineers traveling in both directions frequently (2-3 travels per quarter) and working with the remote team for 3-4 weeks will enhance the relationships. This will help us for better culture sync. These ambassadors ensure there is enough osmosis within the distributed feature team.
Working Software over Comprehensive Documentation
Jim McCarthy said that, "The regular build is the single most reliable indicator that a team is functional and a product is being developed." This is very much true in the case of a distributed agile team. We need to ensure that we have a good build mechanism in our organization where the latest builds are easily available for the test teams. This will help the test teams to run their test on the latest code. We need to automate the big mountain acceptance tests using appropriate tools. This will help us to test often and communicate the progress to the feature teams.
Frequent demos of the current status of the features to entire feature team is very important. It is a good idea to have such demos weekly once. Demos can be arranged for remote teams on Fridays and we can have a group test after that where the entire feature team tests the latest build with a focus on new features. These demos can be recorded using WebEx and uploaded to a common repository. Later if some of the team members want to go through the demo they can always replay it from the common repository. During the initial milestones where the top priority features are developed we can use build mechanisms like "sandbox" where the developers check in their new code as and when the unit test pass into a sandbox build maintained by the feature team. Test engineers can always use this build for testing the new features. As we are going to give feedback on working software rather then on design documents or requirement documents the feedback inputs will have more value. Development engineers can incorporate the feedbacks back into the sandbox next day. At the end of the week the all the new code checked in by feature team in the sand box (which is tested and feedbacks incorporated) can be checked into the main line code. If we are